cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Generalizing the flow
Date Fri, 04 Jul 2003 21:57:50 GMT

Christopher Oliver wrote:
> 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 

not really.
the paragraph just wants to say: you can't make the user click

and with purely reactive I mean there is a difference to regular 
(swing) apps: your app can never take own initiative to push a 
screen or information element to the end user

> becomes the client and the user at his browser becomes the server. The 

but a server that can decide not to respond for one thing...

> 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 

I understand what your saying (but have no means to prove that 

it's just a very thin line... when I look at a flowscript that 
after the sendPageAndWait is detecting which button was pressed...
whell, then I see quite some resemblance to event handling

but I am not the anti-flow guy... I know, I was cought in this 
trap before...
so believe me all the nice things in the wiki about flow are also 
from my hand (and my strong believe)

so, please do not place me in the corner of 

I just happen to think there is more out there...

and I think Sylvain did a great job at summarising which little 
changes could allow a nice coexistence for all...

> value. Attempting to add event handlers to sendPageAndWait simply 
> obscures and detracts from this value, in my opinion.

I agree, people that do nothing but webcontinuations can easily 
forget about events (although they are not obliged to, as do some 
existing examples show IMHO)


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

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message