Re: Struts-chain Behavior Discussion

[Craig R. McClanahan]

Jing Zhou wrote:

----- Original Message ----- 
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, October 04, 2003 10:37 AM
Subject: Re: Struts-chain Behavior Discussion

 

Jing Zhou wrote:
   

For me, "Simple thing should be simple" is the
top rule that supersedes any programming practices. 
     

Some of might say that this *is* a programming practice. Some might also 
couch it as start with "the simplest thing that can possibly work", and 
then let practice be your guide.
   

Only when the experiences they primarily have are coding (there are a lot
of other fields where the same rule is applied to).
 

* If I have 15 commands that needs to jump to the last one in a chain,
  if the branch way is used, then the last command must be repeatedly
 defined16 times in the config file. It loses the grace in expressions
 (although the sample config file does not reveal this problem).
     

Each Command can examine the Context to see if it can handle the current 
state. If it can't then it returns false, and processing continues. You 
don't need to "jump", you need a Command to define the appropriate state 
in your Context.

The fundamental problem might be viewing the Chain as the brains of the 
operation. It isn't. The Chain is just a composite of Commands. The 
Context manages state, and so the Context is where any decision making 
occurs.

   

* The "branch behavior" and "jump behavior" are complementary to
  to each other in theory. Repeatedly executing a set of commands in
  a chain can not be done gracefully in a *extreme* configurable
  chain.
     

Yes, it's possible that the branch behavior might not be the best way to 
go. I suspect that it might be better if a Command did not call other 
Commands, either directly or through the Catalog. But, I do think we 
should leave that door open so that people can experiment with this 
extension. I know in similar implementations, I often found myself 
having (the equivalent of) Commands calling Commands. But those 
implementations did not have a Chain to work with, and once we have more 
experience working with a real Chains, other strategies may become 
evident. I believe that at some point we may be able to dispense with 
branch behavior, so that very little happens behind the scenes. Or maybe 
not. Practice will dictate.
   

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.

 

* If in the end, the fundamental APIs do not want to deal with
  "jump behavior", I still could not successfully implement an
  extended Chain to make up the capability. From the original
  publication about the Chain of Responsibility, it does not
  dictate "jump behavior" is prohibited or "branch behavior" is
  only allowed. In my world view, the three behaviors are
  equally important: "sequence behavior", "branch behavior",
  and "jump behavior" in an extreme configurable chain.
     

IMHO, these behaviors out of scope for an implementation of the Chain of 
Responsibility pattern. Many implementations don't even return false or 
have the Filter backdoor. These are optimizations Craig made to help 
with resource-intensive operations. In many implementations, every 
Command on the Chain is visited, and there may not even be a guarantee 
that any of the Commands handles the request. I don't see "jump 
behavior" as an essential part of the CoR "world view". The 
boolean/Filter behavior is a stretch as it is, and it is probably as far 
we can go and still call it a GoF CoR.
   

Neither "sequence behavior" nor "branch behavior" are described
as essential parts of the CoR "world view". Since the three behaviors
are orthogonal to each other and commons-chain implements two
of them, thus in theory, it is *in-complete*. That is the research
direction I would like to point out to the community that we might
be able to complete it some how.
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.

For some applications, just "sequence behavior" is enough as you
mentioned before. But from the research point of view,
it has very little gain than using a single RequestProcessor. Since
commons-chain is also designed to be used in other environments,
for example, in business tiers, the community should put more efforts
to extract maximum possible functionality out of Chain.
 

Actually, our very own use case (RequestProcessor) is a perfect example 
of why using a chain instead of a base RequestProcessor class -- with 
nothing else -- is still more powerful.  Consider the dilemma I was in 
trying to implement the struts-faces library:

* I needed to implement my own RequestProcessor subclass to
 override some of the base behaviors.
* I want to integrate support for Tiles, which also requires its
 own RequestProcessor subclass, but not require it.
* Java doesn't support multiple inheritance.

With CoR, this is trivially solved by providing different standard 
chains that interweave the various commands as necessary (Struts 
standalone, Tiles standalone, Struts+Faces, Struts+Tiles, and 
Struts+Tiles+Faces).

 

-Ted.

   

Jing
 

Craig

---------------------------------------------------------------------
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]