> In 1.0, the validation model for the server side has been significantly enhanced.
>The
> idea of auto-generating JavaScript validation code for the things you can check on
>the
> client side is attractive, but won't make Struts 1.0 (unless someone really hurries
> and creates it :-).
Hmm ... I am using a nightly build from about a week ago,
I'll have to dig into it to see how this enhanced validation
works (or is it not in there yet).
> I would caution you that, even if you implement client-side JavaScript validations,
> your server side logic should not rely on them. After all, the user can easily turn
> off JavaScript, and/or write an application that simulates a browser's interactions
> with the server but tries to bypass your edits.
The client side validation is only for simple things,
that validate() would do, such as checking for number
format, empty strings, valida credit card number, post
code and so on. The action bean would still need to check
that, say a credit card was valid (rather then just a number).
>> Also, I couldn't work out how to get the request attributes
>> to be sticky between the next and previous pages (think CGI.pm
>> and it's param() functions). It's probably something to do
>> with the response, but I don't have the docs handy.
>>
>
> Sticky checkboxes have been fixed in 1.0 by adding a reset() method to the ActionForm
> class. You should reset any boolean properties to false in the reset() method, which
> is called before the property populator -- which will set the checkbox back to true
>if
> it was indeed checked.
Hmm, I was thinking more about text fields and so on
between multipage forms, not rebuilding the current
form with the previous data.
> I will take a look at your example, but there is a subtle philosophical issue that
>has
> affected the way ActionForm beans are specified in Struts.
>
> Basically, an ActionForm is part of the presentation layer, not the model layer.
> Their primary purpose is to encapsulate the current set of inputs that a user last
> entered -- whether or not they are valid -- so that you can create an error page that
> faithfully represents what *was* entered, and points out what needs to be changed
> (just like GUI apps do). Otherwise, you're going to force the user to have to
> re-enter some of the fields, and that will not make you a popular person with your
> user community.
I suppose what I'd like is rather then having validate()
being called, when each property has it's setXXX method
called, the setXXX method does the simple validation, and
throws a ProperyVetoException with the error message
text as part of the Exception. Then if a try block
cathces this, stacks up the error messages and calls
the page again with these errors. It seems that from
what I've seen, most validate() methods are the same.
