"Craig R. McClanahan" wrote:
> 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?
This doesn't sound right to me at all.
I've always relied on the presence of the input field to perform validation or not,
and I think it's far more easier to switch validation on or off by setting this
entry rather than to do it in the code, using the mapping and or request. This is
just declarative vs programmative.
Here's a typical usecase I have that, if I'm not missing something, would have to
be modified if you made such a change:
- The user clicks on a link to change his personal information
- The action is configured with an actionForm, but without input, so that the
action can have access to the form, retrieve the info from the database, populate
the form, and forward to a JSP page. At this step, the form is empty, or just
contains the key of the user we're interested in.
- The user modifies the information and submits the form. This action is configured
to use the same form class, but now has an input parameter, so that the information
the user submits is now validated.
This design is used in a lot of cases, and I don't understand how validating the
form even if the input parameter is not there would help us, and I don't see what
it would add.
Am I missing something?
JB.
>
>
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 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
--
Jean-Baptiste Nizet
[EMAIL PROTECTED]
R&D Engineer, S1 Belgium
Kleine Kloosterstraat, 23
B-1932 Sint-Stevens Woluwe
+32 2 200 45 42
