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.
