cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: Changes made to flow system.js
Date Mon, 09 Dec 2002 00:38:57 GMT
Stefano Mazzocchi wrote:

> Miles Elam wrote:
>> Stefano Mazzocchi wrote:
>>> Look at what sendPageAndWait() is supposed to do:
>>>  1) create the continuation object
>>>  2) store it someplace
>>>  3) get its id
>>>  4) invoque the sitemap with the required URI
>>>  5) pass the invocation parameters and the continuation id 
> You got me thinking that 'sendPage' (with and without 'AndWait') is 
> wrong semantics because it focus the attention on getting the page 
> out, instead of focusing on waiting until the data is received.
> 'waiting' in a continuation-wise sense, of course.
> i think that if we focus our semantics on the 'way-back' from the 
> client instead that on the 'way-up' to it, we might gain further 
> explicitness.
> What do you people think?
Yes, another way of looking at it is that (from the flow script's point 
of view) sendPageAndWait()

1) displays a form page in the client's browser
2) waits for the form to be submitted (which becomes available to the 
script as the cocoon.request property)
3) returns

So this function describes a round trip interaction. I believe in 
Christian Queinnec's original (scheme) code he called this function 
simply "show". Thus like "sendPage" his name focused on the first leg of 
the trip. Other names like,

  getUserInput(uri, bizData)

focus on the return leg of the round trip. I think both are valid 
(partial) descriptions of the function's behavior. I don't think one or 
the other is superior. And combined names like sendPageAndWait or 
sendPageAndGetUserInput() seem overly explicit and ugly.

So here are some other possibilities:

1)  Revert to the nice

   sendPage(uri, bizData);

instead of the ugly sendPageAndWait() and use something ugly and 
explicit like

   sendPageNoWait(uri, bizData);

instead of sendPageAndContinue();

2) Explicitly identify the input page, such as

    sendForm(uri, bizData); // block waiting for user input; 
cocoon.request contains the submitted request after this returns


    sendPage(uri, bizData); // send a page that won't return here; 
cocoon.request is invalid after this returns

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);



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

View raw message