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. Fr. (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 [mailto:[EMAIL PROTECTED]] 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 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 > ... > (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 learning. +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 validator. Btw, the javadocs look very good, which to me is a sign of overall quality. --Jeff -- 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 *********************************************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
