cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: [RT] Generalizing the flow
Date Fri, 04 Jul 2003 23:39:15 GMT
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


Mime
View raw message