Also, I think Chris is right on target with this, so, if you don't mind, I'll continue the discussion until we have reached consensus.
I know that javascript allows you to redefine your function names easily, but that's working around the problem and it doesn't help to create consensus, without with the community might develop friction and frustration even more than during the discussions.
Anyway, feel free to ignore this discussion if you don't care about it.
Christopher Oliver wrote:
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.
Yep.
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.
Very good description.
So here are some other possibilities:Ohhhh, nice!!!
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
What I like about this is that semantics are abstract enough to mean anything, but they don't confuse people!
more about this below.
3) Punt on distinguishing this behavior with the name of the function. Just add a third (optional) boolean parameter to indicate if it should blockI like the above better.
sendPage(uri, bizData, waitForInput);
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)
- 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.
What do you think?
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
