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:
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
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)
The problem I have with the proposed changes is that they obscure 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
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.
do you mean:
'obscuring' in terms of hiding their continuation focus in the naming?
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
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
