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 }
