On 4/21/05, Erik Weber <[EMAIL PROTECTED]> wrote: > That's the way I do it. If your Actions are light, as they should be, it > doesn't add a lot of code. Some redundant code is not a bad thing, it > can make things clearer. If you were to "chain" actions, then you'd be > going through the entire request processor chain again.
I'd even go so far as to say that callling a method on a facade from more than one action is not redundant. Instead, I would say that it's a good thing and proves that the facade is well factored. Typically, I recommend that Actions be used as "transaction scripts" [Fowler, PEAA]. The Action should call one or more methods on a facade to initiate and complete the business transaction, and then select the appropriate response. (Which is what I believe Erik and others on this thread also do.) Sometimes the response needs to be created by another Action, but this is not what we meant when we coined the term "Action Chaining". Action Chaining is using more than one action to complete the business transction *before* selecting the response. > I think that Struts 1.3, with chain of responsibility implementation, > should allow chaining of actions without causing redundant processing, > but I can't say for sure (at least I hope it does). In 1.3, we are using the Commons CoR to code the request processor. As a result, the Request Processor is easier to customize. For more about that see * http://wiki.apache.org/struts/WhyChain Developers might also want to use Commons CoR to create their own business facade. But the Commons CoR can be used with *any* version of Struts, or any version of anything for that matter. (Heck, I'm using a C# port of CoR with .NET.) With CoR, it's very easy to create transaction scripts by assembling the scripts (or "chains") from individual commands in a chain. In the instant example, "save" could be one command and *list* could be another. The benefit is that the Action would could call the "Xylophone" chain without knowing that it included "save" and "list *and* that you can change what commands are called by the "Xylophone" chain by editing the catalog XML document. For more about Commons CoR, see * http://jakarta.apache.org/commons/chain/cookbook.html Where CoR really shines is in the preparing rich forms that include multiple drop-downs and such. Each control can be populated by its own command. If you add or subtract a control to a page, you can edit the page and edit the catalog, and never touch the Action that calls the chain. What I really like is that I don't have to sweat the facade API. Before CoR, a lot of effort went into desiging the facade objects so that the individual methods would be easy to find (high cohesion). Now that the methods are individual commands, there's one less thing to design. :) Of course, the best part is that it's very easy to unit test the individual commands. If we need another drop down, I write a test and a command, when the test is green, I plug the command into the chain and add the control to the JSP. That's it. Over on dev@, the gang is getting ready to roll 1.2.7, which will hopefully go GA, and then we should be about ready to roll 1.3.0. We doubt that 1.3.0 will be GA, but we are eager to tap the keg. > > Erik --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
