Action Chaining

First, we usually define "action chaining" as creating a "move" action
by having a "copy" action forward to a "delete" action. Simply going
from one action to another isn't a classic example of harmful
chaining. The key point is whether only one action resolves the
business use case.

Classic action chaining is considered harmful because it implies that
the Actions have become a business facade. Any Action should be able
to call facade.copy and facade.delete from a move Action. Better yet,
the facade should provide a move method, and implement it any way it
likes. We should not feel like we need to reuse multiple Action
classes to solve one business use case. Struts 1 Actions were intended
to be what Martin Fowler calls a "transaction script", where "move" is
one transaction, not two.

The design of Struts 1 made action chaining difficult because s1
repopulates the request on every forward. When people start to use the
S1 actions as an API, they want to do things like change properites on
an ActionForm, and are surprised when the framework resets their

The Struts 2 group does discourgage classic Action chaining, because
it implies the business API is underdevelpoed. Albeit, we do provide a
action chaining result that copies the properties from one Action to
the next. The interceptor stack and result are processed for the
chained action, but the request doesn't pass back through the


So you can set a flag on the copy action and have it picked up by the
delete action. This is *not* considered an ideal practice, since
coupling individual Action classes complicates the API, but it's there
when people choose to use it.

So, yes, Struts 2 has an elegant solution for action chaining, if you
choose to use it.

Control preparation

As mentioned, Struts 2 solves the control population issue via the
preparable interface. Another solution is to use the action tag to
execute an Action in place.


One way to use this tag is to put a control on a "snippet" JSP that is
rendered as a result of an Action that does nothing but create the
object that populates the control. The action tag sets
"executeresult=true", then control markup will be "included" into the
page (like a tile), after the action executes.

In effect, exectuteResult actions can be used like a tag that can run
its own action before emitting the markup.


<%@ taglib prefix="s" uri="/struts-tags" %>
   <s:action name="languages" namespace="/ActionTag" executeResult="true"/>
   <s:action name="colors" namespace="/ActionTag" executeResult="true"/>


<%@ taglib prefix="s" uri="/struts-tags" %>
       tooltip="Choose Your Favorite Language"
       label="Favorite Language"
       headerValue="None"/> (execute)

   public String execute() {
       favoriteLanguages.add(new Select.Language("EnglishKey",
"English Language"));
       favoriteLanguages.add(new Select.Language("FrenchKey", "French
       favoriteLanguages.add(new Select.Language("SpanishKey",
"Spanish Language"));
       return SUCCESS;

struts.xml (Input, Languages)

       <action name="Input">
           <result type="plaintext">Input.jsp</result>

       <action name="Languages" class="app.Languages">

The advantage being that the "Languages" action could be dropped in
whereever the "Languages" control is needed, and that the Action for
the form doesn't need to know how to populate the Languages control.

Now, the Action is going to be hit every time the page is rendered,
but so long as you are using a caching data access layer, like IBATIS
or Hibernate, it will end up being a memory-to-memory transfer, rather
than a database access.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to