Craig McClanahan wrote:
* Regarding chaining of actions themselves, if you are using the standard
request processing chain that remains as bad an idea as it has always
been in Struts, and I don't see any reason to make it easier with chaining
than it is today.
Hi Craig. I was hoping you could explain 1) how people typically chain actions in struts 2) why it is a bad idea
I have some ideas for answers to both questions but I'd like to hear what you think.
Thanks, Bill
The code that is in the repository now has focused on providing a chain implementation that is fundamentally backwards compatible with existing Struts 1.1/1.2 functionality. As such, it emulates the current RequestProcessor architecture by passng all requests through a single commonly configured pipeline (which can, of course, be customized).
Going beyond strict backwards compatibility, there's lots of options:
* A chain can already invoke another chain using the generic LookupCommand capability. The "other" chain's name can be determined either literally (via the "name" property) or indirectly (via the "nameKey" property, naming a context property where some other processing logic has stored the name of the chain to be executed).
* Given this, it would be trivial, for example, to create a chain equivalent to the standard DispatchAction, which based the name of the chain to run on some request parameter, or other incomding characteristic on the request. In the "servlet-standard" chain, this technique is used to execute a user-defined preprocess chain if there is one, ignoring it otherwise.
* Alternatively, it would be possible to set things up so that the name of the action implicitly selects a correspondingly named chain (if there is one); defaulting to the standard chain if there is nothing special. That way you could customize the processing of individual actions without having to affect all of them.
* Regarding chaining of actions themselves, if you are using the standard request processing chain that remains as bad an idea as it has always been in Struts, and I don't see any reason to make it easier with chaining than it is today. Instead, a different approach is likely to be better -- for example, building a chain that forwards to a view named "foo" could automatically look up a setup chain (specific to that view) and execute it if it's there. This would likely eliminate many occurrences of the "setup action --> view --> process action" design that you see in lots of Struts code.
What a chain does is totally up to who designs the chain. Once you free yourself from a requirement to be backwards compatible (leaving the existing servlet-standard chain there for people that *do* want that), there's a lot of room to innovate. So, the answer to nearly all of yor questions is "yes, you can do that if you want to."
Craig
On Fri, 22 Oct 2004 20:23:28 -0400, David G. Friedman
<[EMAIL PROTECTED]> wrote:
I'm curious about Struts-Chain and have read through the 1.2.4 source on it plus the 1.3 SVN repository. I don't see anything suggesting how to make my action chain itself to another action in the struts-config.xml example. Nor do I see anything suggesting how to have an action be processed by a chain other than the default chain. Is struts-chain supposed to be as one chain per web.xml pattern matching? Are the chains supposed to do that and use a common struts configuration object? (I.e. Just /do/whatever invokes chain a but mapping /dothis/whatever3 invokes a different chain?
Thanks for any help.
Regards, David the Curious ([EMAIL PROTECTED])
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
