----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Friday, October 03, 2003 7:09 PM Subject: Re: Struts-chain Behavior Discussion
> Jing Zhou wrote: > > >It looks to me that I threw a disturbing idea. Now I change > >the subject for more discussions of different opinions. > > > >Craig mentioned the "go to" statement in programming > >languages and hinted it could be an evil if Chain implement > >the semantics of "go to" (I just called it "jump behavior"). > > > >If we recognize Chain as a high level pattern regulator, > >I would not agree such a comparison is appropriate > >unless someone could convince me the following > >observations are questionable. > > > >* I studied several workflow engines (not page flow stuff, they > > manage persisted workload for people) They all implement, > > one way or another, the "jump behavior". I could not see > > they violate the OO design principles as high level > > regulators. > > > > > You seem to be assuming that commons-chain is, or is intended to be, a > workflow engine. It's not. It's fundamental plumbing that might or > might not be used in the creation of a workflow engine, but would > certainly not be the only API exposed to users. I did not assume that commons-chain is (or intended to be) a workflow engine here. The two observations (including the Struts one below) tell me that there is nothing wrong to implement "jump behavior" in high level pattern regulators (or systems). They are not that kind of "evils" we see the "go to" in programming languages. > > >* Struts itself, as a MVC pattern regulator in its core, > > implements the "go to" semantics when Action returns a > > ForwardConfig. It does a "go to" the next page, right? -:) > > > Thus, Filter doesn't help you deal with control flow. Got it clear. Thanks for the details. > It's not just an issue of simplicity, it's an issue of necessity. You > haven't yet shown me a use case where commons-chain is the right design > pattern for implementing something, but it cannot be done (or cannot be > done gracefully) without the "start at index" or "skip this step" > capability. > Additionally, basing starting and/or stopping points on indexes into the > chain is horribly fragile -- as soon as I add or remove steps elsewhere > in the chain, I've just broken your logic, and introduced a bug in > something I did not directly change. That would be bad, so I'm also > opposed to the idea on technical grounds. > > Finally, even if you do have a use case that needs this capability, > there's nothing stopping you from implementing an extended Chain that > does it. I contend we should not put anything like that into the > fundamental APIs unless it's absolutely vital. > Evaluating a requirement to see if it is vital or not depends on how you order the rules to follow. For me, "Simple thing should be simple" is the top rule that supersedes any programming practices. Here are the issues I could see: * 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). * 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. * Basing index values for "jump behavior" is fundamentally flawed. I was aware of that. It has the similar problems as in the pseudo controllers (where each commands in between must honor a flag). To be honest, I have not used commons-chain yet, this is just an analysis from what I understand so far. The potential problems here is about the index-based binding in the Chain interface. The Chain interface bind commands based on the order the commands are added. So we can not jump to a logically named command in a chain. This makes the index-based jump the only possible way. * 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. * There are more issues. But I get to stop here for a clear view of my thinking. Again, this is derived from what I estimated from the codes. If any thing incorrect or there is already a solution to the problem, I'd be interested. At least, I have more understanding to commons-chain now :-) > Craig > Jing --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
