cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: [RT] Generalizing the flow
Date Fri, 04 Jul 2003 19:36:50 GMT
I think I see why Marc is confused about the flow approach. In his Wiki 
he restates this fundamental misunderstanding:

>         5. Names, Definitions and Design Proposal
> Now, off for a question: How do you control your webapp?
> As a developer? You don't! The web is purely re-active. The end-user 
> (browser) is in charge at all times by the mere pull nature of the 
> web. It's his/her click (incoming HTTPRequest) that is deciding what's 
> up next. The smart developer however immediately understands that 
> dynamically generated HTML, showing an abundance of seducing widgets 
> is in fact exposing only a very limited list of sensible 'next' 
> actions the end user can engage upon. Indeed it is only declaring 
> those URI's to be followed by the end user.
With the flow approach this isn't always true. It is indeed the case 
when the user selects a link to a top-level function in a flow script. 
Here the webapp is a server and the client browser is invoking one of 
its services. This corresponds to <map:call function="blah"/>.

However with continuations, control  becomes inverted: the webapp 
becomes the client and the user at his browser becomes the server. The 
sendPageAndWait() function can be thought of as "calling" the user at 
his browser (to fill in a form for example) and the  <map:call 
continuation="..."/> construct can be thought of as "returning" the 
result of this call to the webapp.

Thus there is a peer-to-peer relationship between the webapp and the 
user. Sometimes the browser "calls" the webapp, sometimes the webapp 
"calls" the browser. Some links in the page represent "calls" to the 
webapp and others (the ones that contain continuation ids) represent 
"returns" from a call to the browser.

However the flowscript approach is clearly _not_ event-driven (from the 
developer's point of view) but purely sequential. This is also its great 
value. Attempting to add event handlers to sendPageAndWait simply 
obscures and detracts from this value, in my opinion.


Sylvain Wallez wrote:

> 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 
> 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

View raw message