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