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...@verizon.net> on 2003/03/20 05:44:07 UTC
Flow Scoping, was: JavaScriptInterpreter: bug or feature?
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
RE: [RT] ParentAware components (was:Re: Flow Scoping, was...)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
+1
Carsten
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> <RT-starts/>
>
> This revives an idea I had a long time ago when writing the
> treeprocessor : "parent-aware" components.
>
> The elements in the <map:component> part of the sitemap are
> ComponentSelectors (CS) with a special behaviour : they know their
> "parent", i.e. the component that has the same role in the parent
> ComponentManager (handled by the parent sitemap), in order to implement
> component inheritance : if a CS is asked for a component it doesn't know
> of, it delegates the call to its parent. It is "parent-aware".
>
> This is not useful only for sitemap component selectors if we consider
> the fact that <map:components> is nothing more than an xconf file.
> Consider for example datasources : we have defined global datasources in
> cocoon.xconf, and want local datasources defined (and visible) only in a
> particular subsitemap. Currently, if we write <datasources> in
> <map:components>, we hide global datasources. If we used parent-aware
> selectors, we could _augment_ the set of available datasources. The same
> can be used for InputModules.
>
> Up to know, I thought this behaviour could be mostly useful for
> ComponentSelectors, but the Interpreter use case proves that it can be
> useful for "regular" (i.e. non-CS) components as well.
>
> Implementation-wise, I'm thinking of defininig parent-aware by a new
> lifecycle interfacee :
> public interface ParentAware {
> public void setParent(Object parent)
> }
>
> Any component implementing this interface will be given once (before
> initialize()) the object that implements the same role in the parent
> component manager.
>
> Thoughts ?
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
[RT] ParentAware components (was:Re: Flow Scoping, was...)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christopher Oliver wrote:
> OK. I think you could get that effect by modifying
> JavaScriptInterpreter.set/getSessionScope(). Right now these associate
> the scope with the uri prefix of the current environment. Instead, to
> get the behavior you describe, I guess it should be associated with
> the top-most parent of the current sitemap that has a flow defined in
> it. Any ideas on how to implement that?
What if a JavaScriptInterpreter was able to know the
JavaScriptInterpreter that exists in the parent sitemap ?
<RT-starts/>
This revives an idea I had a long time ago when writing the
treeprocessor : "parent-aware" components.
The elements in the <map:component> part of the sitemap are
ComponentSelectors (CS) with a special behaviour : they know their
"parent", i.e. the component that has the same role in the parent
ComponentManager (handled by the parent sitemap), in order to implement
component inheritance : if a CS is asked for a component it doesn't know
of, it delegates the call to its parent. It is "parent-aware".
This is not useful only for sitemap component selectors if we consider
the fact that <map:components> is nothing more than an xconf file.
Consider for example datasources : we have defined global datasources in
cocoon.xconf, and want local datasources defined (and visible) only in a
particular subsitemap. Currently, if we write <datasources> in
<map:components>, we hide global datasources. If we used parent-aware
selectors, we could _augment_ the set of available datasources. The same
can be used for InputModules.
Up to know, I thought this behaviour could be mostly useful for
ComponentSelectors, but the Interpreter use case proves that it can be
useful for "regular" (i.e. non-CS) components as well.
Implementation-wise, I'm thinking of defininig parent-aware by a new
lifecycle interfacee :
public interface ParentAware {
public void setParent(Object parent)
}
Any component implementing this interface will be given once (before
initialize()) the object that implements the same role in the parent
component manager.
Thoughts ?
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Flow Scoping, was: JavaScriptInterpreter: bug or feature?
Posted by Christopher Oliver <re...@verizon.net>.
OK. I think you could get that effect by modifying
JavaScriptInterpreter.set/getSessionScope(). Right now these associate
the scope with the uri prefix of the current environment. Instead, to
get the behavior you describe, I guess it should be associated with the
top-most parent of the current sitemap that has a flow defined in it.
Any ideas on how to implement that?
Regards,
Chris
Marcus Crafter wrote:
> On Thu, Mar 20, 2003 at 01:30:42PM -0500, Vadim Gritsenko wrote:
>
>>Marcus Crafter wrote:
>><snip/>
>>
>>> For systems where a subsitemap represents a new application,
>>> behaviour would be configured to be as it currently is.
>>
>>Why not: for systems where a subsitemap represents a new app, dont
>>declare anything in the parent sitemap you don't want to expose to
>>subsitemap! :-)
>>
>>This will be consistent with the rest of Cocoon - otherwise somebody
>>will ask for sitemap which does not inherits, say, generators...
>
>
> Good point. :)
>
> Cheers,
>
> Marcus
>
Re: Flow Scoping, was: JavaScriptInterpreter: bug or feature?
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Thu, Mar 20, 2003 at 01:30:42PM -0500, Vadim Gritsenko wrote:
> Marcus Crafter wrote:
> <snip/>
>
> > For systems where a subsitemap represents a new application,
> > behaviour would be configured to be as it currently is.
>
> Why not: for systems where a subsitemap represents a new app, dont
> declare anything in the parent sitemap you don't want to expose to
> subsitemap! :-)
>
> This will be consistent with the rest of Cocoon - otherwise somebody
> will ask for sitemap which does not inherits, say, generators...
Good point. :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Flow Scoping, was: JavaScriptInterpreter: bug or feature?
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Vadim Gritsenko" <va...@verizon.net> wrote:
> Marcus Crafter wrote:
> <snip/>
>
>> For systems where a subsitemap represents a new application,
>> behaviour would be configured to be as it currently is.
>
> Why not: for systems where a subsitemap represents a new app, dont
> declare anything in the parent sitemap you don't want to expose to
> subsitemap! :-)
>
> This will be consistent with the rest of Cocoon - otherwise somebody
> will ask for sitemap which does not inherits, say, generators...
Agreed wholeheartedly...
Pier
Re: Flow Scoping, was: JavaScriptInterpreter: bug or feature?
Posted by Vadim Gritsenko <va...@verizon.net>.
Marcus Crafter wrote:
<snip/>
> For systems where a subsitemap represents a new application,
> behaviour would be configured to be as it currently is.
>
Why not: for systems where a subsitemap represents a new app, dont
declare anything in the parent sitemap you don't want to expose to
subsitemap! :-)
This will be consistent with the rest of Cocoon - otherwise somebody
will ask for sitemap which does not inherits, say, generators...
Vadim
Re: Flow Scoping, was: JavaScriptInterpreter: bug or feature?
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Thu, Mar 20, 2003 at 09:43:06AM -0800, Christopher Oliver wrote:
> Marcus Crafter wrote:
> >On Wed, Mar 19, 2003 at 11:44:07PM -0500, Vadim Gritsenko wrote:
> >
> >>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?
> >
> >
> > I tend to agree Vadim. Allowing the hierarchical organisation of flow
> > scripts and variables would solve the cross-sitemap issues I
> > outlined in my previous email.
> >
> > For the cases where subsitemaps represent new applications, perhaps
> > this 'inheritence' behaviour could be made configurable at each
> > sitemap level ?
> >
>
> OK. Can you describe an example application that is organized this way,
> so I can picture what this would look like?
Ok, thinking out loud here:
Let's say that our sitemaps (for a single application) are
arranged like this:
root
|
|-----------|
sub #1 sub #2
Then JavaScript methods and globals defined in the 'root' flow (if
configured to be inheritable) would be available in the lower
level sub #1/#2 sitemaps.
ie. using the example I had before:
root.js:
var currentUser = null;
function login()
{
// assume valid user
cocoon.createSession();
currentUser = new User(usename);
// continue and send Page.
}
sub-1.js:
function someProcessing()
{
// currentUser already set by login()
if (currentUser.someCheck())
{
// do the processing
}
}
That allows common script methods to be placed in the root.js
(reuse), and globals to be valid across subsitemaps (cross sitemap
communication).
For systems where a subsitemap represents a new application,
behaviour would be configured to be as it currently is.
Thoughts ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Flow Scoping, was: JavaScriptInterpreter: bug or feature?
Posted by Christopher Oliver <re...@verizon.net>.
Marcus Crafter wrote:
> On Wed, Mar 19, 2003 at 11:44:07PM -0500, Vadim Gritsenko wrote:
>
>>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?
>
>
> I tend to agree Vadim. Allowing the hierarchical organisation of flow
> scripts and variables would solve the cross-sitemap issues I
> outlined in my previous email.
>
> For the cases where subsitemaps represent new applications, perhaps
> this 'inheritence' behaviour could be made configurable at each
> sitemap level ?
>
OK. Can you describe an example application that is organized this way,
so I can picture what this would look like?
Re: Flow Scoping, was: JavaScriptInterpreter: bug or feature?
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Wed, Mar 19, 2003 at 11:44:07PM -0500, Vadim Gritsenko wrote:
> 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?
I tend to agree Vadim. Allowing the hierarchical organisation of flow
scripts and variables would solve the cross-sitemap issues I
outlined in my previous email.
For the cases where subsitemaps represent new applications, perhaps
this 'inheritence' behaviour could be made configurable at each
sitemap level ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&: