See below.
Pierre M�tras wrote:
> [snip]
> What I proposed is to generate a server error when "input" is not set, and
> that the servlet can't find the "input" for the action. That's a programming
> error not to have correctly defined the struts-config.xml file, that's to
> say have defined a validation method without a corresponding "input" form to
> display the errors.
> But when "input" is not defined and the validation doesn't fail, it seems to
> me that not calling "processValidate" (in fact existing at the beginning of
> the function) is a source of bugs. The presence of the "input" attribute is
> now the only mean to tell Struts that your ActionForm is in fact an (old)
> ValidatingActionForm.
> I rather prefer to have the call to "ActionForm.validate" occurs every time
> (and the default "validate" returns "true"), now that ActionForm are
> ValidatingActionForm, and let the coder decide if he needs validation when
> he redefines the "validate" method (and he can take a decision at that
> moment, as now he has access to the mapping and request parameters).
>
OK, now I see what you are after. I'm modifying the logic of processValidate()
to do the following basic steps:
* If there is no form bean, skip validation
* If the request was cancelled, skip validation
* Call the validate method:
* If no errors, continue normal request handling
by calling the action etc.
* (At this point, we know a validate error occurred)
* If this is a multipart request, roll it back
* If there is no input form defined, report an error 500
because the application is mis-configured (a form bean
is defined, but no input page to return to)
Does that sound right?
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Before deverting to a design comment, a documentation bug:
>
> The "input" attribute is declared mandatory if the "name" attribute is set,
> from the DTD.
>
> input Context-relative path of the input form to which control
> should be returned if a validation error is
> encountered.
> Required if "name" is specified, else not allowed.
>
> This check is not done, and I don't think we need it.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
In effect, isn't this the change implemented as described above? The new logic
catches this only if the validate() method returns false, which is really the
only time we care anyway. I will clarify that it's not required if your form
bean does no validation.
(I will comment on the design discussion in a separate message)
Craig
