struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rey Francois <>
Subject RE: Form Bean Validation
Date Wed, 27 Jun 2001 18:12:55 GMT

I'm not sure yet I understand exactly what you need yet, and why validation
on the setter methods of the form would help you. But have a look at the
mapper framework I made publicly available recently
( It does not
do validation on the setter method of the form, but it may be flexible
enough for you to do more than just validating. You could imagine a mapper
that actually contains more mappings than there is fields in the form. Those
extra mappings could for example provide you with the ability to specify the
SQL statement. You could create with this framework some custom validator
classes that allow you to specify valid ranges, default values, etc. Almost
every XML element in the mapper config file supports one or more child
'set-property' elements like in struts-config.xml, so you can use that
pattern to customize several instances of the same class of
validators/converters that are registered with the mappers.


PS: I'm sending this also to you Jonathan personally because for some
reasons I do not see messages I posted on the list recently... Perhaps
they've change the setup so that one does not get his own postings?

-----Original Message-----
From: Jonathan Fuerth []
Sent: 27 June 2001 20:03
Subject: Re: Form Bean Validation

On Wed, Jun 27, 2001 at 09:27:13AM -0700, David Winterfeldt wrote:
> The ActionForm is considered to be a container for
> holding and preserving the information the user has
> entered.  So you don't want to reject any data at this
> level because if the validation fails you want to
> return exactly what the user has entered.  So most

Aha!  Ok, that makes a few things clearer in my head.  Unfortunately,
it also raises some new questions. :)

For instance, how would you go about modeling this generic and (I
imagine) common web-application scenario:

-A server-side validated form is presented to the client, who is
expected to make mistakes.
-The server catches the mistakes and presents the previous values to
the user, flagging the ones that need to be re-entered.
-Finally, the user gets everything right.  A page is presented to the
user which summarises the input, along with an "accept" or "cancel"
choice at the bottom.
-The user gives the go-ahead, and the correct information is stored in
a JDBC-accessed database.
-Later, the user (or other interested parties) will be presented with
this data.

This is essentially what I've been trying to figure out for a year now
(when I first got into servlets).  In my experience, the fields in the
form will change fairly often, as will their default values and
acceptable ranges.  What I'm aiming for is to be able to perform this
sequence of events for any given set of database-stored data, while
only specifying the labels, datatypes, defaults, accepted ranges, and
underlying SQL statements once (and hopefully in one place, but that
may be too much of a stretch).

Have you (or other struts users) managed this feat yet?  I'm very
interested in anything anyone has to say on this topic.. It's become
an obsession (since my full-time job is to design and implement
java-based, RDBMS-backed web applications).

> * When the exception/validation happens in the setter,
> you can't do things that depend on other fields.  Like
> this field is required only if another field is filled
> in.

Ok, excellent point.  That JavaBeans constrained property model kind
of relies on an AWT/Swing-type GUI, where this isn't an issue.  As
you've observed, it's certainly an issue in a web application.
Dependant fields would have to be informed whenever their dependencies
change value.

> Also the current system isn't able to handle an
> exception being thrown during the auto-population of
> the ActionForm from the request.

Ok.  It sounds like I'll have to make a similar (but different) bean
to each FormAction bean which does the actual database manipulation
and stuff.  That throws me off my little quest for the
single-specification-of-everything-in-the-form paradigm. :)

Thanks for your reply.

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.

View raw message