struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: [Gurus Invited] Why not an Action Based Validator?
Date Wed, 15 Jan 2003 20:27:19 GMT


On Wed, 15 Jan 2003, Phase Web and Multimedia wrote:

> Date: Wed, 15 Jan 2003 08:28:23 -0700
> From: Phase Web and Multimedia <mail@phase.ws>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> Subject: RE: [Gurus Invited] Why not an Action Based Validator?
>
> Thanks. I understand the logic of having the form handle simple validation
> to avoid unnessecary Action invocation. That does make sense.
>

That was indeed the original intent of validate() in ActionForms -- to
focus on the "user interface" type validations rather than business rules
validations.  There's more than one valid :-) use case, so I don't see us
getting rid of this even if we were to add something for business layer
validations as well.

It would be interesting to explore a more structured environment for
creating validation frameworks for business rules checking as well.
Perhaps the standard actions package (org.apache.struts.actions) could
offer a base class (along the lines proposed earlier in this thread) with
the appropriate model built in for this.

I haven't played with it myself, but I understand that you can use
commons-validator classes directly to configure your business tier
validations -- including the ability to create custom validation methods
as needed.  All that would be necessary is a way to read in the
configuration of these validators from some XML file as well.  Or, you
could just write your validations as standard Java logic in the validate()
method.

One advantage you didn't list for doing all the validations together is a
human factors one -- the user can find out about *all* their errors in one
round trip to the server.  For example, if you make a syntactic error in
one field (that could be caught by UI-level validation) and a semantic
error in another field (invalid customer account number), it takes two
round trips to fix all the errors if the validations are split, but only
one trip if they are joined.

> Thanks,
> Brandon Goodin

Craig



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message