cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: Changes made to flow system.js
Date Fri, 06 Dec 2002 15:07:03 GMT
Giacomo, Sylvain,

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:
>>
>>  
>>
>>> 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.
> 
> 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
mpo@outerthought.org                              mpo@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