You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2004/01/23 01:57:29 UTC
Re: Managing Continuation Trees
Vadim Gritsenko wrote:
<snippp/>
> I'm in favor of (b) as it is more consistent. So, my proposal is:
>
> (a) Modify makeWebContinuation to behave same as sendPageAndWait
> w.r.t. lastContinuation
> (b) Expose makeWebContinuation in the Javascript.
> (c) Using makeWebContinuation, system.js can be extended to include
> bookmark() Javascript function.
>
> WDYT?
Guys, comments?
PS in case js attachment got blocked, original email is here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107479669416699
Vadim
Re: Managing Continuation Trees
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
<snip/>
> And one more thing: makeWebContinuation currently is not consistent.
> Let's first make it consistent with sendPageAndWait, and all other
> modifications / additions can happen in addition to this fix. Do we
> have an agreement on this?
+1. Increased consistency never hurts ;-)
> And we can expose it as "createWebContinuation", as Sylvain suggested.
+1
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Managing Continuation Trees
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Christopher Oliver wrote:
> Ok, I just committed changes that implement createWebContinuation().
> The support for continuation local variables is also included.
It works! At least it seem to ;-)
Vadim
Re: Managing Continuation Trees
Posted by Christopher Oliver <re...@verizon.net>.
Ok, I just committed changes that implement createWebContinuation().
The support for continuation local variables is also included.
Regards,
Chris
Vadim Gritsenko wrote:
> 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.
>
>
>
> <snip/>
>
>
>> Sylvain Wallez wrote:
>
>
> <snip/>
>
>>> 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.
>>
>>
>
>
> And one more thing: makeWebContinuation currently is not consistent.
> Let's first make it consistent with sendPageAndWait, and all other
> modifications / additions can happen in addition to this fix. Do we
> have an agreement on this?
>
> And we can expose it as "createWebContinuation", as Sylvain suggested.
>
> Vadim
>
>
Re: Managing Continuation Trees
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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.
<snip/>
> Sylvain Wallez wrote:
<snip/>
>> 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.
>
And one more thing: makeWebContinuation currently is not consistent.
Let's first make it consistent with sendPageAndWait, and all other
modifications / additions can happen in addition to this fix. Do we have
an agreement on this?
And we can expose it as "createWebContinuation", as Sylvain suggested.
Vadim
Re: Managing Continuation Trees
Posted by Sylvain Wallez <sy...@apache.org>.
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.
Ah yeah, reuse of continuations is something I've got to investigate,
namely in Woody as you rightly point out. I tried to analyze JXForm's
flow stuff, but failed to, as I got lost between the different form
phases and continuation reuse. Can you give some clue on how we should
refactor the woody redisplay loop?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Managing Continuation Trees
Posted by Christopher Oliver <re...@verizon.net>.
Vadim Gritsenko wrote:
> 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.
You're right, but it can be shared if no ContinuationLocal variables are
used. This is another reason to try to avoid the overhead of
ContinuationLocal variables.
>
> Also, when you say:
>
>> page.commit(); <-- Continuation created here to handle submit of page
>> and script is suspended
>
>
>
> What do you really mean here?
>
I mean a JS continuation is created and the script is suspended until
the page is submitted by the browser as in sendPageAndWait().
Chris
Re: Managing Continuation Trees
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
>
Re: Managing Continuation Trees
Posted by Christopher Oliver <re...@verizon.net>.
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.
Regards,
Chris
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
>
Re: Managing Continuation Trees
Posted by Sylvain Wallez <sy...@apache.org>.
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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Managing Continuation Trees
Posted by Christopher Oliver <re...@verizon.net>.
BTW, with this approach you can easily implement a "Back" button. You
simply invoke the parent WebContinuation's bookmark continuation.
Regards,
Chris
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?
>
> Chris
>
> Vadim Gritsenko wrote:
>
>> Vadim Gritsenko wrote:
>>
>> <snippp/>
>>
>>> I'm in favor of (b) as it is more consistent. So, my proposal is:
>>>
>>> (a) Modify makeWebContinuation to behave same as sendPageAndWait
>>> w.r.t. lastContinuation
>>> (b) Expose makeWebContinuation in the Javascript.
>>> (c) Using makeWebContinuation, system.js can be extended to include
>>> bookmark() Javascript function.
>>>
>>> WDYT?
>>
>>
>>
>>
>> Guys, comments?
>>
>> PS in case js attachment got blocked, original email is here:
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107479669416699
>>
>> Vadim
>>
>>
>
>
>
Re: Managing Continuation Trees
Posted by Christopher Oliver <re...@verizon.net>.
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?
Chris
Vadim Gritsenko wrote:
> Vadim Gritsenko wrote:
>
> <snippp/>
>
>> I'm in favor of (b) as it is more consistent. So, my proposal is:
>>
>> (a) Modify makeWebContinuation to behave same as sendPageAndWait
>> w.r.t. lastContinuation
>> (b) Expose makeWebContinuation in the Javascript.
>> (c) Using makeWebContinuation, system.js can be extended to include
>> bookmark() Javascript function.
>>
>> WDYT?
>
>
>
> Guys, comments?
>
> PS in case js attachment got blocked, original email is here:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107479669416699
>
> Vadim
>
>