cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Generalizing the flow
Date Sat, 05 Jul 2003 06:40:24 GMT

Christopher Oliver wrote:
> Marc Portier wrote:
>> 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 
>> not really.
>> the paragraph just wants to say: you can't make the user click
>> and with purely reactive I mean there is a difference to regular 
>> (swing) apps: your app can never take own initiative to push a screen 
>> or information element to the end user
> Sorry, but I don't see any difference here. AFAIK Swing apps are similar 
> to webapps in the respects relevant to this discussion.
> Swing apps have the same problem as web apps when it comes to multi-page 
> form style interactions (Wizards): they're very hard to write.

I see your point now

> I've actually written a version of flowscript for Swing (using Rhino 
> continuations), that allows you to write single-threaded multi-page 

wow, sounds really interesting

> Swing (even non-modal) wizards in JavaScript similar to the way you can 
> do it in XMLForm/JXForms (including automated support for back/next 
> navigation).
>>> becomes the client and the user at his browser becomes the server. The 
>> but a server that can decide not to respond for one thing...
> Yes, but that's the case with any remote server of any kind. I'm not 
> sure what your point is here.

in fact, re-reading it I start wondering myself,

did get your point on the 'relevant' area,
so I would need to think about it some more, this web-difference 
has been an idee-fix in my head for some years... thx for making 
me reconsidering this (I hate idee-fixes)

>>> 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 
>> I understand what your saying (but have no means to prove that assertion)
>> it's just a very thin line... when I look at a flowscript that after 
>> the sendPageAndWait is detecting which button was pressed...
>> whell, then I see quite some resemblance to event handling
>> but I am not the anti-flow guy... I know, I was cought in this trap 
>> before...
>> so believe me all the nice things in the wiki about flow are also from 
>> my hand (and my strong believe)
>> so, please do not place me in the corner of 
>> anti-webcontinuation-activist,
>> I just happen to think there is more out there...
>> and I think Sylvain did a great job at summarising which little 
>> changes could allow a nice coexistence for all...
>>>> scripts. 
> The problem I have with the proposed changes is that they obscure the 

do you mean:
'obscuring' in terms of hiding their continuation focus in the 

> design and use of flowscript (in order to support some other unspecified 

hm, unspecified should turn out as 'user defined', if we 
generalized it correctly this could help out some people IMHO

but: yes, its a long term vision to maybe never see some of those 
other engines end up in cocoon cvs through their own blocks

(although I really would like to give a shot at an implementation 
of the 2nd model (see wiki) which I consider usefull for more 
people then just me)

> "flow engine", which to appears to not really have the same "interface" 

which differences do you see?

mind that I'm not talking FOM here... as I see it the FOM is the 
interface the webcontinuation-flowengine is providing to its 
script-functions (probably based on what he is capable of doing 
through the common interface of course)

> as the flowscript engine, IMO). To try to force them to use the same 
> sitemap constructs seems unnecessary and counterproductive.

there is only 2 constructs involved, no?
-start an interaction --> create new state instance
-continue with one --> call back to state

I see a perfect fit, but please elaborate on what I possibly missed.

(the stateless impl would never call back to a state of course, 
so they are not hampered by the existance of a construct they 
don't need to use)

> Regards,
> Chris

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message