You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gianugo Rabellino <gi...@apache.org> on 2004/03/16 19:55:18 UTC
JXTG weirdo
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.
This beans (which, BTW, is an Avalon component) resides in the session,
so I thought that something along
${cocoon.session.getAtttribute('mybean').getMap()} or the equivalent
#{$cocoon/session/attribute['mybean']/map} would have done the trick,
but indeed that wasn't the case. I thought that there was something
weird with the cocoon.session part, since is FOM bases and flow was
involved only to a certain extent, so I resorted to a sitemap parameter:
<map:parameter name="mybean" value="{session-attr:mybean}"/>
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?
--
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/)
Re: JXTG weirdo
Posted by Gianugo Rabellino <gi...@apache.org>.
> Reinhard Pötz wrote:
>
>> Gianugo Rabellino wrote:
>>
>>> 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.
>>>
>> IIRC Sylvain added support for the bizdata object to the cForms API as
>> well
>
> Yep. That was one of the main purposes of woody2.js: form.showForm()
> should have the exact same parameters a cocoon.sendPageAndWait(), since
> there are many use cases where the view is the combination of the form
> with some other business data.
Yes, showForm() is fine. The problem is with the form definition file
being loaded as a source (new Form(source)), which rules out the
possibility to pass a bizData object along. I was hoping that JXTG was
able to pick up an object from session/context/whatever and do it's job
inside a pipeline, with no need for argument passing. But it doesn't seem
to be the case.
>>> (note to self: refrain from posting if you'll be unable to follow up
>>> for the next few days...)
>
> CC'ed you directly so that you don't miss this answer ;-)
Thanks a lot. Webmail is - somehow - behaving today. :-)
Ciao,
--
Gianugo
Re: JXTG weirdo
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Pötz wrote:
> 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.
>>
> IIRC Sylvain added support for the bizdata object to the cForms API as
> well
Yep. That was one of the main purposes of woody2.js: form.showForm()
should have the exact same parameters a cocoon.sendPageAndWait(), since
there are many use cases where the view is the combination of the form
with some other business data.
>> (note to self: refrain from posting if you'll be unable to follow up
>> for the next few days...)
>
CC'ed you directly so that you don't miss this answer ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: JXTG weirdo
Posted by Reinhard Pötz <re...@apache.org>.
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.
>
IIRC Sylvain added support for the bizdata object to the cForms API as well
> (note to self: refrain from posting if you'll be unable to follow up
> for the next few days...)
;-)
--
Reinhard
Re: JXTG weirdo
Posted by Gianugo Rabellino <gi...@apache.org>.
Sylvain Wallez wrote:
>> Perhaps what is needed is for JXTG to have a parameterized
>> "ContextBuilder" that can set up its variable context differently
>> depending on whether it is called from sendPage*() (in which case it
>> provides access to the FOM) or not (in which case it only provides
>> access to the Request/Session/Context - and/or other objects...)
>
>
>
> Seems a good idea. There should be no difference from the template POV
> on the availability of non-flow data (request, session, etc) whether the
> template is called by a flowscript or not.
Yup. And not only that: I'm starting to think that JXT could be useful
even outside Cocoon, as a generic way to script JXPath/Jexl. Would it
make sense to factor the "language" in a generic POJO/Component with
JXTG being just a glue?
--
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/)
Re: JXTG weirdo
Posted by Sylvain Wallez <sy...@apache.org>.
Christopher Oliver wrote:
> The problem (I think) is that he is trying to use JXTG in a pipeline
> called from the Form constructor, e.g.
>
> var form = new Form("cocoon:/whatever");
Ah, got it now!
> However, the "cocoon" variable in JXTG is only set up when the
> pipeline is called from a Flowscript via cocoon.sendPage*().
>
> Vadim raised this issue a while ago and Carsten mentioned he was
> planning to do something about it. Carsten, what's the status of that?
>
> Perhaps what is needed is for JXTG to have a parameterized
> "ContextBuilder" that can set up its variable context differently
> depending on whether it is called from sendPage*() (in which case it
> provides access to the FOM) or not (in which case it only provides
> access to the Request/Session/Context - and/or other objects...)
Seems a good idea. There should be no difference from the template POV
on the availability of non-flow data (request, session, etc) whether the
template is called by a flowscript or not.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: JXTG weirdo
Posted by Christopher Oliver <re...@verizon.net>.
The problem (I think) is that he is trying to use JXTG in a pipeline
called from the Form constructor, e.g.
var form = new Form("cocoon:/whatever");
However, the "cocoon" variable in JXTG is only set up when the pipeline
is called from a Flowscript via cocoon.sendPage*().
Vadim raised this issue a while ago and Carsten mentioned he was
planning to do something about it. Carsten, what's the status of that?
Perhaps what is needed is for JXTG to have a parameterized
"ContextBuilder" that can set up its variable context differently
depending on whether it is called from sendPage*() (in which case it
provides access to the FOM) or not (in which case it only provides
access to the Request/Session/Context - and/or other objects...)
Chris
Ugo Cei wrote:
> Gianugo Rabellino wrote:
>
>> 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.
>
>
> I'm not sure I'm following you here. Can't you do form.showForm(uri,
> bizData)? Or do you mean something else?
>
> Ugo
>
>
Re: JXTG weirdo
Posted by Ugo Cei <u....@cbim.it>.
Gianugo Rabellino wrote:
> 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.
I'm not sure I'm following you here. Can't you do form.showForm(uri,
bizData)? Or do you mean something else?
Ugo
Re: JXTG weirdo
Posted by Gianugo Rabellino <gi...@apache.org>.
Bruno Dumon wrote:
>>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/)
Re: JXTG weirdo
Posted by Bruno Dumon <br...@outerthought.org>.
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
Re: JXTG weirdo
Posted by Gianugo Rabellino <gi...@apache.org>.
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.
(note to self: refrain from posting if you'll be unable to follow up for
the next few days...)
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/)
Re: JXTG weirdo
Posted by Reinhard Pötz <re...@apache.org>.
Gianugo Rabellino wrote:
> 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.
>
> This beans (which, BTW, is an Avalon component) resides in the
> session, so I thought that something along
> ${cocoon.session.getAtttribute('mybean').getMap()} or the equivalent
> #{$cocoon/session/attribute['mybean']/map} would have done the trick,
> but indeed that wasn't the case. I thought that there was something
> weird with the cocoon.session part, since is FOM bases and flow was
> involved only to a certain extent, so I resorted to a sitemap parameter:
>
> <map:parameter name="mybean" value="{session-attr:mybean}"/>
>
> 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.
--
Reinhard
Re: JXTG weirdo
Posted by Sylvain Wallez <sy...@apache.org>.
Gianugo Rabellino wrote:
> 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.
>
> This beans (which, BTW, is an Avalon component) resides in the
> session, so I thought that something along
> ${cocoon.session.getAtttribute('mybean').getMap()} or the equivalent
> #{$cocoon/session/attribute['mybean']/map} would have done the trick,
> but indeed that wasn't the case. I thought that there was something
> weird with the cocoon.session part, since is FOM bases and flow was
> involved only to a certain extent, so I resorted to a sitemap parameter:
>
> <map:parameter name="mybean" value="{session-attr:mybean}"/>
>
> 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?
<map:parameter> are *strings*, meaning the "MyBean@whatever" you got is
the result of String.valueOf(Object).
Now why did cocoon.session.getAttribute('mybean') failed, I don't know.
A technique I often use to isolate this kind of evaluation problems is
the JXTemplate equivalent of the good old println which simply consists
in outputting the result of an expression in the resulting page.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }