On Wed, 2004-03-17 at 19:52, Gianugo Rabellino wrote:
> Reinhard P�tz wrote:
>
> >> but even this one seems unwilling to behave as I expected. The thing
> >> is that if I try just ${cocoon} I can see my parameter=MyBean there,
> >> and if I try ${cocoon.parameters.mybean} I indeed get a
> >> [EMAIL PROTECTED], so the object is there (pardon my funky syntax: I'm
> >> writing on a bus and don't have the actual code in front of me, please
> >> consider that I *think* I'm using a correct syntax. However, I'm still
> >> unable to access any accessor of my object: all I get is an empty
> >> evaluation that carries a firghtening nothing using Jexl syntax, and a
> >> non-existent path using JXPath's. I feel I'm doing something
> >> *horribly* wrong, but ATM I'm out of ideas. Any suggestions?
> >>
> >
> > I also can't tell you how what you're doing wrong but passing the
> > session objects to the pipline within cocoon.sendPage(AndWait) should
> > work in every case in is the cleaner approach IMHO.
>
> 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).
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.).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
