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,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
