Re: Struts-chain Behavior Discussion

[Craig R. McClanahan]

Jing Zhou wrote:

----- Original Message ----- 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 11:26 AM
Subject: Re: Struts-chain Behavior Discussion

 

Looks like you are asking less while I am asking more :-)

     

Exactly.  More == Bloat unless you really need it.  And I can't see that
I need it yet.
   

I did not see it until I was thinking a way to build user interfaces for
Chain.
If labeled commands could be regarded as implicitly defined chains, then
we have a shorter chain-config.xml for the following MAIN chain:
  <chains>
    <chain name="MAIN">
       <command jumpLabel="L1" className="Class1" />
       <command jumpLabel="L2" className="Class2" />
       <command label="L1" className="Class3" />
       <command label="L2" className="Class4" />
    </chain>
  </chains>
Where each labeld command defined a chain from
that command to the end. Thus the chain L1 contains
two commands and L2 contains one command.
Currently, to achieve the same behaviors, we have to
define two nested chains shown below. Note that the
chain B1 is equivalent to chain L1 and B2 is equivalent
to L2. The execution paths are identical between the
two MAIN chains, as I explained in the other
message. So "More" does not necessarily imply "Bloat"
and it is not my interests to bloat any systems
if not necessary.
  <chains>
    <chain name="MAIN">
       <command className="Class1" branchCommand="B1" />
       <command className="Class2" branchCommand="B2" />
       <command className="Class3" />
       <command className="Class4" />
    </chain>
    <chain name="B1">
       <command className="Class3" />
       <command className="Class4" />
    </chain>
    <chain name="B2">
        <command className="Class4" />
    </chain>
  </chains>
 

I actually think this is better, because you can customize *just* the B1 
path or *just* the B2 path if you want to, without having to mess with 
MAIN at all.

 

Please build something and show it to us, instead of talking about it.
It won't necessarily be a "chain of responsibility" pattern any more,
but it might well be interesting.  However, you still haven't even shown
me a practical use case where the functionality you're talking about is
required, and you still haven't shown me how you plan to get around the
fragile nature of subscripts.
   

As I wrote in the other message, it should be exactly the CoR pattern
without skipping commands.
Well, we already have that :-).

Just need to do some feasibility research
before someone could actually build it. Now we learned that
index-based "jump behavior" is fragile. So label-based one seems to
be the right choice.
And, we already have that too, by branching to labelled chains.

The remaining objection I see is to the verboseness of the 
configuration, which (as I mention above) is IMHO an advantage because 
the detailed subchains can be individually customized.

Looking at the possibility to do it without changing
core APIs is my first choice. Looks to me I need to store a label in
context per request thread for Chain.execute(), but what about
for non-web context is not clear to me yet (???) as well as how
I am going to add labeled commands to a chain (???)
Our real needs come from UI design requirements. We try our best
to give end users simple ways to do simple things first, such as
our phased validation model in Carrier. When we move to Chain,
we have to evaluate different UI design options.
 

UI workflows across requests are not what commons-chain is really for -- 
it's about designing the processing for a particular single request (in 
the case of Struts), or for decomposing the business logic generally in 
the business or persistence tiers.

However, it's also feasible to build branches and labels in by subclass 
CommandBase and ChainBase appropriately, instead of modify Command and 
Chain.  That would be the suggested way to prototype something.

 

Craig

   

Craig

Jing
Netspread Carrier
http://www.netspread.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]