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
