I see my remark wasn't that stupid after all (taking as an argument the fact the statistic unlikeliness of having exact equal idiots) Sorry, for not earlier reading deeper down the thread though...
only I'm not ready to give in yet...
is making a continuation really atomicly linked to sending a page? Your argumentation makes me see that:
Rather then 2 there are 3 concerns covered in the sendPageAnd...
I guess it's more like
makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest :-)
coming back on the expressed idea of splitting the methods up, it could make sense to thus split it up in 3 steps.
//1.
var continuation = makeNewContinuation();
// creates a URI in fact to talk about this continuation
//2.
sendPage("page from sitemap", continuation);
// allowing sendPage to insert the required links
...
//do other stuff if you like, other sendPages (see previous remark) should probably fail
//3.
waitForContinuation(continuation); // saves the current state of script vars and position into the ref
making it atomic makes it probably more idiot-proof, but access to the actual continuation object seems to open up a number of other interesting things:
>> reuse explicitely one of the previous continuations
suppose submission of form "start-sequence" triggers this script:
var c = makeNewContinuation();
sendPage("p1", c);
waitForContinuation(c);
sendPage("p2", c);
waitForContinuation(c);
sendPage("end-result"); // no continuation ref!
this would allow the user to follow this path:
start-sequence > {submit} > p1 > {submit} > p2 > {submit} > end-result
but also to proceed with {back|back} > p1 > {submit} > end-result
offering something I would call the 'should-only-pass-once-step-in-the-chain' (p2 in this example)
specially for larger wizard-like flows it could be nice to be able to 'skip' the steps that were already taken
(the real life example that would say that p2 could not just be up front of p1 in this case is missing ATM :-( )
it also seems to be a less memory-hungry way to implement something of the sort:
var result = startLengthyOperationAsync();
var c = makeNewContinuation();
while (!result.isReady()) {
sendPage("GoingStrongPleaseCheckBack.html", c);
waitForContinuation(c);
}
sendPage("showResult"); // no continuation argument!
all of this probably makes it harder to make it resiliant to script errors of course... what if
var c1 = makeNewContinuation();
sendPage("p1", c1);
waitForContinuation(c1);
var c2 = makeNewContinuation();
sendPage("p2", c2);
waitForContinuation(c1);
regards,
-marc=
Sylvain Wallez wrote:
Giacomo Pati wrote:On Wed, 4 Dec 2002, Stefano Mazzocchi wrote:Semantically speaking, this is a _really good_ idea, but... it unfortunately cannot be implemented that way :(
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
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.
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
-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
