a case for an atypical business validation

[Dan Allen <da...@mojavelinux.com>]

In most cases, solving the "users type the darnest things" should be
left up to only the validator, whether it be through the ActionForm
for the Validator framework.  However, I have a case where a field
just might cross boundaries to the business logic where at first
look it might seem like the job of the validator.

Consider a user profile form which includes a password and
passwordVerify field.  At first you might want to apply a
requried,minlength to the password and a required,identical to the
passwordVerify to make sure you are getting a password from the
user.  However, since passwords are generally one-way encrypted,
there is no way to repopulate the form with the password in it when
the user is updating his/her profile.  In fact, it is standard
procedure on the web that if you leave your password blank it will
remain the same (assuming you have an account).  Therefore, in this
case it makes more sense to go ahead and leave off the required
dependency for the password field and check in the business logic
whether the account exists or not before taking the user back to the
form to enforce a password to be filled in (for new accounts).

Does that seem reasonable?

Dan

p.s. assume that the same form-bean is used for new accounts and
account updates.

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Daniel Allen, <da...@mojavelinux.com>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Rumour has it that bad dreams about Windows can be ended by 
putting on a pair of Tux slippers and clicking your heels 
together 3 times while saying. 
"There's no place like /home." 
"There's no place like /home." 
"There's no place like /home."
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

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