You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <ug...@apache.org> on 2003/10/21 00:46:08 UTC
[VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
[Is a vote needed before changing a public interface, even if it's in an
unstable block? And, by the way, where are the rules detailing what
needs a vode and what doesn't?]
I'd like to propose changing the signature of two interface methods:
org.apache.cocoon.woody.formmodel.Widget.generateSaxFragment
org.apache.cocoon.woody.datatype.SelectionList.generateSaxFragment
by adding a third parameter:
void generateSaxFragment(ContentHandler contentHandler, Locale locale,
JXPathContext jxpathContext)
The reason I need this is because I want to populate selection lists
from a collection stored in the Flow object model.
I've already performed the necessary changes and tested that all samples
seem to work fine, in my local copy.
Please cast your vote or otherwise express your opinion.
Ugo
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Ugo Cei <u....@cbim.it>.
Giacomo Pati wrote:
> Why not just have the @src of the <selection-list> check the protocol
> used to distinguish the type?
That's a possibility I evaluated, but keep in mind that you need to
specify also the name of the properties used to retrieve the key and
value from each object in the collection. Maybe something like this
would work:
src="xpath://path/of/collection#keyattr,valueattr"
but what does it buy you, besides having to parse the URI?
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Giacomo Pati <gi...@apache.org>.
On Tue, 21 Oct 2003, Sylvain Wallez wrote:
<snipped/>
> Ok, I understand. I encountered a somehow similar problem and came to
> the conclusion that what we need is actually to have <wd:selection-list>
> a pluggable component.
>
> We could then have <wd:selection-list
> type="default|flow-jxpath|javascript|whatever"> and the attributes and
> content of this element be the configuration of the selection list. We
> can then have the FlowJXPathSelectionListBuilder be Contextualizable to
> give the Avalon Context to the FlowJXPathSelectionList it creates.
Why not just have the @src of the <selection-list> check the protocol
used to distinguish the type?
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
> Sylvain Wallez wrote:
>
>>> Shouldn't this component be called just JXPathSelectionList? There's
>>> no reason why it should be called from the Flow only, is there?
>>
>> Yes, there is, since the xpath expressions apply to the flow view
>> data object (I prefer "view data" to "context object" as there are
>> already too many "context" objects in Cocoon).
>
>
> I see, but maybe it would be useful to use data coming from somewhere
> else. I'll have to reflect some more about this.
Maybe we could define the context object for the xpath expressions using
an input module? Or have an AbstractXPathSelectionList and have
FlowXPathSelectionList extend it?
>> That's why FlowXPathSelectionList is so simple.
>
>
> Understood.
>
>>> What about tests? ;-)
>>
>> Well, awaiting your commit ;-)
>
>
> See FlowJXPathSelectionListTestCase ;-). By the way, as you wrote
> above, there are too many contexts in Cocoon. In order to pass the
> "view data " to Cocoon, I had to put that inside a flowContextObject
> which in turn is put inside a Request which in turn is put inside an
> objectModel which in turn is put inside a contextObjectModel which is
> used to build the Context. Can you say "matrioska"? ;-)
You're right. And I was thinking of "promoting" the view data object as
a member of the object model (it's today a request attribute). This
should not break compatibility as this is hidden inside FlowHelper, and
would speed up access by avoiding the intermediate access to the request
object.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Ugo Cei <u....@cbim.it>.
Sylvain Wallez wrote:
>> Shouldn't this component be called just JXPathSelectionList? There's
>> no reason why it should be called from the Flow only, is there?
> Yes, there is, since the xpath expressions apply to the flow view data
> object (I prefer "view data" to "context object" as there are already
> too many "context" objects in Cocoon).
I see, but maybe it would be useful to use data coming from somewhere
else. I'll have to reflect some more about this.
> That's why FlowXPathSelectionList is so simple.
Understood.
>> What about tests? ;-)
> Well, awaiting your commit ;-)
See FlowJXPathSelectionListTestCase ;-). By the way, as you wrote above,
there are too many contexts in Cocoon. In order to pass the "view data "
to Cocoon, I had to put that inside a flowContextObject which in turn is
put inside a Request which in turn is put inside an objectModel which in
turn is put inside a contextObjectModel which is used to build the
Context. Can you say "matrioska"? ;-)
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
> Sylvain Wallez wrote:
>
>> Done: the selection list builders are now pluggable components. And I
>> also wrote the FlowJXPathSelectionList just to test if this worked
>> properly...
>
>
> In the back of my mind I'm a little sad because you took away from me
> the possibility of making a first, substantial commit ;-).
Oh, I'm sorry for that :-/ But I'm sure there are many more commits to
come!
>> Is this what you had also? If not feel free to hack and patch around!
>
>
> I have a couple of observations just from quickly glancing at your code:
>
> Shouldn't this component be called just JXPathSelectionList? There's
> no reason why it should be called from the Flow only, is there?
Yes, there is, since the xpath expressions apply to the flow view data
object (I prefer "view data" to "context object" as there are already
too many "context" objects in Cocoon).
> In my code I mimicked what DynamicSelectionList does, namely wrapping
> the ContentHandler in a SelectionListHandler that does some datatype
> conversions, AFAIU. Isn't the same needed here?
The main difference with DynamicSelectionList is that values are given
in their object form, and not as Strings. DynamicSelectionList has a lot
of code to convert the @value attribute format according to the
selection list's convertor and the output Locale.
That's why FlowXPathSelectionList is so simple.
> What about tests? ;-)
Well, awaiting your commit ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Ugo Cei <u....@cbim.it>.
Sylvain Wallez wrote:
> Done: the selection list builders are now pluggable components. And I
> also wrote the FlowJXPathSelectionList just to test if this worked
> properly...
In the back of my mind I'm a little sad because you took away from me
the possibility of making a first, substantial commit ;-).
> Is this what you had also? If not feel free to hack and patch around!
I have a couple of observations just from quickly glancing at your code:
Shouldn't this component be called just JXPathSelectionList? There's no
reason why it should be called from the Flow only, is there?
In my code I mimicked what DynamicSelectionList does, namely wrapping
the ContentHandler in a SelectionListHandler that does some datatype
conversions, AFAIU. Isn't the same needed here?
What about tests? ;-)
That's all for now. I hope do have a deeper look at the code later, and
maybe write some tests and docs.
Thanks a lot,
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ugo Cei wrote:
> Sylvain Wallez wrote:
>
>> Mmmh... as I also need this for my current project, let's make a
>> deal: I componentize selection-list in the coming days, not later
>> than the end of this week, so you can use it for your
>> FlowJXPathSelectionList.
>>
>> How does it sound?
>
>
> It sounds like an offer I cannot refuse ;-).
Done: the selection list builders are now pluggable components. And I
also wrote the FlowJXPathSelectionList just to test if this worked
properly...
You can now write
<wd:selection-list type="flow-jxpath" list-path="selectList"
value-path="value" label-path="label"/>
And in the flow script:
var data = {selectList: [{value:3, label:"three"}, {value:4}]};
form.showForm("form.html", data);
Is this what you had also? If not feel free to hack and patch around!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Ugo Cei <u....@cbim.it>.
Sylvain Wallez wrote:
> Mmmh... as I also need this for my current project, let's make a deal: I
> componentize selection-list in the coming days, not later than the end
> of this week, so you can use it for your FlowJXPathSelectionList.
>
> How does it sound?
It sounds like an offer I cannot refuse ;-).
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ugo Cei wrote:
> Sylvain Wallez wrote:
>
>> Ok, I understand. I encountered a somehow similar problem and came to
>> the conclusion that what we need is actually to have
>> <wd:selection-list> a pluggable component.
>
> <snip/>
>
>> What do you think?
>
>
> I think that what you're proposing looks interesting and certainly
> more elegant than my proposal. However, I'm not sure I can implement
> it myself in a reasonable amount of time. Personally, I'd go for the
> "simplest possible thing that might work" (TM) and refactor later if
> and when the need arises. However, I'm just a newbie with this stuff,
> but with a need to be satisfied ASAP. So, if you're not convinced,
> I'll fork my own version and wait for someone to implement the
> full-featured solution.
Mmmh... as I also need this for my current project, let's make a deal: I
componentize selection-list in the coming days, not later than the end
of this week, so you can use it for your FlowJXPathSelectionList.
How does it sound?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Ugo Cei <u....@cbim.it>.
Sylvain Wallez wrote:
> Ok, I understand. I encountered a somehow similar problem and came to
> the conclusion that what we need is actually to have <wd:selection-list>
> a pluggable component.
<snip/>
> What do you think?
I think that what you're proposing looks interesting and certainly more
elegant than my proposal. However, I'm not sure I can implement it
myself in a reasonable amount of time. Personally, I'd go for the
"simplest possible thing that might work" (TM) and refactor later if and
when the need arises. However, I'm just a newbie with this stuff, but
with a need to be satisfied ASAP. So, if you're not convinced, I'll fork
my own version and wait for someone to implement the full-featured solution.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Ugo Cei wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Can you explain in more details what's the purpose of the
>>> jxpathContext here and where its value come from? Adding a
>>> dependency on JXPath so high in Woody interfaces doesn't seem good
>>> to me.
>>
<snip/>
> Ok, I understand. I encountered a somehow similar problem and came to
> the conclusion that what we need is actually to have
> <wd:selection-list> a pluggable component.
>
> We could then have <wd:selection-list
> type="default|flow-jxpath|javascript|whatever"> and the attributes and
> content of this element be the configuration of the selection list. We
> can then have the FlowJXPathSelectionListBuilder be Contextualizable
> to give the Avalon Context to the FlowJXPathSelectionList it creates.
>
> The flow context is then available through
> FlowHelper.getContextObject(ContextHelper.getObjectModel(avalonContext)).
>
> This would avoid passing along the context object and also use it in
> situations other than generateSAXFragment() such as during form
> validation (for closed enumerations).
>
> What do you think?
>
> Sylvain
Maybe somewhat OT, but wouldn't it be a good idea to define an API for
using expression languages access java objects. After all, there
starting to be quite a few components in Cocoon that uses JXPath or
other expression languages. An expression language component would make
it easier to write and support such components and it would probably
make the use of expression languages more standardized among components.
JEX http://www.plotnix.com/jex/index.html is an example of what such an
API could look like. JEX was added to jakarta-commons-sandbox but didn't
take of, IIRC people thought that it was better to use BSF, but IMO
something like JEX would be usefull for using expression languages in
Cocoon.
WDYT?
/Daniel
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ugo Cei wrote:
> Sylvain Wallez wrote:
>
>> Can you explain in more details what's the purpose of the
>> jxpathContext here and where its value come from? Adding a dependency
>> on JXPath so high in Woody interfaces doesn't seem good to me.
>
>
> The value comes from WoodyTemplateTransformer:
>
> Object flowContext = FlowHelper.getContextObject(objectModel);
> WebContinuation wk = FlowHelper.getWebContinuation(objectModel);
> JXPathContext jxpc = JXPathContext.newContext(flowContext);
>
> (similar code must be added to WoodyGenerator also).
>
> We need this if we want to populate selection lists with collections
> defined in the flowscript and avoid the need to call a different
> pipeline. Please have a look at the following (contrived) sample,
> while I try to prepare a more meaningful one:
>
> <wd:selection-list model="model" key="key" value="value"/>
>
> ...
>
> public class MyBean {
> public int getKey() { ... }
> public String getValue() { ... }
> };
>
> ...
>
> var list = [ new MyBean(1, 'One'), new MyBean(2, 'Two') ];
> form.showForm("uri", { "model" : list });
>
>
> Now that I think about it, we might as well pass "Object flowContext"
> to generateSaxFragment, thus avoiding a dependency on JXPath. So, I'm
> changing my proposal to the following:
>
> Change the signature of two interface methods:
>
> org.apache.cocoon.woody.formmodel.Widget.generateSaxFragment
> org.apache.cocoon.woody.datatype.SelectionList.generateSaxFragment
>
> by adding a third parameter:
>
> void generateSaxFragment(ContentHandler contentHandler, Locale locale,
> Object flowContext)
>
> Hope this answers your doubts.
Ok, I understand. I encountered a somehow similar problem and came to
the conclusion that what we need is actually to have <wd:selection-list>
a pluggable component.
We could then have <wd:selection-list
type="default|flow-jxpath|javascript|whatever"> and the attributes and
content of this element be the configuration of the selection list. We
can then have the FlowJXPathSelectionListBuilder be Contextualizable to
give the Avalon Context to the FlowJXPathSelectionList it creates.
The flow context is then available through
FlowHelper.getContextObject(ContextHelper.getObjectModel(avalonContext)).
This would avoid passing along the context object and also use it in
situations other than generateSAXFragment() such as during form
validation (for closed enumerations).
What do you think?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Ugo Cei <u....@cbim.it>.
Sylvain Wallez wrote:
> Can you explain in more details what's the purpose of the jxpathContext
> here and where its value come from? Adding a dependency on JXPath so
> high in Woody interfaces doesn't seem good to me.
The value comes from WoodyTemplateTransformer:
Object flowContext = FlowHelper.getContextObject(objectModel);
WebContinuation wk = FlowHelper.getWebContinuation(objectModel);
JXPathContext jxpc = JXPathContext.newContext(flowContext);
(similar code must be added to WoodyGenerator also).
We need this if we want to populate selection lists with collections
defined in the flowscript and avoid the need to call a different
pipeline. Please have a look at the following (contrived) sample, while
I try to prepare a more meaningful one:
<wd:selection-list model="model" key="key" value="value"/>
...
public class MyBean {
public int getKey() { ... }
public String getValue() { ... }
};
...
var list = [ new MyBean(1, 'One'), new MyBean(2, 'Two') ];
form.showForm("uri", { "model" : list });
Now that I think about it, we might as well pass "Object flowContext" to
generateSaxFragment, thus avoiding a dependency on JXPath. So, I'm
changing my proposal to the following:
Change the signature of two interface methods:
org.apache.cocoon.woody.formmodel.Widget.generateSaxFragment
org.apache.cocoon.woody.datatype.SelectionList.generateSaxFragment
by adding a third parameter:
void generateSaxFragment(ContentHandler contentHandler, Locale locale,
Object flowContext)
Hope this answers your doubts.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ugo Cei wrote:
> [Is a vote needed before changing a public interface, even if it's in
> an unstable block? And, by the way, where are the rules detailing what
> needs a vode and what doesn't?]
>
> I'd like to propose changing the signature of two interface methods:
>
> org.apache.cocoon.woody.formmodel.Widget.generateSaxFragment
> org.apache.cocoon.woody.datatype.SelectionList.generateSaxFragment
>
> by adding a third parameter:
>
> void generateSaxFragment(ContentHandler contentHandler, Locale locale,
> JXPathContext jxpathContext)
>
> The reason I need this is because I want to populate selection lists
> from a collection stored in the Flow object model.
>
> I've already performed the necessary changes and tested that all
> samples seem to work fine, in my local copy.
>
> Please cast your vote or otherwise express your opinion.
Can you explain in more details what's the purpose of the jxpathContext
here and where its value come from? Adding a dependency on JXPath so
high in Woody interfaces doesn't seem good to me.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: [VOTE] Add parameter to Woody {SelectionList,Widget}.generateSaxFragment
Posted by Reinhard Poetz <re...@apache.org>.
From: Ugo Cei
> [Is a vote needed before changing a public interface, even if
> it's in an
> unstable block?
I don't think a vote is needed.
> And, by the way, where are the rules detailing what
> needs a vode and what doesn't?]
Don't know :-(
Steven, do you have a pointer for us?
>
> I'd like to propose changing the signature of two interface methods:
>
> org.apache.cocoon.woody.formmodel.Widget.generateSaxFragment
> org.apache.cocoon.woody.datatype.SelectionList.generateSaxFragment
>
> by adding a third parameter:
>
> void generateSaxFragment(ContentHandler contentHandler,
> Locale locale,
> JXPathContext jxpathContext)
>
> The reason I need this is because I want to populate selection lists
> from a collection stored in the Flow object model.
>
> I've already performed the necessary changes and tested that
> all samples
> seem to work fine, in my local copy.
>
> Please cast your vote or otherwise express your opinion.
Anyway, big +1 from me!
Cheers,
Reinhard