This is a good question that deserves a wiki writeup as I'm guessing I'll get asked it a lot :)

While chain and xwork interceptors do overlap some in theory, they overlap very little in practice. Chain is a general purpose, chain of responsibility pattern that is better suited, IMO, for general request processing, initialization, decision points, etc. XWork interceptors are more like Servlet Filters, and are specificly designed to intercept an action execution.

Just as we discovered Chain commands were difficult to use for Struts users (all the casting for one), Ti users will generally write interceptors and not chain commands. Interceptors are more natural, support around operations better due to easier use local variables, and provider easier access to the Action they are intercepting with no casting.

In Ti, while we do use chain for general request processing, where I think it really shines is decision points, something the CoR is built to solve. A good example is the chain that creates a form bean. A chain is called, and the first command that sees it can create it, does, then returns "true" as the responsibility has been assumed. So in summary, Ti developers will work with chains and some interceptors, while the average Ti application will only need to know interceptors.

Hope that helps,

Don


Ted Husted wrote:
On 8/31/05, Don Brown <[EMAIL PROTECTED]> wrote:

I should really list this out on the wiki site.  The short of it is XWork gives 
us an Action framework, interceptor
chains, expression language support, l18n, validation, and the value stack.


Do we need both interceptor chains and CoR chains?

Would it be possible to code a Struts Request Processor using an
XWorks interceptor chain?

-Ted.

---------------------------------------------------------------------
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]

Reply via email to