Re: Changes made to flow system.js

[Christopher Oliver]

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,

getReply()
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

and

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

Regards,

Chris


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]