Hi All,
Thanks for the replies, I now feel less lost in the ether :)
You each brought up excellent points which I believe are address-able.
Ultimately, I guess a working example sounds best for exploring these
ideas.. I'll try to post something back over the weekend on this.
Until then, I'll try to respond inline with your messages.
> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 20, 2001 3:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: server-side, java-based validation rules for struts..
>
>
> +1
>
> David Winterfeldt wrote:
> > I don't think there would be anything wrong with your
> > idea, but I think it is a little more flexible keeping
> > the validation separate from the ActionForm. I
> > started working on a validation framework, but I put
> > the info in an xml file. I would rather change a
> > value in an xml file than having to recompile my code.
My thinking is the JavaBeans approach keeps coupling
between validation and ActionForms very low. In fact,
the collaboration between an ActionForm and its
Validators should remain completely declaritave.
For instance, if you have an optional date on your
form, and you wanted to ues a Jakarta provided date
validator you could say something like this:
<struts-config>
<form-bean name="myForm" type="MyForm">
<change-listener
property="myDate"
type="org.apache.struts...OptionalDateValidator"
/>
</form-bean>
</struts-config>
As for recompiling, don't do it, just keep on creating
lowly coupled validation rules.
eg.
RequiredDateValidator
RequiredEmailAddressValidator
OptionalNumericValidator
etc.
> >
>
> I think the java.bean.VetoableChangeListenter would be a good thing in
> an helper bean that was populated by an ActionForm bean, but would
> violate the API contract for an ActionForm bean. The ActionFormBean is
> suppose to accept whatever the actor throws at it, and then perform
> validation. This way we can return exactly what they entered for
> correction.
The point you make on Contract is a good one. It might mean
modifing our response processing a little, however, I don't
think we lose support for it. Bascially, the user submitted
value is accessible via:
PropertyVetoException --> getPropertyChangeEvent() --> getOldValue()
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
-- Levi
