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 Sat, 17 Apr 2004 01:53:24 GMT
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. 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.

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).


Gianugo Rabellino wrote:

> We are currently building a cforms based application with fairly 
> decent complexity level. Our (rather convoluted but, take my word for 
> that, legit) business logic requires the usage of an Avalon component 
> during the binding phase, so we thought to use the fb:javascript 
> binding method, hoping to find (even if not explicitely documented) 
> the good old FOM, together with the cocoon object.
> That was indeed the case, and we were cheerfully using logic like the 
> one in the following snippet:
> <fb:load-form>
>    var validation = cocoon.getComponent("bindinghelper");
>    var today = new;
>    var executionDate = validation.getValidExecutionDate(today);
>    widget.setValue(executionDate.getTime());
> </fb:load-form>
> At a certain point, though, we mangled the form *definition* and 
> modified a selection list so that it was taking its data from a 
> cocoon:/ pipeline instead than from a static file (which we used 
> during prototyping). Such pipeline, in turns, calls the flow which 
> sendPage()s to a JXTG (data are in a business object we need to stream):
>     <map:match pattern="lastTransfer">
>         <map:call function="lastTransferList"/>
>     </map:match>
>     <map:match pattern="lastTransferList">
>       <map:generate type="jxtg" src="resources/jxt/transfer-list.jxt"/>
>       <map:transform src="resources/xsl/transfer-list2fdsel-list.xsl"/>
>       <map:serialize type="xml"/>
>     </map:match>
> (now, talking about tangled web of pipelines calling flow calling 
> pipelines... but anyway)
> Here is where crap happens. In our binding phase the cocoon object 
> isn't there anymore:
> "file:/Users/gianugo/dev/src/newcorporate/src/build/webapp/italiantransfer/resources/forms/italian-transfer-bind-bean.xml",

> line 5: uncaught JavaScript exception:
> at insertItalianTransfer 
> (file:/Users/gianugo/dev/src/newcorporate/src/build/webapp/italiantransfer/flow/italianTransfer.js,

> Line 42)
> at  (resource://org/apache/cocoon/forms/flow/javascript/v2/Form.js, 
> Line 158):
> ReferenceError: "cocoon" is not defined. 
> (file:/Users/gianugo/dev/src/newcorporate/src/build/webapp/italiantransfer/resources/forms/italian-transfer-bind-bean.xml;

> line 5)
> and we are unable to run our binding code. Debugging 
> o.a.c.f.util.JavascriptHelper, it turns out that the parent scope in 
> our first scenario is a FOM, while the insertion in the definition of 
> the dynamic list, (apparently) causing another flow call to happen, 
> leaves an empty NativeObject in place of the FOM.
> OK, I hope you're still with me until now. :-) Questions follow:
> 1. is this an expected behaviour?
> 2. would it be possible/make sense to ensure that even javascript 
> bindings get a FOM object?
> 3. if not, what is the alternative? Writing a custom binding? Really? :-/
> Thanks for your time on this. I'm really banging my head against this 
> issue and can't quite see a way out as of now.
> Ciao,

View raw message