Ted Husted wrote:
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.)
Yes, that is a good explanation.
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.
When I speak of Action chaining, I mean to say a scenario where one action mapping's suggested forward path is not directly to a response generator (a JSP), but in fact to another mapped action (which will eventually forward to a response generator). I was advising against this (I know the tempation is there -- I have done it myself) because it causes all the dozen or so methods in the request processor "chain" to be executed again, redundantly in most cases, and also somewhat because of the "hidden" nature of the processing (which is also why I have avoided some genuine Struts niceties so far, but, let's face it, a strength of Struts is indeed declarative programming). I was imagining there might be a way, with the new controller, to put the request back through the chain but to somehow say, process X, process Y and process Z might be omitted, thus avoiding unnecessary processing, while letting process A, B, etc., occur again. This was merely a guess, and I could be way off, and am probably missing the point entirely as I haven't played with the new controller (or any of the Apache CoR stuff) yet.
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.
Thanks for the explanation. I will have to see some examples for it to sink in. I have been mainly using 1.1. I was wanting to upgrade, but have been waiting for 1.3 because of the major change. I'll be watching for the release. Please announce on this list. :)
Erik
Erik
--------------------------------------------------------------------- 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]
