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