cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Flow Scoping, was: JavaScriptInterpreter: bug or feature?
Date Thu, 20 Mar 2003 04:44:07 GMT
I'm combining two emails into one...

Christopher Oliver wrote:

> What defines an application in Cocoon.

Some (not necessarily root) sitemap and all of its subsitemaps can be 
seen as one application. Sub-sitemaps can be seen as sub-applications...

> For example, does each get a separate class loader? Is there a 
> relationship to sitemaps? 

Each sitemap gets own ComponentManager which is "component loader", COP 
(kind-of) equivalence of class loader. This component manager is 
configured in such a way that it inherits all components from the parent 
sitemap (

> What I'm trying to accomplish here is to share code between users 
> (meaning we don't have to duplicate immutable objects like scripts, 
> thereby saving memory).
> Perhaps you can help by explaining how and when instances of 
> JavaScriptInterpreter get created. Is it per sitemap?

Right now I think yes, InterpreterSelector (which is for some reason 
bound to Interpreter.ROLE instead of Interpreter.ROLE + "Selector") is 
created for every sitemap - means that it will create instances of 
Interpreters one per sitemap per language (currently JavaScript only).

> With Rhino, script variables are stored in a "scope" object - which 
> must be created on a per user basis. This is the "thrScope" variable 
> you see in However, it's possible to share 
> the built-in JavaScript objects, like String, Number, etc. as well as 
> scripts loaded by the sitemap (system.js, etc) since these are 
> immutable objects, among all the thrScope's. This shared scope is the 
> "scope" field in


> I only want to compile and execute the set of scripts that apply to a 
> specific application. I don't want them shared between different 
> applications. I think I remember Ovidiu saying that each (sub-)sitemap 
> should represent a single application. Does that make sense? If so, 
> would each one its own instance of JavaScriptInterpreter? 

I would suggest behaviour similar to the rest of sitemap components: 
flows defined in parent sitemap should be available in the subsitemaps. 
Is it possible from JavaScript POV - hierarchical organization of scopes?

Also, is it possible (from JavaScript POV) to have single place (per 
Cocoon instance) to store / cache / share all pre-compiled JavaScripts? 
(See - currently every instance of Generator will 
have own instance of Script)


View raw message