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.
I mean a JS continuation is created and the script is suspended until the page is submitted by the browser as in sendPageAndWait().
Also, when you say:
page.commit(); <-- Continuation created here to handle submit of page and script is suspended
What do you really mean here?
Chris
