Re: [Vote] Mapper framework in sandbox (was RE: Commons Validator Packaging/Content)

[Ted Husted <hu...@apache.org>]

+1 as a Commons package.

Rey's a longtime contributor to the Struts lists, and his Mapping
framework is often mentioned by the Struts developers. Rey's also made
some important contributions to the Digester package. As he mentioned
elsewhere, this package complementary to the Commons Validator, and I
believe some people use both in the same application. 

I think both the Mapping framework and Rey himself would both be worthy
denizens of the Commons.

But, I don't believe it needs to go into the sandbox first. The package
has been "out there" and available for download with full source for
some time, and there is a developer community already using it. 

-Ted.


Rey Francois wrote:
> 
> I've sent this post yesterday but I'm pretty sure it will quickly fade under
> the abyss of all the posts on this list. So I post my proposal again, using
> a more appropriate title, and using the recommended format:
> 
> Proposal for a mapper framework
> 
> (0) rationale
> 
> In many application environments validation needs to be performed on data
> fields, data is converted from one form to another, and is being transferred
> from one object to another. A typical example is found in graphical user
> interfaces that validate user input, convert it to a proper form, and send
> it to a server application for processing. In the case of HTML front-ends,
> the HTTP protocol forces user input to be sent as text data to the server
> where the validation and conversion has to be performed.
> 
> Most of the time implementing such validation and conversion requires lots
> of custom code: get the data element, validate it, convert it, and put the
> result into another object. In a small application, this may not be an
> issue. However in medium to large applications with many different data
> elements, such coding becomes a tedious and error-prone task.
> 
> In such situation developers tend to achieve some form of reuse in order to
> reduce the menial work. At the lowest level is the cut'n'paste approach. A
> better approach is the definition of some high-level abstraction which
> encapsulate reusable logic: validation and conversion classes are typical
> abstractions found in most systems.
> 
> However, even with validation and conversion logic being reusable, some
> custom coding is still required in order to attach those validations and
> conversions to the data elements. To avoid completely the custom code, an
> even higher level of abstraction is needed in order to model such bindings.
> The mapper framework implemented in this package provides such high-level
> abstractions, making the validation, conversion, and transfer of data a
> process driven by a configuration file.
> 
> Although the central concept in this framework is the one of a mapper, the
> framework is flexible enough to be used only for validating fields of an
> object, or converting an object into another one, or simply copying fields
> from one object to another. It is also flexible enough so that validation,
> conversion, and transfer can be performed on multiple objects within the
> same mapper.
> 
> (1) scope of the package
> 
> The mapper framework provides the necessary classes and abstractions to
> perform validation, conversion, and transfer of data fields between any
> types of objects. The configuration of all mappers and other abstractions is
> done in one or more XML file loaded at startup. The framework does not
> depend on any other application framework such as Struts or Turbine, and
> integration with such frameworks should be provided separately.
> 
> (1.5) interaction with other packages
> 
> The mapper framework makes use of
>  - the Commons Digester
>  - the Commons BeanUtils
>  - JavaCC
>  - the Commons Pool (work in progress)
> 
> (2) identify the initial source for the package
> 
> The initial codebase is to be contributed by Francois Rey. A version of the
> source is already available at <
> http://husted.com/struts/resources/mapper.htm >.
> 
> (2.1) identify the base name for the package
> 
> org.apache.commons.mapper
> org.apache.commons.mapper.parser
> 
> (3) identify any Jakarta-Commons resources to be created
> 
> (3.1) mailing list
> 
> Until traffic justifies, the package will use the Jakarta-Commons list for
> communications.
> 
> (3.2) CVS repositories
> 
> For the time being, the package will reside in a sub-project of the
> Jakarta-Commons sandbox CVS.
> 
> (3.3) Bugzilla
> 
> The package should be listed as a component of under the Jakarta-Commons
> Bugzilla entry.
> 
> (3.4) Jyve FAQ (when available)
> 
> commons-mapper
> 
> (4) identify the initial set of committers to be listed in the Status File.
> 
>  Francois Rey
> 
> -----Original Message-----
> From: Rey Francois [mailto:Francois.Rey@capco.com]
> Sent: 14 January 2002 13:40
> To: 'Jakarta Commons Developers List'
> Subject: RE: Commons Validator Packaging/Content
> 
> This Intake component is quite interesting. If I had known of its existence
> about half a year ago I may have inspired myself or even reused it instead
> of developing my own validation/conversion/mapping framework.
> 
> In any case, I now have this framework that I think is quite relevant to all
> these discussions in the commons list. I've already "published" the mapper
> framework on Ted Husted's resource site (see
> http://husted.com/struts/resources/mapper.htm) and some of you may remember
> a few postings about it.
> 
> Because I see so much discussion about a validation framework, about Intake,
> and competing implementations in the sandbox, I'm also starting to itch: I'd
> like to put this mapper framework in the sandbox so that more people can see
> it and judge it. Let me give a few bullet points about it:
> - it's a validate/convert/transfer framework: it can take values from one
> object, validate/convert them, and transfer the resulting values into
> another object
> - it can do all this or just a little (e.g. just validation) very easily, in
> one go or step by step (e.g. step1: validate; step2: convert; step3:
> transfer; with user control between each step).
> - XML configuration: mappers, mappings, converters, validators, validation
> rules, getters & setters, etc. are defined in one or more XML config file.
> - it is HTTP and Struts independent: it only depends on the PropertyUtils,
> Digester, JavaCC, JUnit, ...
> - it is used in production within a Struts web application: it handles all
> form validation, all backend request population, and all mappings of backend
> results to presentation beans.
> - more info and download on http://husted.com/struts/resources/mapper.htm,
> and in the included HTML file.
> 
> This framework IMHO is of good quality, but I never bothered "promoting" it
> by creating a web site for it. Since it was made downloadable from Ted's
> site, I received a few mails, both on the list and personally, from people
> using this framework asking me questions. So it is used out there, but it's
> usage is very limited compared to David's validator component.
> 
> Making it available in the sandbox would make it more visible, would allow
> others to participate in its evolution, and would also provide a "healthy"
> competition to the validation framework business.
> 
> Anybody out there supporting the submission of this mapper framework in the
> sandbox?
> 
> Fr.
> 
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: 07 January 2002 02:42
> To: Jakarta Commons Developers List
> Subject: Re: Commons Validator Packaging/Content
> 
> Jon Scott Stevens wrote:
> > That is my question. Why doesn't David work towards integrating Intake
> into
> > Struts instead of working on pulling what is duplicated from Struts out
> into
> > Commons? The answer is simple...it is David's itch to scratch and it is
> the
> > simplest thing for him to do. That is the current failure of Jakarta in my
> > eyes. Jakarta has become no better than Sourceforge. It is a place where
> you
> > can dump your least common denominator.
> >
> > Instead of Struts working to use Turbine code and then move it into
> Commons.
> > Struts came up with their own validation framework, made it stable in
> Struts
> > land and is now dumping it into Commons. There is a complete lack of
> > communication there.
> 
> Yes, we recognized that last year, and so created the Commons. At that
> time, David's framework already existed. Learning the lessons of
> Turbine, we decided not to integrate into Struts, and left it as a
> free-standing component. (It was created that way from the beginning.)
> 
> David has already done the work. At this point, the duplication of
> effort would be making Intake a free standing component. If someone
> wants to do that, and donate it to the Commons, I think that would be
> great,  especially since the Commons specifically provides for
> competiting implementations.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> ************************************************************************
> The information in this email is confidential and is intended solely
> for the addressee(s).
> Access to this email by anyone else is unauthorised. If you are not
> an intended recipient, please notify the sender of this email
> immediately. You should not copy, use or disseminate the
> information contained in the email.
> Any views expressed in this message are those of the individual
> sender, except where the sender specifically states them to be
> the views of Capco.
> 
> http://www.capco.com
> ***********************************************************************
> 
> ************************************************************************
> The information in this email is confidential and is intended solely
> for the addressee(s).
> Access to this email by anyone else is unauthorised. If you are not
> an intended recipient, please notify the sender of this email
> immediately. You should not copy, use or disseminate the
> information contained in the email.
> Any views expressed in this message are those of the individual
> sender, except where the sender specifically states them to be
> the views of Capco.
> 
> http://www.capco.com
> ***********************************************************************
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Vote] Mapper framework in sandbox (was RE: Commons Validator Packaging/Content)

[Jason van Zyl <jv...@zenplex.com>]

On 1/16/02 12:47 PM, "Ted Husted" <hu...@apache.org> wrote:

> +1 as a Commons package.
> 

Sounds good to me.

+1



-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>