struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <mr...@twdata.org>
Subject Re: Spring and XWork in Ti
Date Thu, 01 Sep 2005 15:26:27 GMT
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 <mrdon@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message