cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: Changes made to flow system.js
Date Sun, 08 Dec 2002 04:41:49 GMT
Hi Marc,

Good to see you delving deep into this stuff!

On Friday, Dec 6, 2002, at 07:07 US/Pacific, Marc Portier wrote:

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

Yes, what you describe makes perfect sense. To avoid confusion though, 
the makeNewContinuation should be called makeNewContinuationId(), 
because it's not the function that creates the continuation, it only 
creates a continuation Id to passed by sendPage() in the generated 
response sent back to the client.

The idea is that you create the continuation id first, pass it in the 
View to be sent to the client, and only then you create the 
continuation object and associate it with the continuation id. 
Perfectly valid scenario.

The actual continuation has to be created by the waitForContinuation(), 
which should take the continuation id, create the continuation object, 
and associates them in the global continuations hash table. This 
function will essentially do what _sendPage() does today in system.js.

> >> 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 :-( )

Again, 'c' in the above example is not really the continuation, but the 
continuation id as I described above.

Yes, this makes perfect sense and is a good use case. The beauty of the 
continuations based control flow system is that even if the raw Cocoon 
doesn't support this kind of functionality, you as developer can 
implement it very easily with very few lines of code. Just tell me how 
much code you need to write this without control flow.

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

That's perfectly correct! You can do all sorts of nasty things, since 
you have complete control over the system. Again 'c' here should be a 
continuation id, not the true continuation.

> 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);

Which is indeed a big problem. That's why the default API is sort of 
idiot-proof and doesn't allow you to do this type of things. Advanced 
users could easily implement whatever they want.

Regards,
Ovidiu

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


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


Mime
View raw message