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 04:20:33 UTC
JavaScriptInterpreter: bug or feature?
Can somebody knowledgable comment on the following method? Local
variable scope is not used...
private Script compileScript(Context cx, Scriptable scope,
Source src) throws Exception {
InputStream is = src.getInputStream();
Reader reader = new BufferedReader(new InputStreamReader(is));
// FIXME: scope or this.scope?
Script compiledScript = cx.compileReader(this.scope, reader,
src.getURI(),
1, null);
return compiledScript;
}
Thanks,
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
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Flow Scoping, was: JavaScriptInterpreter: bug or feature?
Posted by Vadim Gritsenko <va...@verizon.net>.
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: JavaScriptInterpreter: bug or feature?
Posted by Christopher Oliver <re...@verizon.net>.
Hold on, Vadim. I'll fix that shortly. It's only there for testing
compiling with different scopes. I think it's good that you're visually
inspecting the code for problems, but I think we should focus more on
externally visible problems rather than code inspection at this point.
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?
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.
When you request the property of an object in JavaScript the interpreter
performs the lookup in the following way:
Search the object itself
Search the object's prototype chain
Search the object's parent scope
The thrScope's parent scope is null, so it becomes the global variable
scope for the user, but we set its prototype to be the shared "scope",
so builtin objects are located in the shared scope.
I wanted to test if I could successfully compile scripts using the
shared scope instead of in thrScope, and it does indeed seem to work.
Now my question:
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?
Regards,
Chris
Regards,
Chris
Vadim Gritsenko wrote:
> Can somebody knowledgable comment on the following method? Local
> variable scope is not used...
>
>
> private Script compileScript(Context cx, Scriptable scope,
> Source src) throws Exception {
> InputStream is = src.getInputStream();
> Reader reader = new BufferedReader(new InputStreamReader(is));
> // FIXME: scope or this.scope?
> Script compiledScript = cx.compileReader(this.scope, reader,
> src.getURI(),
> 1, null);
> return compiledScript;
> }
>
>
> Thanks,
> Vadim
>
>
>