cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
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 (SitemapLanguage.java:139)
...

> 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 JavaScriptInterpreter.java. 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 JavaScriptInterpreter.java.

<snip/>

> 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 JSGenerator.java:98 - currently every instance of Generator will 
have own instance of Script)


Vadim



Mime
View raw message