Jim Newsham wrote:
> Jean-Baptiste Nizet wrote:
>
> >
> > I'm thus in favor of keeping the current behavior, where the form is not
> > validated if the input element is not defined. It's just a matter of form
> > reusability and declarative programming vs classical programming.
> > Now, I wouldn't be too much against the reverse situation, where you would have
> > to specify something in the config file if you want your form NOT to be
> > validated. The best thing to do, IMHO, is to make the presence of a
> > "validateForm" element (true or false) mandatory as soon as a formAttribute is
> > defined. That way, you have the complete declarative control on the validation,
> > and you can't make errors, since the application won't deploy if you forget to
> > specify the element. Of course, you could still set it to false instead of true,
> > but that would be your entire responsibility, and would have the same
> > consequences as inadvertently returning null in your validate method.
> >
> > What do you think?
>
> I'm in favor of being able to configure validation independently of the form also.
> This allows me to use my form object for both setup of the jsp page
> ("preprocessing") and later processing the changes made by the user. The
> pre-processing requires no validation -- in fact some of my pages broke when
> I downloaded a recent struts which always validates, causing me to revert to my
> previous struts version.
>
> An alternative would be to subclass non-validating FormX.java to get
> ValidatingFormX.java which just overrides validate(), for all forms FormX which use
> this style. Personally I'd rather configure this in struts-config.
>
Configurability on a per-mapping basis seems to make the most sense. I'm going to add
an attribute to the <action> element (and a corresponding property on ActionMapping) to
make this possible.
>
> Jim Newsham
Craig
