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 :).
Don
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
