struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Jouravlev" <>
Subject Re: Does Struts 2 solve the action chaining problem?
Date Thu, 30 Nov 2006 22:47:29 GMT
On 11/28/06, Tarek Nabil <> wrote:
> Hi,
> One of the problems with Struts was that if you had a page that requires
> some setup and this page submits to an Action, then you would not be
> able to set validate to true on that action because if validation
> problems occur then Struts will take you directly to the input JSP
> without performing the setup and your JSP wouldn't work.
> A solution to that would be to specify the input of the action as the
> setup action, which means you're doing action chaining and Struts is not
> good at that (it will reset your form among other things).
> The solution of choice for us so far was to call validate() ourselves in
> the action and if a validation problem occurs then we call the setup
> method (eventually you start using your action methods as an API which
> still was not good).
> Another problematic scenario is the case when you're editing some
> database record for example. When you go to your setup action for the
> first time, you will populate drop down lists for example, and then load
> the existing values from the database to your JSP fields. If the user
> attempts to save and some problem occurs then in the setup action, you
> will need to again populate the drop down lists, but you will NOT want
> to overwrite the user's inputs with the existing data. This is very
> similar to the first problem, but you would also need to pass some flag
> to the setup method to tell it whether to copy the data from the
> database to your ActionForm.

Struts 1.x works perfectly well in the above scenarios. You may want
to check out the overview of Struts action usage in  Struts wiki [1].
You can have one action handling both setup and input or you can have
two separate classes. Also, you can have two different action forms or
one action form.

Struts populates an action form automatically, which seems like too
much automation to me, but this cannot be changed now to ensure
backwards compatibility. The specifics of handling form bean
repopulation depend on chaining approach.

If you use in-server forwarding, then you will have to place a token
into the request object in the first action, and check this token in
the target action (actually, you will probably be checking this flag
in the form bean). If flag is there, this means that the action was
chained by forwarding, and you have to prohibit updating a form bean.
You can do this by putting an "if" into each and every setter of the
form bean. Quite clunky. If you use a different action form for a
chained action, you may want to define getters only, or to have setter
methods that do not correlate with URL parameters.

If you use redirection through browser, then just do not append any
parameters to the target URL, this way a redirected request will be
clean of parameters and Struts will not populate a form bean, because
it has nothing to populate with. What is more, you can use one
session-scoped form bean for both actions, it already has been set up,
so you don't it to reinitialize it.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message