Re: [cforms] Weird behaviour of flow and fb:javascript binding

[Christopher Oliver]

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

Chris

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 Packages.java.util.GregorianCalendar();
   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,