Jim Richards wrote:
> > 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).
>
Looking at my sentence above, I see that I wasn't clear.
The server-side enhancement is that the validate() method is now called with the
request and
the current mapping so that you have more context for making your validation decisions
--
for example, you can go retrieve the user's session and get state information you've
stored
there.
Support for auto-generating client side validation JavaScript is not there, and is
unlikely
to be in the final 1.0 release.
>
> > 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).
>
I agree with using client-side validation where you can, to improve the UI by catching
errors earlier. My caution is that you should plan on re-performing these checks as
appropriate on the server side. Don't assume that your JavaScript validation actually
took
place.
>
>
> >> 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.
This would worsen performance (handling exceptions is not particularly cheap) versus
the
current approach.
Also, there are also many sorts of error checks that depend on more than one field
("field B
is required if field A is present, otherwise it must be blank"). The HTTP and servlet
specs
provide no guarantees on what order the request parameters are presented, so where do
you
put the checks for this? In many cases, you are going to need a global validate()
method of
some sort anyway.
Craig
