cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Generalizing the flow
Date Sat, 05 Jul 2003 12:41:22 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 
> 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



Mime
View raw message