commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rey Francois <>
Subject RE: [Vote] Mapper framework in sandbox (was RE: Commons Validator Pac kaging/Content)
Date Wed, 16 Jan 2002 09:50:29 GMT
In terms of stability, the mapper framework should be pretty stable. It's
used in production and I wouldn't like to break the API. For the future
development prospects: well it depends on the community too!!! There are a
few things that can be done, the todo.xml does list interesting possible
extensions. As far as I am concerned I work on it either in my spare time,
or when it's for a specific project. Donating it to the commons is for me a
logical evolution: it does build upon commons stuff (digester, beanutils,
pool), and I really think it does answer an existing need, especially if you
work in a transactional world with value objects, result sets, etc.

See also an extended interaction section below, highlighting differences
with David's framework.


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

The main differences with the validator framework from David Winterfeld
(included with Struts as a contribution), is in the scope and level of
abstractions. While the validation framework only covers the validation
part, the mapper framework can also convert values, validate converted
values, and copy the converted/validated values to one or more object (e.g.
value objects). The mapper framework provides many abstractions: validators,
converters, getters, setters, error handlers, etc., making it possible, for
example, to define each single validation and conversion in its own class
that can easily be reused. Also, the mapper framework includes a small
language that is used essentially for simple validations and for combining
validators and converters together, making it easier to create smaller
grained and reusable validations/conversions that can be glued together with
this language (e.g. no need to write a third validator in order to combine
two existing ones). Most of the mapper framework classes (mapper, mapping,
mapped-object, etc.) can be extended so that much of the behavior can be
altered either globally or locally. On the other hand, the validator
framework from David provides less levels of abstractions (e.g. each
validation is a method on a class) and extensibility.  It does however
perform a very good job at validating forms within a Struts application,
even making it possible to generate client-side validation in Javascript.
This latter feature is probably the only thing the mapper framework doesn't
do compared to David's validation framework. However it would easily be
implemented by making the mapper framework support the Visitor pattern, and
by implementing a javascript visitor.

The differences with the Intake service found in Turbine are less clear to
me since I never used it. From reading the Intake doc, it seems to cover the
same functionality: validate/convert/transfer. Intake is part of the Fulcrum
service framework used by Turbine, so at present using intake means (correct
me if I'm wrong) using the fulcrum framework as well. On the other hand, the
mapper framework is not dependent on any other application or service
framework such as Struts or Turbine/Fulcrum. It has of course dependencies
with the packages mentioned above, but one can use the mapper framework in
any context: Struts, Turbine, etc. For example integration with Struts is
best done via subclassing the ActionMapping and adding a new property
containing the name of the mapper to use for validating an ActionForm. That
way the mapper can be specified in the struts-config.xml file.

-----Original Message-----
From: Jeff Turner []
Sent: 15 January 2002 23:10
To: Jakarta Commons Developers List
Subject: Re: [Vote] Mapper framework in sandbox (was RE: Commons
Validator Pac kaging/Content)

On Tue, Jan 15, 2002 at 10:24:37AM +0100, Rey Francois wrote:
> I've sent this post yesterday but I'm pretty sure it will quickly fade
> the abyss of all the posts on this list. So I post my proposal again,
> a more appropriate title, and using the recommended format:
> Proposal for a mapper framework
> (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)

Perhaps we should expand the meaning of "interaction" to include how it
compares to existing Commons components with similar goals.

I'm very happy to see components competing for the same turf (as the
charter allows), as long as it's clear to newcomers (ie, me:) what the
differences are, in terms of features, stability (esp. API contracts)
and future development prospects. I want to know which to spend time

+1 for putting it in the sandbox (with a cleaned-up build system:)
+10 if you could outline in the proposal how it differs from David's

Btw, the javadocs look very good, which to me is a sign of overall


To unsubscribe, e-mail:
For additional commands, e-mail:
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.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message