cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [cforms] Weird behaviour of flow and fb:javascript binding
Date Sun, 18 Apr 2004 19:11:27 GMT
Christopher Oliver wrote:

> I can't say that I fully understand your problem, but I just looked at 
> o.a.c.f.util.JavascriptHelper, and that appears to have some major 
> bugs. If it isn't called from a flow script it uses a static 
> JavaScript object as the top level scope (where JS global variables 
> are created), but does not even synchronize access to it. That means 
> any global variables you set in one of your Javascript snippets 
> (intentionally or accidentally) will be visible to all users and you 
> will see undefined behavior if multiple threads read and write the 
> same variables.


Learning the internals of Rhino and how this scope and context machinery 
works is not an easy task :-/

So the solution is to create a new scope for each call, right? Also, 
instead of creating an intermediate scope to hold snippet-specific data, 
I was think of using functions where this intermediate scope would be 
function parameters. That way "global" variables in the snippet actually 
are local variables of the function.

> If it is called indirectly from a flow script (i.e. from sendPage*()) 
> you share global variables with the flow script (that's why you could 
> access the "cocoon" object in some cases but not others). But this is 
> also bad because it makes bugs related to accidentally overwriting 
> global variables very hard to find.


I consider this the availability of the cocoon object and global 
flowscript variables an essential feature, as form event listeners are 
an integral part of the controller.

> However, as a hack for the time being, you could probably set the 
> request attribute it uses to obtain the flow script global scope 
> yourself before calling the binding.
>
> As regards evaluating JavaScript snippets in form definition and 
> binding files, I don't think the flowscript global scope should used. 
> Rather, a special scope should be created (- and unique per thread) in 
> which to evaluate those snippets. The binding framework and form 
> framework can make available appropriate Cocoon system objects in this 
> scope if that is required (such as an object that allows you to get an 
> avalon component).


Mmmh... how would this "cocoon" object be different from the one in 
flowscript?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message