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"/>.
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.
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.
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 http://wiki.cocoondev.org/Wiki.jsp?page=GeneralizedFlow
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
