Chaining actions together is generally frowned upon. The primary reason is that it indicates that the actions are becoming an API unto themselves. This is often a bad idea since the intelligence you are putting into these various action is trapped within Struts and the web layer and cannot be reused.
The recommended approach is to look at the underlying operations these actions are performing, and refactor those operations into a facade or set of business objects that all the actions can share. Then, instead of chaining actions, have a single action call whatever methods it needs on the facade, or instantiate and execute whatever business objects are needed. That way you can do whatever you need to do from any action.
The underlying idea is that each Struts action should represent a single use case scenario. The scenario requires certain input (the ActionForm) and results in certain output (the ActionForward). Interally, the Action class should focus on selecting the appropriate business classes, handing these external classes whatever input they need, and deciding what to next.
Chaining an action often indicates that a business operation is embedded in an action. Business operations should be refactored out of the presentation tier, and into a business layer that you can control without the help of the HTTP protocol.
Of course, your mileage may vary. If you must chain actions (<frown/>), a simple solution is to add a "read-only" switch to the properties you want to set and share between actions. Then have the setter check the readonly property before changing the value.
if !(readonly) this.value = value;
Of course, this doesn't work with DynaActionForms. The next best thing is to add a helper bean to the context and have your actions prefer that to the ActionForm property. Something like
String id = fetchHelperId(request);
if (null==id) {
id = myForm.getId();
putHelperId(request,id);
}(which could be reduced to processHelperId(request,form)).
Incidentally, the reason you have to create a new ActionForward is that these are shared by all the clients and all the requests. If you change the ActionForward instance returned by findForward, you are changing it for the rest of the application as well. (Hence, the freezing.)
So, if you must add parameters to an ActionForward (<frown/>), a new instance must be created and returned by the Actions. (Which is why we return the ActionForward and not just the ActionForward name.)
-Ted.
Adam Hardy wrote:
I have two actions chained together. They both take the same formbean. The first is sectionInsert.do and the second, which sectionInsert forwards to on success, is sectionEdit.do
sectionInsert.do receives the properties of a Section in the request parameters, including id=0 where it is 0 because it does not exist in the DB yet. So it inserts the new Section into the DB and returns the new id, which is needed by sectionEdit to put into the html for the edit page.
I originally thought I could save the new id to the formbean and this would get passed on, but sectionEdit instantiates its own formbean and fills it with the request parameters - include id=0.
Is there an intuitive way of passing on the new id?
I already use sectionEdit.do as a first action by calling it with an id on a querystring, where the formbean picks it up. I would like to use a method that is easy for both these situations.
I'd appreciate any inspiration. Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
