Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40145F69.6090209@reverycodes.com>
Date: Sun, 25 Jan 2004 19:29:29 -0500
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Managing Continuation Trees
References: <400E93B3.8010100@reverycodes.com> <400E9568.2060106@verizon.net>
 <400E9766.5050806@reverycodes.com> <400E9DA0.20706@verizon.net>
 <400EA064.4020502@reverycodes.com> <400EC1CC.8050801@verizon.net>
 <bumr7h$nlo$1@sea.gmane.org> <400EF667.9010500@verizon.net>
 <400EFB69.9000505@reverycodes.com> <400F46DB.9010800@verizon.net>
 <4010184E.20502@reverycodes.com> <40107179.5010407@reverycodes.com>
 <4012FAF1.5050604@verizon.net> <bv1dkl$mmo$1@sea.gmane.org>
 <40144075.5030109@verizon.net>
In-Reply-To: <40144075.5030109@verizon.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>