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 ProposalWith 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"/>.
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.
First of all, let me say that this event thing is one of the "wild thoughts" of the wiki page, and is not part of the proposed modification.
Now, what you say with continuations inverting the control is interesting. Let's compare continuation based webapps with Swing apps.
In a Swing app, you put widgets in a frame and attach event listeners to these widgets. How are these handled ? Well, the internal event loop waits for user click, and then finds the widget which was clicked and calls its event listeners. When we say that the event loop "waits", we can also consider that the program is "suspended", awaiting from system I/O.
Now consider a continuation based webapp. The displayed page (analogous to the Swing frame) contains several links and buttons (analogous to Swing widgets) each calling the same continuation with some distinguishing parameter (I purposely ignore here links starting a new flow). When the continuation is restarted, you have to test which one of the widgets was activated in order to execute the corresponding logic.
So you have constructs like :
sendPageAndWait("foo.html");
var action = cocoon.request.getParameter("action");
if (action == "next") {
doNext();
} else if (action == "prev") {
doPrev();
} else if (action == "cancel") {
doCancel();
} else if (action == "save") {
doSave();
}...Not really nice code, isn't it ? And painful and boring to type...
The event handlers mentioned in the wiki page are nothing more than a convenience utility allowing to replace the above by :
var handlers = { "next" : doNext, "prev" : doPrev, "cancel" : doCancel, "save" : doSave};
sendPageAndWait("foo.html");
handleAction(cocoon.request.getParameter("action"), handlers);
And that's all. And we called this event handlers, since it looks a lot like attaching event listeners in a Swing environment.
Now the wild thoughts pushed the idea even further and led to the idea of using the "handler" set by the flow script to produce the links in the view. All this is only a possible thing, if it matches the application needs, but in no way something that is, nor has to be, imposed.
Note also that this is possible with the current flow implementation and that the proposed changes have abolutely no relationship with this.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
