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:[EMAIL PROTECTED]] > 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:[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:commons-dev-> [EMAIL PROTECTED]> > > -- > To > unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
