Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 45542 invoked by uid 500); 4 Dec 2002 21:04:24 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 45504 invoked from network); 4 Dec 2002 21:04:22 -0000 Message-ID: <3DEE6E66.70200@apache.org> Date: Wed, 04 Dec 2002 13:06:46 -0800 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Changes made to flow system.js References: <20021204112642.GA13596@fztig938.bank.dresdner.net> <3DEE00E5.80006@anyware-tech.com> <20021204134901.GE11504@fztig938.bank.dresdner.net> <3DEE09A2.4050203@anyware-tech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org