Hi Craig,
> >
> > > mapping.getInput() works OK if you have the "input" attribute set in
> > > the corresponding action tag in struts-config.xml
> >
> > Yes. I found that one later. I didn't investigate why it worked in
version
> > 0.5, perhaps due to new bugs that I introduced bugs when I rewrote my
> > struts-config.xml file.
> >
> > Also, I suggested yesterday a change in the
ActionServlet.performValidate
> > method to the struts-dev list, for calling the ActionForm.validate even
when
> > the "input" attribute is not set.
> >
>
> What would the controller servlet do if the validate() method returned
errors in
> this case? It doesn't know where to send the user back to (that's what
the
> input attribute is there to tell it), and there is no other current
mechanism to
> let the action that is called know that there were validation problems.
Yes, the "input" attribute is necessary when the validation fails, but not
when it succeeds!
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).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now, a long comment on design with Struts...
In fact, my opinion is not definitely set, when studying the Struts example,
and perhaps due to a design deviation...:
<!-- Edit mail subscription -->
<action path="/editSubscription"
type="org.apache.struts.example.EditSubscriptionAction"
name="subscriptionForm"
scope="request">
<forward name="failure" path="/mainMenu.jsp"/>
<forward name="success" path="/subscription.jsp"/>
</action>
<!-- Save mail subscription -->
<action path="/saveSubscription"
type="org.apache.struts.example.SaveSubscriptionAction"
name="subscriptionForm"
scope="request"
input="/subscription.jsp">
<forward name="success"
path="/editRegistration.do?action=Edit"/>
</action>
>From that extract, the check for validation will only occur on the
"saveSubscription" action only. A user can change his subscription
information, but defer the validation to the moment when that info is saved
to database.
This behavior can be interesting for multipages forms, but should we define
it in the configuration file or in the "validate" method?
The example uses a "N Action - 1 ActionForm" design that allows to define an
"input" attribute for each Action error processing, where I used a "1
Action - 1 ActionForm" one in my application:
<action path="/subscription"
...
name="subscriptionForm">
<forward name="init" path="/page1.jsp">
<forward name="editPage1" path="/page1.jsp">
<forward name="editPage2" path="/page2.jsp">
<forward name="save" path="/display.jsp">
<forward name="display" path="/display.jsp">
<forward name="exit" path="/menu.do">
</action>
I've used and <action> definition as a way to group related JSP pages, for
instance, editing and displaying a user subscription. Selecting between the
different sub-actions is done using a URL like
"/subscription.do?action=init". All treatments concerning the subscription
process are centralized in the "SubscriptionAction" class.
A problem with such a design is that when an error occurs, you can't
redirect to a default error page (it depends on the subaction you were
performing)... In that case, I would think that the "validate" function
should decide which error forward should be used:
validate()
- local validation on page 1 data
if error, forward to errorPage1
- local validation on page 2 data
if error, forward to errorPage2
- global validation
if error, forward to inputPage
Comments? Have others "missed" the original Struts design?
Now is not the time to change version 1.0 API, just before release (and now
that my application runs without it). But is it a desired extension for 1.1?
Pierre M�tras
