Note: This discussion can be applied to most any version of Struts, though I am specifically working with version 1.2.9.
Where, oh where, is the appropriate place to put code that sets up the request for a page? All of the examples are too simplistic and don't demonstrate this need. Everything in Struts seems to be based off of actions, but after an action, the request needs to be set up for the next page. While this could be done from the very same action, doing so doesn't seem entirely appropriate. The current action shouldn't have to know what needs to be set up on the next page.
Page A is a menu. From page A, you can follow a link to page B. Page B shows a department list. From that list, you can press an Edit link for each department. Doing so takes you to page C, a department edit screen. When page C is submitted, you are returned to page B.
Page B requires a certain amount of setup. Namely, a list of departments must be read from somewhere and then put into the request in order to build the list on the page. My first inclination would be to fire an action from page A that leads to page B. In that action, putting the list into the request takes place. An initialization action for page B, per se. This works fine for now.
Another action, clicking the edit link, takes you from page B to page C to edit department details. The only thing happening in this action is loading values into the form for that department.
But what happens when page C is submitted? There needs to be a save action that saves changes to the department. Makes sense. But how do you get back to page B? The department list needs to be put into the request; page B still needs to be set up. This could lead to two solutions. First, you could potentially jump from the "save page C" action over to the "setup page B" action, essentially calling two actions back to back somehow. Is this possible? And more importantly, is it appropriate? Second solution is to perform page B setup inside of the save action. This works, but is it appropriate?
The problem with the second solution is that it unnecessarily ties an action to it's result page. If you were to change the result page, you would have to find every action in the application that leads to that result page, and update it's setup code for the changed page. So you have duplicated code, and it's prone to errors.
The solution I have come up with is to use a modified version of the second option. Have a setup method for each page that exists within the Action class that will be forwarded to. Call this method immediately before calling mapping.findForward. Then, hopefully, most actions that will lead to this page will be related, and can be stored in the same DispatchAction class. Thus, every individual action within the DispatchAction class that goes to a particular page can call the same setup method immediately before forwarding to it (see example below). If anyone wishes to discuss this solution or propose other solutions, I'd be glad have a discussion.
It would also be possible to rename the "setupXxx" methods something more like "forwardToXxx", pass it the mapping as another parameter, and actually do the findForward call from within the forwardToXxx" method.
Action chaining will work, but you may have to be careful regarding how to access any shared form variables between the actions in your jsp.
The post redirect method will also help prevent multiple form submissions if the user hits reload on the department list after editing a department. Especially if you aren't using tokens.
There are pros and cons to each of the methods above, but they will both work and are both common design patterns.
Scott: It is good to see such an intelligent question with a thoughtful solution. I have never used DispatchAction but I do think that my project would be better off if I combined related searching, editing and saving operations into one action class. These operations are now performed by separate action classes.
I guess I use a solution like Dom mentions, but the implementation is different. If the flow is "Display User List" > "Display User Detail" > "Save User" > "Redisplay User List" then my save action would have a forward back to the action for "Display User List" with redirect set to true. Something like this: