commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rey Francois <Francois....@capco.com>
Subject [Vote] Mapper framework in sandbox (was RE: Commons Validator Pac kaging/Content)
Date Tue, 15 Jan 2002 09:24:37 GMT

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>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message