cocoon-dev mailing list archives

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

> 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.
See below.

>> 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?
Depends on the requirements of the Form and Binding frameworks (in other 
words a design is needed). But, for example, I think we can all agree it 
should not have a "sendPageAndWait()" function.


View raw message