Thank you for quick response and your ideas about the implementation. But can I ask you why I can't use the second approach with struts 1.1. I explore struts-chain code once again and found that I only need to change 1 Command in servlet-standard chain.
And what means "provided for backwards compatibility with Struts 1.1" ? Will the next release replace Actions with something else? best regards, Konstantin On 13:50 Tue 11 Nov , Craig R. McClanahan wrote: > Quoting Konstantin Shaposhnikov <[EMAIL PROTECTED]>: > > > Hello all. > > > > If I understand corretly struts-chain package is used for > > modelling struts RequestProcessor using jakarta-commons chain library. > > > > That is definitely *one* use case for the chain of responsibility pattern. > > > When I've had heard this name I actually thought that this > > package is for composing struts actions as chain of commands > > and was very surprised when I found something different. > > > > So I what to know what do you think about described idea > > (define struts actions as chain of commands). I think that > > such functionality can be very usefull. Any comments > > are welcome. > > > > It certainly makes a lot of sense. For this purpose, you could do one of the > following: > > * In a Struts 1.1 world, create an Action that knows how > to set up an appropriate WebContext and delegate its work > to an appropriately named chain. Such an Action class could > be parameterized so it was reusable for any chain-based > definition of the required logic. > > * In a Struts 1.2 world (where, presumably, we base the actual > Struts RequestProcessor on commons-chain), you could customize > the standard processing chain to insert application specific > logic anywhere you need it, and/or replace the command that > executes a "real" Struts Action (provided for backwards > compatibility with Struts 1.1) with a call to an application > specific chain instead. > > Even outside the web tier, you might find the commons-chain impementation of the > Chain of Responsibility pattern useful as well. > > > best regards, > > Konstantin > > > > Craig > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
