struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: Spring and XWork in Ti
Date Thu, 01 Sep 2005 17:00:06 GMT
Joe Germuska wrote:
>> 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.
> I'm just wondering when this discovery was made.  I don't recall seeing 
> a lot of discussion about it.  I don't know enough about WebWork 
> interceptors to argue whether they are easier or not, although it seems 
> like if you really want to implement "around" style programming, they 
> would fit better, since the model with which Struts executes per-mapping 
> commands doesn't really give you anything to wrap around.  I guess you 
> can always make a chain with filters; I can't think of a time I ever 
> wanted to apply a solution like that, so it's pretty abstract to me.  I 
> just don't remember there being much discussion about whether commands 
> were easy or hard.

I'm referring to more to how chain worked before we added our own ActionContext, 
and even then, I personally find its "return true or false" unintuitive for 
process flow.  In that case, I find interceptors more practical, as they allow 
you to have code before and after processing that uses method variables.  With 
Chain, you have to use a Filter and even then, there is no way to share 
variables between the two blocks of code without instance variables which has 
its own problems.

That is not to say I don't like chain, but I think it is better suited for 
"chain of responsibility" needs rather than process flow, and when it comes to 
the end user, we should make things as easy and intuitive as possible. 
Interceptors, following the pattern of Servlet filters, does that, IMO.

XWork and WebWork have a ton of examples of interesting uses of interceptors, 
but one in particular is their WorkflowInterceptor, which brings Struts 
Classic-style workflow (populate, validate, if fails, goto input) to Ti/Webwork. 
  What is interesting is this is optional and can be replaced if a different 
workflow suites you better in a very straightforward way (see xwork.xml 
interceptor defs which will be annotations in Ti).

>> 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.
> Ti depends on commons-chain 1.0.  The LookupCommand in that version of 
> commons-chain treats a "true" return value from any called chain as a 
> signal to abort the entire chain processing.  Did Ti reimplement the 
> idea that some commands would ignore the return value from a 
> looked-up-chain, as has since been added to the unreleased SVN head of 
> commons-chain?  Or has that just not been noticed yet?

The key here is Ti doesn't have "one chain to rule them all", but periodically 
uses special purposes chains.  This form chain I'm referring to is not directly 
connected to the main processing chain at all, but is initiated by another 
component.  These special purpose chains I think matches the original intent of 
commons-chain better than as a limited workflow language, again, in my humble 
opinion :).


> Joe

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message