We are developing here such validation framework. I've already posted a
message about this on 11 May, but I didn't get much reply yet. The problem
we are trying to solve here is to not only do a validation, but also convert
the form fields into objects, e.g. from a string to a date object, an
operation which is in itself a form of validation (if the conversion fails,
the input is invalid). The other interesting feature of what we're
developing is that once a field has been validated/converted, it can be
copied onto another object property so that at the end of the validation
cycle, we can directly retrieve a usable model object already populated. In
our case, those objects are command objects we send to an EJB backend.
We call this extension the "Mapper", as the overall concept is to map
properties from one object (ActionForm) to another object (command bean,
PreparedStatement, etc.), while performing validation and type conversion.
The mapper is configured through an XML file with contains the mapper
definitions, along with the definition of other object such as validator and
converter classes. This XML configuration file is digested by the digester
and results in a hierarchy of objects. At the top, the Mappers class
contains the list of Validators, Converters, and Mapper instances. The
Mapper class encapsulate Mappings and MappedObjects, each Mapping being a
relationship between one or more MappedObjects and containing the name of
the fields to "import/export". Each individual Mapping can use its own
Converter. If there is a conversion problem, the Mapper calls the
ConvertExceptionHandler which has been provided during its initialization.
Each Mapping can also validate the input before conversion by using
Validator classes. The definition of the validation is done using a small
language (parsed by JJTree/JavaCC) so that multiple Validator can be
combined (and, or, xor, etc.).
Other interesting things to mention: each MappedObject can define its own
Getter, Setter, and Creator classes, allowing us to not only support
JavaBeans, but also query strings, query and result buffers, etc. Validator
and Converter classes are given a Locale instance in order to support some
internationalization. A Mapping can itself contain a nested Mapper, so that
hierarchies of objects can also be validated/converted/mapped. Finally, the
whole cycle of validating/converting/mapping can be done in one call, or can
be split up into individual steps: 1. Validation, 2. Conversion, 3. Mapping,
thus avoiding unnecessary processing if for example the validation fails.
This mapper functionality will be used at different stages: during the
validation of a form (ActionForm.validate()), during the parsing/handling of
backend result messages, and whenever we need to transfer data from one
object to another. In the case of form validation, we subclass the
ActionForm and implemented the validate logic (look for a mapper named
formName+"Mapper", call its validation, create ActionErrors in case of
errors). In the future I would expect to implement two things: the recycling
of the state objects (Mapper classes are stateless, state is stored in
separate classes), and the inclusion of client-side validation with
JavaScript, in the same way as in Dave's framework.
All this is work in progress, a large part is implemented and tested. The
bit I'm implementing now is the validation with Validator classes. To give
you a more concrete idea of this extension, I included the DTD of the config
file and a sample config file I use for my testing.
Feel free to comment on this approach. I think combining
validation/conversion/mapping really makes sense otherwise you'll end up
writing custom code to do any of these three things. If the interest is
strong enough, and if the approach gets some support, I wouldn't mind having
it included in Struts at all.
François Rey
Financial WebSuite
Capco
http://www.capco.com/
-----Original Message-----
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: 02 June 2001 08:43
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Client/Server Side Validation for Struts 1.1
I'd like to get a discussion started on the
client/standard validations for Struts 1.1. I thought
it would be good to talk about what basic features it
would include and implementation. Here are the
descriptions from the To Do list for 1.1.
Standard Validations.
Add the ability to configure standard validations on
particular properties to be enforced by the controller
servlet automatically. Where feasible, client-side
JavaScript validations may also be generated based on
the same configuration rules.
Client Side Validation.
Add the ability to automatically generate optional
JavaScript code to perform client-side validations for
things like required fields, numeric fields,
dates/times/timestamps, and so on. The required
validation should mesh with validation enhancements
provided in the controller servlet itself.
Nic Hobbs and I have both volunteered for the Standard
(Server Side) Validations and Ted Husted, Nic Hobbs,
Spencer Smith and I have volunteered for the Client
Validations (JavaScript). Ted has been using a
validation framework I've done on a project (I'm not
sure what version). It lets you define your
validation rules in an xml file. It supports
internationalized rules for a form and
internationalized messages. It has basic support for
creating JavaScript methods that can do what a server
side method does. The code, documentation, and example
webapps are posted here. And of course Struts is
welcome to the source code if everyone thinks that
what I've done so far is good foundation to start on.
http://home.earthlink.net/~dwinterfeldt/
If any of the other volunteers have started something,
I'd like to see it and I'm sure everyone has ideas for
the design. I'd go into more detail about everything
I've done, but it is probably easier for anyone
interested to go to my site and read the documentation
and javadocs posted there.
David Winterfeldt
http://home.earthlink.net/~dwinterfeldt/
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.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, you must not read, 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
***********************************************************************
mapper-config_1_0.dtd
test-mapper-config.xml
