Recently, I had some private talks with Marc Portier about the flow : he was frustated by not grasping the pros and cons of continuations compared to the ReSTy approach he uses a lot. So we talked a bit and quickly came to the conclusion that the flow in Cocoon can be easily generalized to any flow management approach.
Marc gathered the ideas we exchanged (including wild ones !) in a wiki page at http://wiki.cocoondev.org/Wiki.jsp?page=GeneralizedFlow
The purpose of this post is to provide a synthetic view of this discussion and propose the little refactoring in the flow engine that would enable seamless integration of alternate flow controller implementations.
So let's go...
--- oOo ---
There are actually two main concepts behind the flow :
- user interaction : a user interaction is started when a flow function is started, we also often refer to this with "use case", "scenario" or simply "flow"
- interaction state : a particular stage in a user interaction. These are the continuations. We also refer to this with "flow state".
Now if we consider the other approaches that exist to control flow, we can distinguish 3 of them :
1 - continuation-driven flow (i.e. flowscript) : a user interaction instance produces a number of interactions and is able to go back and forth in these states
2 - state automata-driven flow : a user interaction instances only keeps a single interaction state
3 - stateless flow : this is just a simple controller that decides the view, but doesn't handle states between interactions.
What we can see is these flavors 2 & 3 can all fit in the continuation-driven model, if we consider flavor 2 as "continuations expire as soon as a new one is created", and 3 as "there's no sendPageAndWait(), but only sendPage()".
Now, if we look at the internals of the flow engine, we see that they're strongly tied to two specific concepts :
- Interpreter : the interpreter is actually a flow engine, capable of starting an interaction and managing the states
- WebContinuation : this is actually an interaction state (or "flow state")
--- oOo --- So here are the proposed refactorings :
1/ In the flow classes. These changes will be totally transparent to both existing sitemaps and existing flow scripts.
- rename "Interpreter" to "FlowEngine",
- rename "WebContinuation" to "FlowState", and accordingly "WebContinuationManager" to "FlowStateManager".
2/ In the sitemap language. These changes can be disruptive with existing sitemaps, but we can provide (although we aren't in beta) a compatibility mode :
- rename <map:call function=""> to <map:call flow=""> or <map:call controller="">
- rename <map:call continuation=""> to <map:call state="">
Additionally, according to Jeremy's RT, we can also change <map:parameter> from positional to the usual Map-type parameter passing convention. This new convnetion can be related to the use of <map:call flow="">, ensuring back-compatibility.
--- oOo ---
These somewhat minor changes will allow a greater variety of implementations of the Cocoon flow layer. And this is not only for the technical beauty of it, as there are a number of good reasons why we may want alternate implementations :
- some people (talking about personal experience with some customers) don't want to write their controller in JavaScript. They want it in Java. Although a continuation-enabled Java is not yet available, solutions exist to write this using plain old Java.
- some applications (this is Marc's case) must use an existing flow controller and so can't use the JS implementations.
So, as a conclusion : what do you think ?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
