Jim Richards wrote:
> Having had a look at struts for few weeks now, I have
> some thoughts based on other work I've done and what I'd
> like to see/do implemented.
>
> Just to start with, I do like it. It'll make development
> cleaner and easier. I would have done something similar
> based on Cold Fusion's fusebox model probably.
>
> The validation method in ActionForm.validate seems to me to
> being too simple. I'm used to JavaScript validation that is
> fairly similar (see attached html file). I do notice that
> there is some mention of this in the TODO list.
>
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 :-).
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 main problem I see so far with validate is how it will
> work for mulitpage forms. The only way I can see that
> it'd work is by having a hidden field (or form submit value
> that would specify the page number and an if statement
> in the validate method that would check just the required
> values. This would tie the validate too closely to the HTML
> page.
>
Multipage forms are going to be pretty messy under most scenarios. I generally
suggest a single ActionForm bean for the entire multipage form, but you are correct
that the validator needs to have some way to know what fields are on what pages.
>
> If you look at the example I've attached, you'll see that
> there are references to the pages in MultipageForm and
> MultipageAction, as well as validation that is tied to the
> pages. (The code could be cleaner, eg. more messages
> from the .properties file, better error checking,
> and cleaning out unused beans, formatting of the code ;-)
>
> I could write the code so it checks that a parameter is
> specified, but this will cause problems with check boxes and
> multiple select.
> 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.
>
> What I'd like to see is better use of the Bean style, where
> we use PropertyVetoException and similar. It does mean
> writing a more stubborn bean container. But it'll be useful
> when it comes to using Beans developed for instant graphical
> interfaces. Since all my work has been back end work, I've
> only just got into Beans now after a long time in Servlets,
> EJB and Java 1.0 AWT programming.
>
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.
>
> Have fun ...
>
> --------------------------------------------------------------------------------
>
> validate.htmlName: validate.html
> Type: Hypertext Markup Language (text/html)
>
> Name: multipage.tar.gz
> multipage.tar.gz Type: VRML 2.0 (model/vrml)
> Encoding: base64
>
> --------------------------------------------------------------------------------
> --
> Kumera - a new Open Source Content Management System
> for small to medium web sites written in Perl and using XML
> http://www.cyber4.org/kumera/index.html
Craig
