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.
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?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
