Jing Zhou wrote: > * 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.
I believe Chain is suppose to be an implementation of the classic Chain of Responsibility pattern. Chain is something that a workflow engine might use, but I don't believe it is meant to a workflow engine itself.
> The "jump behavior" requirement is very obvious in > Java Server Faces Specification too. When the > renderResponse() is called on FacesContext, the control > is transferred to the Render Response phase after > the current phase. This is another evidence of the > "jump behavior" in high level pattern regulators.
Using a Context to assist with a workflow process seems reasonable. The Command should be able to examine the state of the Context and decide whether they should proceed or not.
In this case, renderResponse could be the postprocess on a Filter. A Command returns True, the Chain ends, and the Filters begin.
For the original use-case, where you just wanted to fast-forward to the end, again a Filter may be the solution. Once a Command returns True, the Filters start firing.
> I would like people to open mind and think, if we > add a method in Chain that allows us to execute > the chain starting with a given index (currently > the starting index is 0). Will that make the thing simple? > Or the idea is still disturbing somewhere?
Why not build another Chain? It's not a "there can only be only one" pattern. As many Chains can reuse as many Commands as needed.
-Ted.
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.
* 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? -:)
In another word, IMHO, low level language principles may not be applicable to high level pattern/structure regulators. Hope people re-think it.
I also recognize the facts that we do not want to overgrow
Chain into an xml based rule engine. It should be just chain.
But for such a simple requirement, one way is to model it
as a "if" decision (Craig way), another way is to model it
as a pseudo controller (Ted way). They are kind of cumbersome to use. It violates the "Simple thing should
be simple" principle - a principle that supercedes other
programming principles. The Filter thing could offer a
simple solution, but I haven't looked it in details yet.
The "jump behavior" requirement is very obvious in Java Server Faces Specification too. When the renderResponse() is called on FacesContext, the control
is transferred to the Render Response phase after
the current phase. This is another evidence of the
"jump behavior" in high level pattern regulators.
I would like people to open mind and think, if we add a method in Chain that allows us to execute the chain starting with a given index (currently the starting index is 0). Will that make the thing simple? Or the idea is still disturbing somewhere?
Jing
Netspread Carrier http://www.netspread.com
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
