cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow system.js]
Date Tue, 10 Dec 2002 20:36:28 GMT
Ovidiu, I know that some of you are somewhat frustrated by this 
'apparently nonsense' discussion on some trivial things like function 
names, but I personally think that a great deal of information was 
exchanged between people on flow and this is a great thing.

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.


> 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:
> 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

Ohhhh, nice!!!

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

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



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

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

View raw message