</snip>
> 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>
-->
<map:flow engine="xyz">
<map:controller src="yyz"/>
</map:flow>
What do you think?
Cheers,
Reinhard
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr�mie sichern!
