Yup, problem is that you can't generate a form definition this way, since the woody.js call expects a pipeline (as in new Form("something")), and doesn't accept a bizData object. Too bad.
With some additions I did today, this is now possible. More specifically, a form can now be created by passing a DOM-tree containing the XML form definition, instead of a source.
An example: var pipelineUtil = cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil); var formDocument = pipelineUtil.processToDOM("myFormPipe", {"myData": myData}); var form = new Form(formDocument.getDocumentElement());
Note that in this case the form definition won't be cached, but that wouldn't be the case anyhow if you're using a non-cacheable pipeline.
Note that since otherwise Woody parses the form definition also to a DOM tree, this way of working doesn't give any additional overhead (in fact, it saves you from a reparse of the XML).
That is definitely going to be useful. Thanks a lot Bruno!
To come back to what you mentioned in your first mail:
Today I got stuck using JXTG in what I thought would have been a quite
common use case. I have to generate a cforms definition file (a selection list, actually) which is dynamically built from a bean that returns a Map.
If you only need to generate the selection list dynamically, I wouldn't generate the complete form definition dynamically. There are various alternatives (src attribute on fd:selection-list, flowjxpath selection list, etc.).
Well, I just couldn't find a way with my (quite tangled) use case. All I had was an object and no way to xmlize it easily without JXTG, since such object lived (was instantiated) inside the flow. Eventually we found a workaround which resembles yours, but still I don't think that my situation was that much unusual...
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/)
