I haven't seen anyone mention the most common use of Action chaining, which is to process the form values from a submit, and use them to prepopulate a second page. Currently, this requires two Actions because there is no officially sanctioned method of instantiating a new form from an Action to be used on a subsequent JSP page. I think if we addressed this, the need for chained Actions would be greatly reduced.
James > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 2003 10:16 PM > To: Struts Developers List > Subject: Re: Action Chaining > > It is becoming commonplace to use an Action as a "front" for > a server page. This is not what people mean when they talk > about Action chaining. > > Some people start to use the Actions as finely-grained > business actions. > For example, they want to accomplish a "move" by forwarding > to a "copy" Action and then have the copy Action forward to a > "delete" > Action. So the point of forwarding to the next Action not to > complete the response, as contemplated by the architecture, > but to continue the business transaction. In essence, they > try to use Actions to create a Chain of Responsibility. IMHO, > that's out of scope for an Action class. > > It is true that we ask too much of the Action class. In fact, > we have been discussing the idea of adding another "View" > handler class, or a "page controller", to the ActionForward. > The idea being that the Action might nest a call to this > class (when specified) as part of the FindForward sequence. > The View class could then prepare the request for whatever > page it is designed to service. > > Tying it to the FindForward sequence keeps the calls to the > business layer within the Action lifecycle, but allows for a > separation of concerns. The Action class can focus on the > core business transaction, and the View class can focus on > preparing the request for its server page -- once the core > transaction is completed and the ActionForward is ready to be > selected. > > http://www.mail-archive.com/[EMAIL PROTECTED]/ms g1 > 8629.html > > It's just a matter of some interested party coming up with an > implementation for other people to try. > > For the other usage, where people have trouble creating a > finely-grained business API, there's a new Chain package in > the Commons sandbox that can help. This package makes it easy > to chain together arbitrary units of work, so that you can do > things like create a "move" command by chaining a "copy" > command to a "delete" command -- and still use "copy" > or "delete" on their own. > > -Ted. > > > Derek Richardson wrote: > > I was trying to avoid rehashing old arguments about action > chaining. I have heard two arguments: one, it is not > supported and can cause strange results and, two, it is > indicative of bad design (the argument made below). > > > > I disagree that action chaining is always indicative of bad > design. See my email on the users list (that got no > discussion, which I never understood) > http://marc.theaimsgroup.com/?l=struts-user&m=10437063942679 1& > w=2. I believe I made an original argument for action > chaining being almost required in a particular situation. > > > > In any case, I am not trying to force the committers to > make action chaining easier in the vanilla struts > distribution. I was merely hoping to get feedback if there is > an obvious problem with my approach. > > > > Perhaps I should have posted to the users list - I thought > that, since this deals with modifying the framework instead > of just implementing within it, that I'd get better feedback here. > > > > Thanks, > > > > Derek Richardson > > > > ------------------------------------------------------------ --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
