cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Changes made to flow system.js
Date Fri, 06 Dec 2002 06:45:38 GMT

On Thursday, Dec 5, 2002, at 02:13 US/Pacific, Michael Melhem wrote:

> On Thu, Dec 05, 2002 at 09:29:23AM +0100, Sylvain Wallez wrote:
>> Ovidiu Predescu wrote:
>>> I think the danger is to have the semantics of these functions
>>> associated with the way the response page is actually sent over the 
>>> wire.
>>> To reiterate my option, I think sendPageAndWait and
>>> sendPageAndContinue are still the best options. They also provide the
>>> maximum compatibility with the old naming, only sendPage dissapears,
>>> everything else is the same.
>> Agree. I think the confusion of "sendPageAndContinue" with 
>> continuations
>> came from the fact that the "sendPage" counterpart wasn't semantically
>> precise enough.
>> Most people seem to agree that "sendPageAndWait" is a good name. My
>> english skills tell me that "continue" is a good word as a 
>> complementary
>> to "wait". And since my skills are somewhat limited, it's likely that 
>> it
>> most people will have the same understanding as me :)
>> So, IMO, "sendPageAndWait" and "sendPageAndContinue", are good names,
>> being equally-precise and semantically complementary.
> Yes I agree (like most) that sendPageAndWait is the best name, because 
> it
> implies that flow "waits" here for a response. (even though 
> techinically
> this is not true)
> +1
> The "wait" here is in the context of the of the flow method...its the 
> flow
> method that waits..but continue in sendPageAndContinue makes sense 
> only in the
> context of the sitemap processing, its the sitemap that continues its
> processing. This requires a context change in understanding which I 
> find
> confusing (and breaks the wait/continue symmetry). Without this 
> context shift,
> one might think its that the flow method that continues - as apposed 
> to waiting.

No, Michael, is not the sitemap that continues the processing. 
sendPageAndContinue will _temporarily_ pass the control to the sitemap 
to generate the response. After the response is generated, the control 
is returned to the control flow script. The "Continue" refers to the 
fact that the function in which sendPageAndContinue appears will 
continue to execute, _after_ the response was sent back to the client.

> Also, a flow method need not have a "sendPageAndWait". Example:
> 	flow()
> 	{
> 	  .....
> 	  if (something)
> 	    sendPageAndContiue(page1)
> 	  else
> 	    sendPageAndContiue(page2)
> 	}
> so in this case, continue could be interepted as "create continuation" 
> as there
> is no "wait" to contrast it with.

It should not be. With the proper documentation (I know, I know ;) 
things should be clear on the meaning and "Wait" and "Continue" in this 

> So as for sendPageAndContinue, I vote
> -0.25 (hmm .. im not totally against it)
> Hmmmm..  we could end up disussing semantics forever,
> but how about "sendPageAndFinish" ? Thats the only alternative i can 
> think of
> at the moment. So one would have:
> 	flow()
> 	{
> 	  sendPageAndWait
> 	   ..
> 	  sendPageAndWait
> 	   ..
> 	  sendPageAndFinish
> 	}

"Finish" what? The problem with that is that you could still do things 
after the page was sent back to the client. Advanced users might want 
to use this fact to do all sorts of nasty things.


Ovidiu Predescu <>

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

View raw message