cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject [RT] Generalizing the flow
Date Fri, 04 Jul 2003 13:59:36 GMT
Hi folks,

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

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 

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 
   - 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message