In a nutshell, Action Chaining is the practice of returning a non-redirect ActionForward which points to a Struts action path. This is chaining (where a redirect isn't) because it results in the ActionServlet triggering a second "run" through the RequestProcessor's processing flow.
Many developers find this an effective way to organize their web applications. However, it is important to note that this is not a supported way to use Struts. The RequestProcessor is designed with the assumption that it is executed once per HTTP request. Sometimes Action Chaining is used as a work around for an application which is not cleanly designed.
An earlier author wrote on this page:
One might argue that the normal flow of a Struts-based application would be similar to this: jsp -> /action -> jsp Some people (including myself) prefer this approach jsp -> /processaction -> /prepareviewaction -> jsp
so again, this is evidence that people use this method successfully. This topic has been discussed exhaustively on the StrutsUserMailingList.
Ted Husted wrote:
IMHO, Action chaining is linking three or more Actions together. (e.g., three points determine a chaine :0) Simply forwarding from one Action to another, so the second can select the page and complete the response, is an ordinary and expected use of the framework.
The "evil" part is when people start using the Action objects as an API and want to pass (new) parameters from one Action to another, either by changing the properties on the ActionForm or by creating a new query string on the fly. The danger here is that the Action *classes* become coupled and start looking like a mess of "GOTO"s.
While there could be exceptions, this usually indicates that there is not sufficient separation between the Action classes and the business tier. Why? Because if I have a decent business facade, I shouldn't have to kludge-around with setting new properties on an ActionForm or as a request parameter. I should be able to code directly to the business facade.
-Ted.