cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [RT] Generalizing the flow
Date Fri, 04 Jul 2003 14:48:35 GMT

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

good conclusio

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

I don't think this "compatibility mode" is necessary because of the FOM we
have to refactor all examples.

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

I've already added this issue to the flow status page

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

some good reasons. I'm +1 with the renamings:

<map:call function="">   -->   <map:call flow="">
<map:call continuation="">   -->   <map:call state="">

If we change this we have to change this too, don't we?

  <map:flow language="JavaScript">
    <map:script src="flow.js"/>


  <map:flow engine="xyz">
    <map:controller src="yyz"/>
What do you think?


+++ GMX - Mail, Messaging & more +++

Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!

View raw message