cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: JXTG weirdo
Date Thu, 18 Mar 2004 17:48:57 GMT
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 
> >> MyBean@whatever, 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
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message