----- Original Message -----
From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Sent: Monday, October 13, 2003 5:39 AM
Subject: RE: Struts-chain Behavior Discussion
> *Question of Architecture*
>
> Does this mean that we have solved the hideous Action Chaining debate?
> In theory an Struts Action could be refactored to be a type of
> ``Command'' and therefor Actions could be chained.
Whenever there is a debate and each side seems to be very reasonable
in certain contexts, it is more likely the system itself is in-complete or
fails to meet the requirements. We use Controller Delegation Model
and/or Event Handler(s) to deal with such problems.
Commons-chain is not intended to solve that debate topic originally.
Last year, people found when they have two RequestProcessor(s), say
A and B, if they need to design a new RequestProcessor C that has
methods from both A and B, the best they can do is to let C extend
one of them, say A, and then copy the methods (possibly line by line)
from B. So a configurable RequestProcessor is somehow needed
to reuse portions of several RequestProcessor(s). This is what
commons-chain is intended to solve initially.
But the problems have not been cleanly solved in regard to reusability.
When a Command is deeply coupled with other Command(s) in a
chain through one or more flags/states in Context (say cancel flag,
invalid token flag, invalid validation flag, etc.) its reusability in a
different chain is very low in theory or very difficult to use (you need
to configure many flags to get it work and subject to the condition
the new Context offers the same set of flags).
I did a little exercise to reduce the command coupling degree by
introducing a NestCommand. Like LookupCommand to execute
a specified chain, NestCommand always return false regardless
what nested chain returns. So a termination of nested chains does
not force a termination of calling chains when NestCommand
is used. The following picture illustrates the idea:
Main Chain:
NestCommand
Nested Chain:
NestedCommand1
NestedCommand2
NestedCommand3
LastCommand
If any nested commands return true, the control flow will
*jump* to LastCommand. It seems to give an answer to my
original question without the notion of branch behavior :-)
NestedCommand2 does not need to check any flag set by
NestedCommand1 in this way and NestedCommand3 does
not need to check any flags set by NestedCommand1 and 2.
They could be reused in other chains without concerning about
flags.
Jing
Netspread Carrier
http://www.netspread.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
