I think you're right that "continuation local" variables are needed to make implementing pagination easy. I just prototyped something as follows:
I created a page-local scope associated with the current continuation of sendPageAndWait accessible as "cocoon.page".
Anything assigned to cocoon.page will be stored in the continuation and retain the same values when the continuation is resumed (after sendPageAndWait()).
Very nice! Clever use of Rhino scopes can do wonders.
This is close to what I suggested, the difference being that I was more thinking to a dedicated class, i.e.:
var foo = new ContinuationLocal();
foo.value = 3;
cocoon.sendPageAndWait("bar");
foo.value = 4;
This approach allow ContinuationLocal variables to respect the usual variable visibility rules and avoid potential naming conflicts either between functions using the same property name for different purposes, or by recursive calls to the same function overriding the value of a higher-level call in the execution stack.
Now this ContinuationLocal class can easily be implemented using the page scope if a ContinuationLocal holds a randomly generated property name that's used to delegate value storage to page scope (not sure about the getter/setter syntax which is new to me):
function ContinuationLocal() {
this.name = generateUniqueRandomName();
this.value getter= function() { return cocoon.page[this.name]; }
this.value setter= function(value) { cocoon.page[this.name] = value; }
}
I personnally prefer this stricter approach to adding a new property on the Cocoon object. What do people think?
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
