cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject [cforms] Weird behaviour of flow and fb:javascript binding
Date Fri, 16 Apr 2004 16:56:26 GMT
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:

    var validation = cocoon.getComponent("bindinghelper");
    var today = new;
    var executionDate = validation.getValidExecutionDate(today);

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 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"/>

(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:


line 5: uncaught JavaScript exception:
at insertItalianTransfer 

Line 42)
at  (resource://org/apache/cocoon/forms/flow/javascript/v2/Form.js, Line 
ReferenceError: "cocoon" is not defined. 

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.


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Blogging at:

View raw message