commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <ssand...@nextance.com>
Subject RE: [Vote] Mapper framework in sandbox (was RE: Commons Validator Packaging/Content)
Date Wed, 16 Jan 2002 18:33:30 GMT
So the initial set of comitters needs to be updated to be:

Rey?
Ted?
Dave?
Craig?

Just wondering, as that piece of the proposal is not here.

Scott

> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org] 
> Sent: Wednesday, January 16, 2002 9:48 AM
> To: Jakarta Commons Developers List
> Subject: Re: [Vote] Mapper framework in sandbox (was RE: 
> Commons Validator Packaging/Content)
> 
> 
> +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: 
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: 
> > <mailto:commons-dev-help@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:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> 
> --
> To 
> unsubscribe, e-mail:  
>  <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message