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 Thu, 17 Jan 2002 15:57:30 GMT
Jeff just took off to Africa, so you might not get his answer.

You have my +1 if you update the initial committers to contain 3 people
willing to work on this (Yes, you count as one of them).

Scott

> -----Original Message-----
> From: Rey Francois [mailto:Francois.Rey@capco.com] 
> Sent: Thursday, January 17, 2002 12:50 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [Vote] Mapper framework in sandbox (was RE: 
> Commons Validator Packaging/Content)
> 
> 
> Sorry, I made a mistake in listing the previous votes. Below 
> is the correction (switch a and b).
> 
> a: mapper in commons sandbox
> b: mapper in commons
> 
> Ted is +1 on b.
> Jason is +1 on b.
> Jeff is +1 on a, but that was before the suggestion of 
> putting the mapper in the commons directly. Jeff, could you 
> please clarify your vote in terms of option a or b? Thanks.
> 
> Fr.
> 
> -----Original Message-----
> From: Rey Francois [mailto:Francois.Rey@capco.com]
> Sent: 17 January 2002 09:45
> To: 'Jakarta Commons Developers List'
> Subject: RE: [Vote] Mapper framework in sandbox (was RE: 
> Commons Validator Packaging/Content)
> 
> 
> I agree with this list of initial committers.
> Since it is proposed as a commons as well, I suggest to 
> qualify your votes as follows:
> 
> a: mapper in commons sandbox
> b: mapper in commons
> 
> Ted is +1 on a.
> Jason is +1 on a.
> Jeff is +1 on b, but that was before the suggestion of 
> putting the mapper in the commons directly. Jeff, could you 
> please clarify your vote in terms of option a or b? Thanks.
> 
> I of course plan to "standardize" the build process and align 
> with the Jakarta template, repackage, and test this before submission.
> 
> Fr.
> 
> -----Original Message-----
> From: Scott Sanders [mailto:ssanders@nextance.com]
> Sent: 16 January 2002 19:34
> To: Jakarta Commons Developers List
> Subject: RE: [Vote] Mapper framework in sandbox (was RE: 
> Commons Validator Packaging/Content)
> 
> 
> 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>
> **************************************************************
> **********
> 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>
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
***********************************************************************


--
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