cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Lewis" <...@ascii27.net>
Subject Re: Changes made to flow system.js
Date Wed, 04 Dec 2002 22:33:20 GMT

what about I/O terms?

sendPageBlocking
sendPageNonBlocking

or something akin to these?

> 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                               <stefano@apache.org>
> --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------- To unsubscribe,
e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


-- 
"The heights of genius are only measurable by the depths of stupidity."



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


Mime
View raw message