Great writeup - however - You are proposing to put this in the sandbox? Don't ask! do!
:) You don't need anyone's approval to put code in commons (assuming you are free and clear to do so from a license POV :) On 1/15/02 4:24 AM, "Rey Francois" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > ************************************************************************ > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
