cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Changes made to flow system.js
Date Wed, 04 Dec 2002 21:06:46 GMT
Sylvain Wallez wrote:
> Michael Melhem wrote:
>> On Wed, Dec 04, 2002 at 02:19:33PM +0100, Sylvain Wallez wrote:
>>> Marcus Crafter wrote:
>>>> Hi Troops!
>>>>     Hope all is well.
>>>>     I've just checked in BZ#14903 which changes the names of the 
>>>> flow     sendPage* functions as previously discussed in the 'flow 
>>>> wishlist'     thread.
>>>>     Unfortunately the change is *not* backwards compatible so please 
>>>> be     careful and update any flow code you might have locally after 
>>>>     updating.
>>>>     The changes are:
>>>>     sendPage() becomes sendPageAndWait()
>>>>     sendPageAndContinue() becomes sendPage()
>>>>     The last one is the tricky one because the method names are 
>>>>     essentially swapped.
>>> Just some thoughts (sorry if this already has been discussed, I may 
>>> have missed it) : why not keeping the "sendPageAndContinue" ?
>> sendPageAndContinue is precisely the problem, many people were 
>> confusing "Continue" with continuations!
> Ah, ok, I understand... but I'm still uncomfortable with having a 
> precise "sendPageAndWait" and an imprecise "sendPage", as inconsistent 
> naming always leads to confusion.
> So, last try : what about "sendPageAndReturn" ?

I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn' 
that much, but it's true that 'sendPage' contains less semantic meaning 
than 'sendPageAndWait' and therefore might become a little confusing at 
first. It's a little bit semantically unbalanced and this doesn't 
reflect in their functional operation.

So, let's see, that method is supposed to 'send a page' to the client 
but is not going to wait for the client to come back and continue. So, 
the real name would be something like

  - sendPageAndDontWait

but that sucks.

  - sendPageAndReturn

is nice but only if you understand that the flow layer takes control 
over the sitemap and that 'return' means that you are returning from 
procedural continuation-based control (the flowscript) to declerative 
request driven control (the sitemap)

So it does have perfect sense for us, but I'm not sure it does for 
somebody that looks at the flowscript for the first time.

But I can't come up with anything better because

  - sendPageAndExit

might be even worse (people might think Cocoon might stop!)

Any idea?

Stefano Mazzocchi                               <>

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

View raw message