I actually do a different design for validating forms. I place a hidden
field before each field I want validated, with a name of validate and a
value of RegExp names that determine the type of validation to be done. In
the JS, I loop through all elements, and if the type==hidden and
name==validate, I get the value, tokenize it into , separated items, then
run through a switch() to validate each of one or more types of validation
done on each field. Using Regular Expressions, I am able to check for
minimum and maximum lengths of both text areas and text fields, required
fields must have something in them, a phone number field which must have
only numbers in the area, prefix and suffix sections, an email address via
the RFC spec for proper email addresses, min/maximum list box selections,
and a few other types. I also allow an image to be used next to each field
and using a mouse-rollover technique, if an image= is specified in the
hidden validate field, and an error occurs, it displays a red arrow next to
the field that is having a problem. It can also pop up a box that indicates
an error on a given field, or just pop up a box at the end of the entire
form being validated if any errors occur. It works pretty nicely, and I
don't have to use any javascript in the form itself or anywhere else..I
simply have every form return a submitForm() value of true or false,
depending on errors.
> -----Original Message-----
> From: Jim Richards [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 21, 2000 3:21 AM
> To: [EMAIL PROTECTED]
> Subject: thought on design
>
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Have fun ...
>
>
>
>
