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've actually written a version of flowscript for Swing (using Rhino continuations), that allows you to write single-threaded multi-page 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.



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 design and use of flowscript (in order to support some other unspecified "flow engine", which to appears to not really have the same "interface" as the flowscript engine, IMO). To try to force them to use the same sitemap constructs seems unnecessary and counterproductive.

Regards,

Chris



Reply via email to