cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Date Mon, 09 Dec 2002 18:40:44 GMT
OK, let's wrap up this discussion.

What I'll do is revert to the old naming and at the same time provide 
some useful aliases for the default functions.

sendPage <=> sendPageAndWait

sendPageAndContinue <=> sendPageNoWait

This means the sendPage() function will also be accessible as 
sendPageAndWait(), and sendPageAndContinue() will be accessible as 

Since in JavaScript functions are objects, if you don't like the 
default names you can just assign them a new name without any penalty 
in runtime performance:

var sendPageWithSomeNewIllustrativeName;

sendPageWithSomeNewIllustrativeName = sendPage;

and so on.

I'll make sure in the documentation we mention the above.

I would like us to spend our energy in discussing better things that 
names (and, ahem, implementing and documenting them). For some reasons 
discussions on names seem to provide the most heated debates.

We can also split the current functionality of sendPage in two 
functions as described by Marc and Giacomo, but I'd consider this 
functionality to be for advanced usages. This should be an alternative 
API for the much simpler sendPage API, and not a replacement for it. 
Several people on this list outlined this functionality, let's 
crystalize these discussions and come up with a good API for it.

Please cast your votes on:

- maintaining the old naming conventions and providing the above 
aliases for sendPage* functions; here's my +1.

- further discussions on an alternative API for sendPage; here's my +1.


On Monday, Dec 9, 2002, at 00:38 US/Pacific, Christian Haul wrote:

> On 08.Dec.2002 -- 03:48 PM, Stefano Mazzocchi wrote:
>> Hmmmm, hmmm, hmmm, ok, ok, what about something radically different 
>> like
>>  getUserInputFromScreen(uri)
>> to replace sendPageAndWait()?
> Only that this function returns void which is again misleading. I
> would expect a function named "get...." to return a value.
> I'm all with Christopher: revert to "sendPage" and have some ugly name
> for the special case where no continuation is created. But then we are
> back to start :-(
> Splitting it up like Marc suggested would be another option only that
> 95% will write their own wrapper around this since the natural use is
> all three together (create id + send page + create continuation). OTOH
> there would be interesting uses if one could slip in code between
> create id and send page.
> Of course we could split it up and provide a convenience function.
> 	Chris.

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

View raw message