Actually, the plan is to build exactly this type of validation into Struts
1.1. In particular, I am hoping to incorporate it into the automated bean
creation tool, one way or another.
The idea is to define your bean(s) in an XML file, and have the tool
generate the actual bean code for you. When you define a bean, you can
specify its type, along with some other validation rules (yet to be
determined). The tool will create a validate() method, and that method will
populate ActionErrors as appropriate.
My original thought was to generate code based on the validation rules.
However, David Winterfeldt has written an interesting validator that runs
off an XML spec directly. This may be a better approach, in that you can
modify the rules later without recreating the bean, among other things.
I'm not sure how this will all fall out in the end, but I will be very
surprised if Struts 1.1 does not include ways of automating the creation of
form beans, and ways of specifying validation rules without writing code.
There are several people interested in working on each of these topics, so
I expect lots of interesting discussion on each and on how to integrate them.
--
Martin Cooper
Tumbleweed Communications
At 02:46 PM 2/28/01 +1100, Nick Pellow wrote:
>Martin,
>
>[EMAIL PROTECTED] wrote:
> >
> > At 11:17 AM 2/28/01 +1100, Nick Pellow wrote:
> > >I am very new to struts as is, but as I far as I can tell from reading
> > >the implementation of the above method,
> > >the ActionForm can only have String properties. Is this correct?
> > >
> > >If so, it would be nice if the ActionForm could support types other than
> > >String and the
> > >struts engine would convert these in a similar fashion as Ant does to
> > >the attributes in the xml build file.
> >
> > Actually, Struts will attempt to convert values as it populates a form
> > bean. This is done in BeanUtils.populate(), which is called right at the
> > end of RequestUtils.populate().
>
>Ooops, thats what I was looking for but did not find.
>
> > However, the problem is what to do if it
> > can't be converted. For example, if I define a form bean property as an
> > int, and the request contains "abc", what should Struts do?
>
>Struts could create an ActionErrors object with an ActionError for each
>conversion error.
>If an error does get raised at that early stage, then one will no doubt
>be raised later on
>in the Action. The difference is that the coder has to
>a) check for the conversion error again,
>b) raise an error again.
>It also means that checking for such user mistakes is spread across
>mulitple layers in the application
>and also across multiple components within the system. I think it would
>be nice to centralize
>such type checking in one part of the system.
>
>
>The error message strings could be defined in a similar fashion to
>errors.header and errors.footer.
>Maybe something like:
>errors.conversion.NumberFormatException=You must enter a number for the
>{0} field, not {1}.
>
>Then when Struts comes across a type error, it raises the error then and
>there, using a resource
>such as the one above to report to the user.
>
>As mentioned earlier in this thread this option could be configurable in
>Struts as it may not
>always be desirable.
>
> > In 1.0, it will set the property to a (configurable) default value, but
> > that's not a good solution when there's no obvious candidate meaning
> > "invalid" (e.g. for a boolean). It also destroys the original user input,
> > so when validate() fails and returns the user to the input form, you can no
> > longer display to them the mistake they made. (By default, in the situation
> > I described above, the user would see "0" where they entered "abc".)
> >
> > So it's really best if form bean properties are all strings. What you *can*
> > do, though, is have your validate() method check that the value can be
> > converted to what you want, and return an error if it can't. For example,
> > you might use Integer.parseInt() to ensure that a valid integer was
> entered.
>
>If the validate() method does the type checking then we must implement
>type
>conversion code and type checking code in every single form bean we
>write!
>On large systems, this is sometimes very unfun.
>
>Any thoughts?
>
>Regards,
>Nick
>
>
>
> >
> > --
> > Martin Cooper
> > Tumbleweed Communications
