cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Date Thu, 09 Jan 2003 06:41:36 GMT
I'd like to start working on the control flow documentation ASAP and I 
was wondering what is the status on the naming convention proposal I 
made a while ago.

So far I've counted three +1 votes for reverting back to the old naming 
convention and providing the following aliases:

sendPage <=> sendPageAndWait (this function provides the blocking 
functionality, the response is sent, the continuation captured and the 
script execution stops)

sendPageAndContinue <=> sendPageNoWait (this function sends the 
response and continues the script execution)

Ugo expressed his -1 on it but I do hope he would change his opinion. 
Although he's not a committer I do value his opinion ;)

Most of the docs and presentations I've written so far refer to the old 
naming convention. All the past emails on the mailing list explaining 
what the control flow is and how it works use the old convention name, 
with sendPage() being the blocking function, not the pass-through one 
we currently have. I think is important to maintain this understanding, 
otherwise we'll end up confusing a lot of people.

Please cast your votes on whether you wish to revert to the old naming 
convention and providing aliases as described above and in the message 
cited below.

Best regards,
Ovidiu

On Monday, Dec 9, 2002, at 10:40 US/Pacific, Ovidiu Predescu wrote:

> 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 
> sendPageNoWait().
>
> 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.
>
> Regards,
> Ovidiu
>
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message