cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Melhem <micha...@fztig938.bank.dresdner.net>
Subject Re: Changes made to flow system.js
Date Fri, 06 Dec 2002 10:09:08 GMT
On Thu, Dec 05, 2002 at 10:45:38PM -0800, Ovidiu Predescu wrote:
> 
> 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.

Hi Ovidui!

> 
> 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.

Oh, I was under the impression that sendPage(AndContinue)() would
actually _exit_ the flow method because I have always used it (and seen it
used) like that. Sorry about the confusion!

So in this sense Wait/Continue _do_ fit well together semantically. ;)

> 
> >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 
> context.

Hmm...perhaps your right, with documentation (and time) we can dissassociate
Continue from continuations. 

> 
> >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.

Interesting, didnt think of that. So does this mean you can send
multiple pages back to the client without client intereaction.. ?

Regrads,
Michael Melhem
> 
> Cheers,
> Ovidiu
> 
> -- 
> Ovidiu Predescu <ovidiu@apache.org>
> http://webweavertech.com/ovidiu/weblog/
> 
> 
> ---------------------------------------------------------------------
> 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