You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ovidiu Predescu <ov...@apache.org> on 2002/12/09 19:40:44 UTC
Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
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
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Ugo Cei <u....@cbim.it>.
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.
Oh no. Apart from stinking of FS, don't you think that this is going to
confuse the hell out of whomever is going to debug your scripts in the
future?
If I were a commiter, I'd express my -1 on this ;-).
> 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.
Agreed. I stopped following naming thread after the first two or three
messages. And I have already switched from sendPage/sendPageAndContinue
to sendPageAndWait/sendPage, so I'd like not to switch back. So my
proposal (not a vote) is to keep things as they are now, i.e. sendPage
and sendPageAndWait.
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de>
> On 09.Dec.2002 -- 10:40 AM, Ovidiu Predescu wrote:
>
> <snip/>
>
> > Please cast your votes on:
> >
> > - maintaining the old naming conventions and providing the above
> > aliases for sendPage* functions; here's my +1.
>
> +1
+1
>
> > - further discussions on an alternative API for sendPage; here's my +1.
>
> +1
-0
Konstantin
>
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>
> ---------------------------------------------------------------------
> 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
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 09.Dec.2002 -- 10:40 AM, Ovidiu Predescu wrote:
<snip/>
> Please cast your votes on:
>
> - maintaining the old naming conventions and providing the above
> aliases for sendPage* functions; here's my +1.
+1
> - further discussions on an alternative API for sendPage; here's my +1.
+1
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Ugo Cei <u....@cbim.it>.
Ovidiu Predescu wrote:
> 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 ;)
My opinion is biased by the fact that I've already started coding using
the new names, but I cannot tell you not to go on with whatever you've
decided just because I don't know how to do a global search&replace ;-).
What I don't like is the idea of having aliases. Beginners are going to
be confused by this, docs and examples will use one alias here and
another one there. So, my opinion is: pick whatever names seem more fit
and stick to them.
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Stefano Mazzocchi <st...@apache.org>.
Ovidiu Predescu wrote:
> 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)
I'm against aliases as well.
I'd say let's go for the new terminology and let's stick with that once
and forever.
People can do a find/replace for now but at least they won't find
scripts with all four methods floating around the internet.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Ovidiu Predescu <ov...@apache.org>.
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