cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Managing Continuation Trees
Date Mon, 26 Jan 2004 00:29:29 GMT
Christopher Oliver wrote:

> There is a disadvantage to that approach, however, namely that it 
> creates new WebContinuations when you redisplay the page (i.e. when 
> sendPageAndWait is called again). The approach I suggested reuses the 
> same WebContinuation. Reusing the same WebContinuation also ensures 
> that the hierarchy of WebContinuations exactly matches the sequence of 
> pages (regardless of whether the page redisplayed, as in for example 
> Woody's validation loop), making back button handling easy.


Well, if I understood you right, ... you can't always just re-use old 
continuation, as it might have old (stale) data. Suppose you have:

var bkm = cocoon.makeWebContinuation();
// Get some data into continuation local variable
cocoon.local.x = java.lang.System.currentTimeMillis();
cocoon.sendPageAndWait("uri", {bookmark: bkm, bizData: cocoon.local.x});


So when you call sendPageAndWait second time (by invoking bkm), you can 
not reuse continuation from previous sendPageAndWait call as it contains 
stale business data.

Also, when you say:

> page.commit(); <-- Continuation created here to handle submit of page 
> and script is suspended


What do you really mean here?


Vadim


> Sylvain Wallez wrote:
>
>> Christopher Oliver wrote:
>>
>>> OK, I got you. What you want is a continuation that will cause a 
>>> page to be redisplayed. But I would suggest a different approach. 
>>> The idea is to associate two JS continuations with each 
>>> WebContinuation. The first is the "bookmark": it will cause the page 
>>> to be redisplayed. The second is the continuation used when the page 
>>> is submitted. However, in order to redisplay the page, the resources 
>>> needed for the pipeline associated with it will need to be 
>>> re-acquired as well (and then released again before the script is 
>>> suspended). How about the following to handle this:
>>>
>>> var page = cocoon.createPage();
>>>
>>> page.begin(); <-- Continuation created here to "bookmark" page
>>>
>>> // acquire resources needed to generate page
>>> var biz = ...
>>>
>>> page.send(uri, biz); <-- WebContinuation created here
>>>
>>> // release resources needed for pipeline processing
>>> biz = null;
>>>
>>> page.commit(); <-- Continuation created here to handle submit of 
>>> page and script is suspended
>>>
>>> Both JS continuations would be associated with the WebContinuation 
>>> created by
>>> page.send(), i.e:
>>>
>>>
>>> public class WebContinuation {
>>>
>>>   public WebContinuation getParent();
>>>
>>>   public Object getBookmarkContinuation();
>>>   public Object getSubmitContinuation();
>>>
>>>   public void setBookmarkContinuation(Object continuation);
>>>   public void setSubmitContinuation(Object continuation);
>>>
>>>   ...
>>> }
>>>
>>> The id passed to <map:call> would include an indicator of whether 
>>> handleContinuation() should select the bookmark or the submit 
>>> continuation.
>>>
>>> WDYT?
>>
>>
>>
>>
>> This looks interesting, however the number of use cases where the 
>> double-continuation is needed seems rather limited, and therefore 
>> always creating the "GET-able" continuation may be most often useless.
>>
>> I like Vadim's (b) proposal (modify makeWebContinuation to behave 
>> same as sendPageAndWait), as it's a simple "manual" way to create 
>> GET-able continuations where needed. These continuations can then be 
>> passed as view parameters in sendPageAndWait, to produce e.g. hrefs 
>> in the view.
>>
>> var bkm = cocoon.makeWebContinuation();
>> var biz = getBizData();
>> cocoon.sendPageAndWait("uri", {bookmark: bkm, biz: biz}, function() { 
>> releaseData(biz); });
>>
>> BTW, what about renaming "makeWebContinuation" to 
>> "createWebContinuation", which would be more consistent with 
>> "createObject"?
>>
>> Sylvain
>


Mime
View raw message