Pierre Métras wrote:
> [snip]
> 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?
>
My thinking on multi-page forms is definitely not totally finished yet, but my
operating assumption has been that you'd have separate actions for each page, so
you could therefore direct errors back to the individual pages. The logical
"grouping" of the actions could happen by subclassing a common base class that
represented the shared logic. You would declare the same form bean for all of
these actions, and you'd store this bean in session scope. (As a side benefit,
you can also use "next" and "previous" logical forward names directly, without
having to calculate which page you are on in sequence, and then know what the
next and previous logical names are.)
It is still messy, because the validation method (at least) needs to know what
fields came from what pages, and there is no convenient way to communicate that
information so that it only needs to be specified once. I think that a final
solution to this is probably going to need to wait for a 1.1 time frame, when we
can figure out how to deal with it cleanly. I believe that the current approach
works quite well for single page forms (with the outstanding issue of people
that want to deal with dynamic sets of properties, rather than fixed ones, which
will need to be a separate extension if we decide to support it).
Thanks for all of your deep thinking on this, and thanks for sharing the
conversion experiences!
>
> Pierre Métras
Craig
