Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Thu, 5 Dec 2002 21:49:37 +0100 (CET)
From: Giacomo Pati <giacomo@apache.org>
Sender: giacomo@lapgp.otego.com
To: cocoon-dev@xml.apache.org
Subject: Re: Changes made to flow system.js
In-Reply-To: <3DEF129B.1090003@anyware-tech.com>
Message-ID: <Pine.LNX.4.44.0212052147430.2319-100000@lapgp.otego.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 5 Dec 2002, Sylvain Wallez wrote:

> Giacomo Pati wrote:
>
> >On Wed, 4 Dec 2002, Stefano Mazzocchi wrote:
> >
> >
> >
> >>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?
> >>
> >>
> >
> >As you said above the function does two things:
> >
> >  1. send a page
> >  2. does not wait
> >
> >So, how about splitting it into two function:
> >
> >  - sendPage
> >  - getAnswer
> >
> >
>
> Semantically speaking, this is a _really good_ idea, but... it
> unfortunately cannot be implemented that way :(
>
> The reason is that suspending the flow (with getAnswer) involves
> creating a continuation object, and that the page that is displayed
> (with sendPage) must know the ID of that continuation in order to put it
> in page links or form actions that will later on resume that continuation.

Ok, I'm not into the code so let me think...

How about

   sendPage (doing it without waiting for an answer)

and

   getAnswerFor( page ) (doing a wait)
   getReplyFor( page )

Giacomo

>
> So you would need in "sendPage" an information that is given later by
> "getAnswer". Chicken and egg problem which requires merging into a
> single function the operations of sending a page and waiting (or not)
> for the user's input.
>
> See o/a/c.components/flow/javascript/system.js for more details.
>
> Too bad...
>
> Sylvain
>
>


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