cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow system.js]
Date Tue, 10 Dec 2002 20:54:22 GMT

>> 3) Punt on distinguishing this behavior with the name of the function.
>> Just add a third (optional) boolean parameter to indicate if it should 
>> block
>>    sendPage(uri, bizData, waitForInput);
> I like the above better.
> What I mostly like is the distinction between a 'form' and a 'page'.
> The way I've been programming web application is that POST and GET 
> actions should be connected to the same resource.
> I mean, if I have to POST something, first of all I GET it, then fill up 
> the form, then POST it, then get results. All good webapp frameworks try 
> to enforce the notion of this in-resource roundtripping.
> This is also because a page can contain *more* than one form.
> For this reason, I would propose to change the notion from 'form' to 
> 'screen' to avoid having the semantic collision between what a 'form' is 
> for flow and what a form is for HTML.
> So, my proposal would be
>   sendScreen(uri, data);
>     - sends the screen containing a form that will trigger a POST action 
> that will go back here
>     - blocks the execution of the flow until a request with the matching 
> continuation ID comes back
>    - returns with the cocoon.* objects filled with the latest client data
>  sendPage(uri, data);
>    - sends a page
>   (no further rountripping is expected from that page so no state is 
> transparently preserved)

Ugg, although I can see a semantic difference between a form and a page I'll
be darned if I can see a semantic difference between a screen and a page
(given that we're not dealing with page oriented media in most cases

>                                     - o -
> I have an alternative proposal, even if this requires more changes to 
> the system:
> Instead of "sendScreen", why don't we do:
>   var objectModel = getClientInput(uri,data);
> then
>  sendPage(uri);
> getClientInput will *implicitly* have a blocking semantics. I know this 
> explicitly outlines the third step, but IMO this solves one cognitive 
> problem that I had when Ovidiu first described the flow: how I get the 
> client data back from sendPage()?
> Having the data *explicitly* returned from the method invocation is, 
> IMO, a *GREAT* help.

Seems much better to me!

To unsubscribe, e-mail:
For additional commands, email:

View raw message