Martin,
[EMAIL PROTECTED] wrote:
>
> 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.
Yup, I minutes after my lost post, I received the post for Volunteer for
Validation
Framework. Wish I had read that first! The validation stuff sure could
be interesting.
> 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 was considering an approach where coders wrote validation code in Java
(we all know java!)
yet the Struts framework executed it. You would extend or implement a
common java class/interface defining a single method,
public ValidationErrors validate(); say.
That is then mapped to the form field in an xml file somewhere.
Struts, however could ship all the standard validations (such as Strings
to ints)
together.
It is something I have not given much thought to yet, but would be
interested in
exploring further.
> 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.
Sounds great!
> 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
