You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Timothy Larson <ti...@yahoo.com> on 2003/12/03 03:42:49 UTC
CocoonForms simple-repeater binding sample?
Does anybody have a working sample of a simple-repeater binding?
I am trying to adapt the binding to work with (you guessed it)
class, new, struct, and union, but I am having trouble getting
the simple-repeater binding working.
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Vadim Gritsenko <va...@verizon.net>.
Marc Portier wrote:
> Vadim Gritsenko wrote:
>
>> Marc Portier wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> Marc Portier wrote:
>>>>
>
> <snip topic="use cases on introducing some direction control on all
> bindings" />
>
> my proposal was to add some @direction="load|save|both"
>
>>
>> Good examples. But I'm not sure I like "direction" attribute. Can we
>> just add "writeonly" attribute, in addition to "readonly"?
>>
>> Vadim
>
>
>
> Vadim,
> I started refactoring the bindings for this, but still have to decide
> how the builder will retrieve the settings from the
> binding-declaration file
>
> After considering your proposal I'm pretty much at the position of
> siwtching back to my original proposal. There are two cases
> introduced by the @readonly @writeonly couple that make it odd IMHO
>
> 1/ readonly="true" writeonly="true"
>
> kinda fights with the meaning of 'only' as a suffix
>
> 2/ readonly="false" writeonly="false"
>
> which would be the equivalent of direction="none" :-)
Ok, go ahead with "direction".
Vadim
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Marc Portier <mp...@outerthought.org>.
Vadim Gritsenko wrote:
> Marc Portier wrote:
>
>>
>>
>> Vadim Gritsenko wrote:
>>
>>> Marc Portier wrote:
>>>
<snip topic="use cases on introducing some direction control on all
bindings" />
my proposal was to add some @direction="load|save|both"
>
> Good examples. But I'm not sure I like "direction" attribute. Can we
> just add "writeonly" attribute, in addition to "readonly"?
>
> Vadim
Vadim,
I started refactoring the bindings for this, but still have to decide
how the builder will retrieve the settings from the binding-declaration file
After considering your proposal I'm pretty much at the position of
siwtching back to my original proposal. There are two cases introduced
by the @readonly @writeonly couple that make it odd IMHO
1/ readonly="true" writeonly="true"
kinda fights with the meaning of 'only' as a suffix
2/ readonly="false" writeonly="false"
which would be the equivalent of direction="none" :-)
for fast testing without a binding I would recommend to people that they
just comment out that section :-)
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Vadim Gritsenko <va...@verizon.net>.
Marc Portier wrote:
>
>
> Vadim Gritsenko wrote:
>
>> Marc Portier wrote:
>>
>>> - in fact it also struck me that the @readonly concept only allows
>>> us to choose between two modes of operation : 1/ do load AND save 2/
>>> do only load. Maybe we should provide a generic attribute on all
>>> bindings that looks like @direction and can hold load|save|both
>>> (probably even implement this at the level of the abstract base class?)
>>
>>
>>
>>
>> I'm curious... What is the usecase for "writeonly" binding?
>
>
>
> hm, I have to admit it was more an academic observation in terms of it
> being two equivalent methods that really do (should) not impose any
> assumed orchestration between both?
>
> in any case this is not about the complete binding action of the WHOLE
> form where you can just choose not to call the load and save actions
> from your controller (flowscript)
>
> it really is about having the possibility on the level of each
> sub-binding to enable or disable any direction in the event of load or
> save being called on the complete form.
>
>
> so use cases coming to mind :
> 1/ not to be disclosed back-end info, e.g. password or visa
>
> But I have to admit that my advise would be to make sure that the
> backend is not disclosing this in the first place, so if the back-end
> sets it to null then you _could_ safely LOAD that data anyway
>
> so, the addition here would only slightly improve performance :-P
>
>
> but I did find a better case to save my ass here :-)
> (and I think it is useful)
> 2/ you want to preserve the original data and ADD the new stuf to the
> backend model
>
> so at some level you would have a context binding for /root/something
> with two nested bindings that alternatively work during load or save,
> so you can
>
> load from ./original
> save to ./updated
>
> resulting into a backend-model with distinct
> root
> something
> original
> updated
Good examples. But I'm not sure I like "direction" attribute. Can we
just add "writeonly" attribute, in addition to "readonly"?
Vadim
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Marc Portier <mp...@outerthought.org>.
Vadim Gritsenko wrote:
> Marc Portier wrote:
>
>> - in fact it also struck me that the @readonly concept only allows us
>> to choose between two modes of operation : 1/ do load AND save 2/ do
>> only load. Maybe we should provide a generic attribute on all
>> bindings that looks like @direction and can hold load|save|both
>> (probably even implement this at the level of the abstract base class?)
>
>
>
> I'm curious... What is the usecase for "writeonly" binding?
>
hm, I have to admit it was more an academic observation in terms of it
being two equivalent methods that really do (should) not impose any
assumed orchestration between both?
in any case this is not about the complete binding action of the WHOLE
form where you can just choose not to call the load and save actions
from your controller (flowscript)
it really is about having the possibility on the level of each
sub-binding to enable or disable any direction in the event of load or
save being called on the complete form.
so use cases coming to mind :
1/ not to be disclosed back-end info, e.g. password or visa
But I have to admit that my advise would be to make sure that the
backend is not disclosing this in the first place, so if the back-end
sets it to null then you _could_ safely LOAD that data anyway
so, the addition here would only slightly improve performance :-P
but I did find a better case to save my ass here :-)
(and I think it is useful)
2/ you want to preserve the original data and ADD the new stuf to the
backend model
so at some level you would have a context binding for /root/something
with two nested bindings that alternatively work during load or save, so
you can
load from ./original
save to ./updated
resulting into a backend-model with distinct
root
something
original
updated
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Vadim Gritsenko <va...@verizon.net>.
Marc Portier wrote:
> - in fact it also struck me that the @readonly concept only allows us
> to choose between two modes of operation : 1/ do load AND save 2/ do
> only load. Maybe we should provide a generic attribute on all
> bindings that looks like @direction and can hold load|save|both
> (probably even implement this at the level of the abstract base class?)
I'm curious... What is the usecase for "writeonly" binding?
Vadim
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Marc Portier wrote:
>
>>
>>
>> Sylvain Wallez wrote:
>>
>> <snip />
>>
>>>>> I was attempting and failing to bind to an XML document. The load
>>>>> worked, but the save gave the exception.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Sylvain?
>>>>
>>>> I know Sylvain created this:
>>>> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/util/jxpath/DOMFactory.java
>>>>
>>>> exactly to cater for the automatic creation (factory) of DOMNodes
>>>> triggered from jxpath createPath statements...
>>>>
>>>> But I have to admit I can't find where that thingy gets registered
>>>> on the jxpath context (too much relying on the advanced search of
>>>> eclipse?)
>>>
>>>
>>>
>>>
>>>
>>> Sorry, I'm very late on all this.
>>>
>>> Actually, there's currently no use of this class in Cocoon samples,
>>> but I use it on my projects. Here's how: in the flow, I don't
>>> load/save the DOM directly, but through a JXPathContext as follows;
>>>
>>> var doc = readDocument(url);
>>> var bindingCtx = createBindingContext(doc);
>>> form.load(bindingCtx);
>>> form.showForm("pipeline");
>>> form.save(bindingCtx);
>>>
>>> And here's the createBindingContext function:
>>>
>>> function createBindingContext(document) {
>>> // Create a JXPath context on the document.
>>> var xpathContext =
>>> Packages.org.apache.commons.jxpath.JXPathContext.newContext(document);
>>> // Set it to lenient
>>> xpathContext.setLenient(true);
>>> // Add the necessary factory create elements and attributes as
>>> needed on non-existing paths
>>> xpathContext.setFactory(new
>>> Packages.org.apache.cocoon.util.jxpath.DOMFactory());
>>> return xpathContext;
>>> }
>>>
>>>
>>
>> Thx for explaining!
>>
>>> Having to explain how this work yesterday during a training, I felt
>>> that it should be better hidden in the binding machinery, since this
>>> is somehow needed every time we bind a form do a DOM (unless the DOM
>>> already contains the whole XML structure).
>>>
>>> So what about adding this into the AbstractJXPathBinding: if the
>>> object passed to load/save is a Node, then add the DOMFactory
>>> automatically.
>>
>>
>>
>> Makes sense!
>> (that is were I was looking for the registration in the first place :-))
>>
>>
>> Only thing to look out for is the possible combination with the
>> insert-node binding? (haven't checked yet how jxpath handles multiple
>> registries)
>
>
>
> We may create a child JXPathContext in InsertNodeJXPathBinding to avoid
> overriding the DOMFactory, but I'm wondering if using a factory is
> needed at all in InsertNode: isn't a simple "appendChild" enough?
>
> i.e. Node node =
> (Node)jxPathContext.getContextPointer().getNode().appendChild(toInsert)
>
that is what the factory is doing :-)
but I catch your drift: the detour is not really needed...
in any case: I'll have a special look at this when I make the changes
>> On a side-note: isn't the utility class a more natural addition to
>> jxpath (in the long run?)
>
>
>
> Sure, we may contribute it. But there's still a problem that needs to be
> fixed, which is that it fails to create an attribute whose owner element
> doesn't exist.
>
fine, was just a thought popping up, thx for explaining
>> And finally:
>> I'm taking it you are quite ok with the rest of the proposal?
>> (just wanted to check)
>
>
>
> Basically, I'm ok with having the two kinds of binding sharing a similar
> syntax (on-bind, on-insert, etc), but I'm not sure merging them in a
> single binding is a good idea, as apart "row-path" and "parent-path",
> their other attributes are very, very different.
>
yep, that is the exercise ahead of us: find an optimal way to do it, as
you can see from the mails, my own vision is still shifting...
> So I would better be in favor of some more explicit names such as
> "delta-repeater" for "repeater" and "override-repeater" for
> "simple-repeater".
>
> WDYT?
>
I'm still closer to the strategy attribute idea, but I definately agree
it could be separated classes.... (shared stuff common, different stuff
separated?)
IMHO having separate elements confuses people more then having a
strategy-selecting attribute, but that might be just an impression?
maybe odd, but a side-effect of the attribute thingy will be that the
alternatives are more naturally documented together...
I like the name delta-repeater more then my own proposal of diff-repeater,
but simple and override score less then the rebuild-repeater?
more opinions?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
>
>
> Sylvain Wallez wrote:
>
> <snip />
>
>>>> I was attempting and failing to bind to an XML document. The load
>>>> worked, but the save gave the exception.
>>>
>>>
>>>
>>>
>>> Sylvain?
>>>
>>> I know Sylvain created this:
>>> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/util/jxpath/DOMFactory.java
>>>
>>> exactly to cater for the automatic creation (factory) of DOMNodes
>>> triggered from jxpath createPath statements...
>>>
>>> But I have to admit I can't find where that thingy gets registered
>>> on the jxpath context (too much relying on the advanced search of
>>> eclipse?)
>>
>>
>>
>>
>> Sorry, I'm very late on all this.
>>
>> Actually, there's currently no use of this class in Cocoon samples,
>> but I use it on my projects. Here's how: in the flow, I don't
>> load/save the DOM directly, but through a JXPathContext as follows;
>>
>> var doc = readDocument(url);
>> var bindingCtx = createBindingContext(doc);
>> form.load(bindingCtx);
>> form.showForm("pipeline");
>> form.save(bindingCtx);
>>
>> And here's the createBindingContext function:
>>
>> function createBindingContext(document) {
>> // Create a JXPath context on the document.
>> var xpathContext =
>> Packages.org.apache.commons.jxpath.JXPathContext.newContext(document);
>> // Set it to lenient
>> xpathContext.setLenient(true);
>> // Add the necessary factory create elements and attributes as
>> needed on non-existing paths
>> xpathContext.setFactory(new
>> Packages.org.apache.cocoon.util.jxpath.DOMFactory());
>> return xpathContext;
>> }
>>
>>
>
> Thx for explaining!
>
>> Having to explain how this work yesterday during a training, I felt
>> that it should be better hidden in the binding machinery, since this
>> is somehow needed every time we bind a form do a DOM (unless the DOM
>> already contains the whole XML structure).
>>
>> So what about adding this into the AbstractJXPathBinding: if the
>> object passed to load/save is a Node, then add the DOMFactory
>> automatically.
>
>
> Makes sense!
> (that is were I was looking for the registration in the first place :-))
>
>
> Only thing to look out for is the possible combination with the
> insert-node binding? (haven't checked yet how jxpath handles multiple
> registries)
We may create a child JXPathContext in InsertNodeJXPathBinding to avoid
overriding the DOMFactory, but I'm wondering if using a factory is
needed at all in InsertNode: isn't a simple "appendChild" enough?
i.e. Node node =
(Node)jxPathContext.getContextPointer().getNode().appendChild(toInsert)
> On a side-note: isn't the utility class a more natural addition to
> jxpath (in the long run?)
Sure, we may contribute it. But there's still a problem that needs to be
fixed, which is that it fails to create an attribute whose owner element
doesn't exist.
> And finally:
> I'm taking it you are quite ok with the rest of the proposal?
> (just wanted to check)
Basically, I'm ok with having the two kinds of binding sharing a similar
syntax (on-bind, on-insert, etc), but I'm not sure merging them in a
single binding is a good idea, as apart "row-path" and "parent-path",
their other attributes are very, very different.
So I would better be in favor of some more explicit names such as
"delta-repeater" for "repeater" and "override-repeater" for
"simple-repeater".
WDYT?
--
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: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Marc Portier <mp...@outerthought.org>.
Timothy Larson wrote:
>
>>Sylvain Wallez wrote:
>>
<snip />
>>>So what about adding this into the AbstractJXPathBinding: if the object
>>>passed to load/save is a Node, then add the DOMFactory automatically.
>
>
> I had not looked into that technique, but if we add on-insert-row to the
> simple repeater then it seems to solve itself because insert-node registers
> a factory.
>
Just for completeness, there is a subtle difference:
The DOMFactory utility will dynamically create any XML paths as required
by jxpath's createPath statement, but actually limited to only those
required.
A nested insert-node or insert-bean will indeed register a dedicated
factory (anonymous inner class inside those bindings). For insert-node
that factory will do more then the minimum: it will copy-clone the
nested XML 'template' of the declared binding into the target back-end XML.
But as said, we surely would need to check up on the registration of
these not to overwrite/hide each other? Although I'm hoping the jxpath
context would nicely scope things according to nesting level?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms simple-repeater binding sample?)
Posted by Timothy Larson <ti...@yahoo.com>.
--- Marc Portier <mp...@outerthought.org> wrote:
> Sylvain Wallez wrote:
> > Sorry, I'm very late on all this.
That's OK. We all have work to do with different time constraints.
> > Actually, there's currently no use of this class in Cocoon samples, but
> > I use it on my projects. Here's how: in the flow, I don't load/save the
> > DOM directly, but through a JXPathContext as follows;
<snip sample code/>
It makes sense now with the help of your sample code.
> > Having to explain how this work yesterday during a training, I felt that
> > it should be better hidden in the binding machinery, since this is
> > somehow needed every time we bind a form do a DOM (unless the DOM
> > already contains the whole XML structure).
I agree this should be automated to work with the regular load/save.
> > So what about adding this into the AbstractJXPathBinding: if the object
> > passed to load/save is a Node, then add the DOMFactory automatically.
I had not looked into that technique, but if we add on-insert-row to the
simple repeater then it seems to solve itself because insert-node registers
a factory.
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
<snip />
>>> I was attempting and failing to bind to an XML document. The load
>>> worked, but the save gave the exception.
>>
>>
>>
>> Sylvain?
>>
>> I know Sylvain created this:
>> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/util/jxpath/DOMFactory.java
>>
>> exactly to cater for the automatic creation (factory) of DOMNodes
>> triggered from jxpath createPath statements...
>>
>> But I have to admit I can't find where that thingy gets registered on
>> the jxpath context (too much relying on the advanced search of eclipse?)
>
>
>
> Sorry, I'm very late on all this.
>
> Actually, there's currently no use of this class in Cocoon samples, but
> I use it on my projects. Here's how: in the flow, I don't load/save the
> DOM directly, but through a JXPathContext as follows;
>
> var doc = readDocument(url);
> var bindingCtx = createBindingContext(doc);
> form.load(bindingCtx);
> form.showForm("pipeline");
> form.save(bindingCtx);
>
> And here's the createBindingContext function:
>
> function createBindingContext(document) {
> // Create a JXPath context on the document.
> var xpathContext =
> Packages.org.apache.commons.jxpath.JXPathContext.newContext(document);
> // Set it to lenient
> xpathContext.setLenient(true);
> // Add the necessary factory create elements and attributes as needed
> on non-existing paths
> xpathContext.setFactory(new
> Packages.org.apache.cocoon.util.jxpath.DOMFactory());
> return xpathContext;
> }
>
>
Thx for explaining!
> Having to explain how this work yesterday during a training, I felt that
> it should be better hidden in the binding machinery, since this is
> somehow needed every time we bind a form do a DOM (unless the DOM
> already contains the whole XML structure).
>
> So what about adding this into the AbstractJXPathBinding: if the object
> passed to load/save is a Node, then add the DOMFactory automatically.
>
> Sylvain
>
Makes sense!
(that is were I was looking for the registration in the first place :-))
Only thing to look out for is the possible combination with the
insert-node binding? (haven't checked yet how jxpath handles multiple
registries)
On a side-note: isn't the utility class a more natural addition to
jxpath (in the long run?)
And finally:
I'm taking it you are quite ok with the rest of the proposal?
(just wanted to check)
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
> Timothy Larson wrote:
>
>> --- Marc Portier <mp...@outerthought.org> wrote:
>>
>>> Timothy,
>>>
>>> the rudimentary dox (see wiki) on the simple-repeater-binding are
>>> explaining this:
>>>
>>> It is currently only supporting binding back to XML (so I suspect
>>> that you were testing versus a java beans backend model here?)
>>
>>
>> I was attempting and failing to bind to an XML document. The load
>> worked, but the save gave the exception.
>
>
> Sylvain?
>
> I know Sylvain created this:
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/util/jxpath/DOMFactory.java
>
> exactly to cater for the automatic creation (factory) of DOMNodes
> triggered from jxpath createPath statements...
>
> But I have to admit I can't find where that thingy gets registered on
> the jxpath context (too much relying on the advanced search of eclipse?)
Sorry, I'm very late on all this.
Actually, there's currently no use of this class in Cocoon samples, but
I use it on my projects. Here's how: in the flow, I don't load/save the
DOM directly, but through a JXPathContext as follows;
var doc = readDocument(url);
var bindingCtx = createBindingContext(doc);
form.load(bindingCtx);
form.showForm("pipeline");
form.save(bindingCtx);
And here's the createBindingContext function:
function createBindingContext(document) {
// Create a JXPath context on the document.
var xpathContext =
Packages.org.apache.commons.jxpath.JXPathContext.newContext(document);
// Set it to lenient
xpathContext.setLenient(true);
// Add the necessary factory create elements and attributes as needed
on non-existing paths
xpathContext.setFactory(new
Packages.org.apache.cocoon.util.jxpath.DOMFactory());
return xpathContext;
}
Having to explain how this work yesterday during a training, I felt that
it should be better hidden in the binding machinery, since this is
somehow needed every time we bind a form do a DOM (unless the DOM
already contains the whole XML structure).
So what about adding this into the AbstractJXPathBinding: if the object
passed to load/save is a Node, then add the DOMFactory automatically.
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: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Marc Portier <mp...@outerthought.org>.
Timothy,
looks like I missed out on this posting earlier, sorry for that.
Timothy Larson wrote:
> --- Marc Portier <mp...@outerthought.org> wrote:
>
>>Timothy Larson wrote:
>>
>>>--- Marc Portier <mp...@outerthought.org> wrote:
>>>
>>>>Timothy Larson wrote:
>>>>
>>>>>--- Marc Portier <mp...@outerthought.org> wrote:
>
>
> == Repeater-binding update-strategy ==
>
> This is a summary to check if our thoughts are in sync.
>
> Options:
> With unique rows: delta (update in place) or rebuild (remove all and re-insert)
> With non-unique rows: only rebuild
>
> Delta
> On load
> Row order in repeater will match row order in xml.
> All or selected rows may be loaded into repeater widget.
> On save
> Row order in xml is preserved, new rows appended in repeater order.
> Rows not present in repeater will not be changed in xml.
>
> Rebuild
> On load
> Row order in repeater will match row order in xml.
> All or selected rows in xml are loaded into repeater.
> On save
> Row order in xml is changed to match row order in repeater.
> Rows not present in repeater will be removed from xml.
>
>
great summary! that's it.
>>2/ @strategy="rebuild" with unique-id and path known to survive sparse-ness
>>(Q: do we need an additional attribute explicitely stating that the
>>parse-ness is to be taken care off? or should we always try when the
>>unique-id is known?)
>
>
> I think you are suggesting for the rebuild strategy to have an attribute to
> indicate that selected rows are to be "officially" loaded into the repeater,
> while the rest of the rows should be loaded as "hidden" rows to allow them to
> be preserved on save. Is this the right interpretation?
>
I was rather talking about not-bound columns then about non-bound rows...
suppose repeater-values-in-model:
id | att_x | att_y
----+--------+-------
1 | A | yes
2 | B | no
and you bind this into a form-model that only shows/allows to edit the
att_x part:
form looks like this:
att_x
[ A]
[ B]
then upon bind-save using the rebuild strategy we will not have the
original values of the att_y present in the repeater context (unless,
they would be there as hidden variables)
the point I try to make is that the rebuild-strategy that KNOWS about
unique-ids really is capable of preserving the att_y values by matching
the id's of the rows (like this you would only need one hidden var for
the id and still recover all the fields that were not bound)
actually in this case the term 'rebuild' reflects the fact that we
rebuild the list and it's order, but not really rebuild the
child-elements that already existed (rather move them back in from some
back-up copy before rebuilding the list)
> Just preserving your mental note for you:
>
>>(mental note to self: recent row-path-insert needs to get a place in
>>side this new multiple strategy stuff...)
>
>
>>just a concern about not cluthering too much inside one class, so we
>>could put the common things in a shared base-class but still separate
>>out the distinct algorithms into disctinct classes?
>
>
> I think you have me convinced...
>
>
>>yeah, I like the idea of the @strategy be _interpreted_ by the
>>Binding-building process and thus yield directly classes shaped for that
>>particular strategy.
>
>
> ... because I agree with you here for the performance reasons you described.
>
>
>>But euh, the wt:repeate-widget can contain pretty much everything in the
>>content model, right?
>>
>>pfew, this comes close to trying to building a generic DOM-constructor
>>editor, no?
>
>
> Yes, with the ability to interpret and support the domain-specific knowledge
> that is being encoded in the DOM.
>
>
>>so what does your form-definition and form-template for editing these
>>files look like, maybe that gives me some inspiration here?
>
>
> Watch for an update coming soon to the big patch on my wiki page:
> http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson
> The other code in the patch is required to make the definitions and templates
> work, because they use "union", etc..
>
reading up... haven't applied the diff yet :-(
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms simple-repeater binding sample?)
Posted by Timothy Larson <ti...@yahoo.com>.
--- Marc Portier <mp...@outerthought.org> wrote:
> Timothy Larson wrote:
> > --- Marc Portier <mp...@outerthought.org> wrote:
> >>Timothy Larson wrote:
> >>>--- Marc Portier <mp...@outerthought.org> wrote:
== Repeater-binding update-strategy ==
This is a summary to check if our thoughts are in sync.
Options:
With unique rows: delta (update in place) or rebuild (remove all and re-insert)
With non-unique rows: only rebuild
Delta
On load
Row order in repeater will match row order in xml.
All or selected rows may be loaded into repeater widget.
On save
Row order in xml is preserved, new rows appended in repeater order.
Rows not present in repeater will not be changed in xml.
Rebuild
On load
Row order in repeater will match row order in xml.
All or selected rows in xml are loaded into repeater.
On save
Row order in xml is changed to match row order in repeater.
Rows not present in repeater will be removed from xml.
> 2/ @strategy="rebuild" with unique-id and path known to survive sparse-ness
> (Q: do we need an additional attribute explicitely stating that the
> parse-ness is to be taken care off? or should we always try when the
> unique-id is known?)
I think you are suggesting for the rebuild strategy to have an attribute to
indicate that selected rows are to be "officially" loaded into the repeater,
while the rest of the rows should be loaded as "hidden" rows to allow them to
be preserved on save. Is this the right interpretation?
Just preserving your mental note for you:
> (mental note to self: recent row-path-insert needs to get a place in
> side this new multiple strategy stuff...)
> just a concern about not cluthering too much inside one class, so we
> could put the common things in a shared base-class but still separate
> out the distinct algorithms into disctinct classes?
I think you have me convinced...
> yeah, I like the idea of the @strategy be _interpreted_ by the
> Binding-building process and thus yield directly classes shaped for that
> particular strategy.
... because I agree with you here for the performance reasons you described.
> But euh, the wt:repeate-widget can contain pretty much everything in the
> content model, right?
>
> pfew, this comes close to trying to building a generic DOM-constructor
> editor, no?
Yes, with the ability to interpret and support the domain-specific knowledge
that is being encoded in the DOM.
> so what does your form-definition and form-template for editing these
> files look like, maybe that gives me some inspiration here?
Watch for an update coming soon to the big patch on my wiki page:
http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson
The other code in the patch is required to make the definitions and templates
work, because they use "union", etc..
--Tim Larson
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Marc Portier <mp...@outerthought.org>.
Timothy Larson wrote:
> --- Marc Portier <mp...@outerthought.org> wrote:
>
>>Timothy Larson wrote:
>>
>>>--- Marc Portier <mp...@outerthought.org> wrote:
>>
>>I see a need for a combination of the 'simple' strategy _and_ the use of
>>unique identifiers:
>
>
> Not sure if I caught this correctly...
> are you suggesting to have these three strategies?:
>
> * update in place per changed item (currently in "repeater")
> * delete and re-add per changed item (new)
> * delete all items and re-add all item (currently in "simple-repeater")
>
yep, think you have a point here, when there are no id's then the 3rd
one is obviously the only valid one, be it about sparse child-elements
or not (we can't find them back anyway, right?)
so a bit more explicit we would have
1/ @strategy="delta" where
if ORIGINAL=[ITEM(id=a,K,1), ITEM(id=b,L,2), ITEM(id=c,M,3)]
and returned after validation the WIDGET-TREE=[ITEM(id=b,10),
ITEM(id=c,11 ), ITEM(id=*,12)]
then the save operation would need to leave the backend in this state
FINAL = [ITEM(id=a,k,1){"MARKED FOR OR DELETED"}, ITEM(id=b,L,10),
ITEM(id=c,M,11), ITEM(id=*,as templated by on-insert-row,12)]
NOTE:
- this would have yielded the same row for any order of the rows coming
back from the repeater: This strategy just finds and matches the
delta's on the children themselves, it is not considering the order of
the rows in the repeater to be of any value
2/ @strategy="rebuild" with unique-id and path known to survive sparse-ness
(Q: do we need an additional attribute explicitely stating that the
parse-ness is to be taken care off? or should we always try when the
unique-id is known?)
then taking a similar case
ORIGINAL = [ITEM(id=a,K,1), ITEM(id=b,L,2), ITEM(id=c,M,3)]
WIDGET-TREE = [ITEM(id=c,11 ), ITEM(id=b,10), ITEM(id=*,12)]
this would yield
FINAL = [ ITEM(id=c,M,11), ITEM(id=b,L,10), ITEM(id=*,as templated by
on-insert-row,12)]
NOTE:
- Items B and C got swapped!
- A got deleted: so there is (compared to the first strategy) an
implicit <on-delete-row><delete-node/><on-delete-row>
- sparse-ness was survived
3/ @strategy="rebuild" without unique-id and path defined: no match possible
then again taking
ORIGINAL = [ITEM(id=a,K,1), ITEM(id=b,L,2), ITEM(id=c,M,3)]
WIDGET-TREE = [ITEM(id=c,11 ), ITEM(id=b,10), ITEM(id=*,12)]
we would now get
FINAL = [ ITEM(id=c,as templated by on-insert-row,11), ITEM(id=b,as
templated by on-insert-row,10), ITEM(id=*,as templated by on-insert-row,12)]
meaning it did not preserver the unbound data
(mental note to self: recent row-path-insert needs to get a place in
side this new multiple strategy stuff...)
>
>>>>- confusion between simple and classic repeater binding... I understand
>>>>that we have two strategies that both have their special uses cases, but
>>>>I would like to have a more syntactic similarities between both to lower
>>>>the usage confusion (and switching effort) ... in fact maybe we should
>>>>even go for a single <wb: element-name for both and switch between both
>>>>by using some @strategy, @flavour or @type
>>
>>in every case, since my comment here was about user-confusion:
>>I would like the fact that we make this chosing of binding strategy
>>reflected in a very explicit attribute (rather then the more implicit
>>changing behaviour you have now?)
>
>
> +1 to using a single wb: element name with @strategy.
>
>
>>as a consequence we should probably keep the implementation classes
>>separate as well (although since more and more declaration stuff gets
>>shared between both some strategy pattern might make sense)
>
>
> Because they share a lot of code, I don't see why we should keep the
> implementing classes separate. Could you explain?
>
just a concern about not cluthering too much inside one class, so we
could put the common things in a shared base-class but still separate
out the distinct algorithms into disctinct classes?
> <snip name discussion/>
>
> The names are intriquing , but lets decide if we even need split
> classes if we use @strategy.
>
yeah, I like the idea of the @strategy be _interpreted_ by the
Binding-building process and thus yield directly classes shaped for that
particular strategy.
I prefer it to the alternative of having the @strategy ripple up into
being a member of the run-time Binding class, since then we would need
to run-time check this strategy member to decide what to do (a bit odd,
since we know that already at the time we construct the Tree of
Bindings, and it cannot change during the lifetime of a Bidning.
>
>>>>- in any case we should remove the XML only limitation from the simple
>>>>repeater, since it's somewhat fighting with the principle of least
>>>>surprise, no?
>
> ...
>
>>yep, Jeremy in the mentioned thead above
>>but even without it, it just makes sense to maintain this (implicit?)
>>contract of the JXPathBinding family: it is expected to both work for
>>XML and Beans
>>(subclasses should never lower contracts from their parents)
>
>
> I agree in priciple, but do not have the will right now to fix it myself.
>
I have, no pro, I would of have earlier, but then I started to remove
the lid and found more crawling worms :-)
Thx for joining in to the discussion, it helped straighten my thouhts out.
> <snip new explaination of @row-path-insert/>
>
>>I'm ready to commit this, supposedly the cvs-diff will make this very clear?
>
>
> The new explaination and the diff make it very clear, thanks. Looks good.
>
yep, thx to Jan for starting to use the predicates!
>
>>>But it cannot handle this:
>>> <wt:repeater-widget>
>>> <wt:widget-label id="sample-field"/>
>>> <wt:widget id="sample-field"/>
>>> </wt:repeater-widget>
>>
>>wow, you make me very curious here!!!
>>are you doing what I think you are doing? mucho exciting stuff man!
>
>
> Yes, I am trying to allow the editing of any XML file, with the intention
> of round-tripping form definitions, templates, etc. in the CocoonForms-based
> forms and reports development GUI.
>
then you are surely more into the stuff Sylvain was doing: strict
binding to XML stuff...
>
>>hm, a repeater of binding-context-nodes could do this?
>>but maybe I'm missing something?
>
>
> Would you explain what you mean? Your second explainations seem to be very
> clear. My current code gets the underlying Node and adds children to it
> directly. If you have a way that is more generic JXPath, I'm all ears.
>
nope, I was thinkin' about something else obviously, sorry there
But euh, the wt:repeate-widget can contain pretty much everything in the
content model, right?
pfew, this comes close to trying to building a generic DOM-constructor
editor, no?
so what does your form-definition and form-template for editing these
files look like, maybe that gives me some inspiration here?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms simple-repeater binding sample?)
Posted by Timothy Larson <ti...@yahoo.com>.
--- Marc Portier <mp...@outerthought.org> wrote:
> Timothy Larson wrote:
> > --- Marc Portier <mp...@outerthought.org> wrote:
> I see a need for a combination of the 'simple' strategy _and_ the use of
> unique identifiers:
Not sure if I caught this correctly...
are you suggesting to have these three strategies?:
* update in place per changed item (currently in "repeater")
* delete and re-add per changed item (new)
* delete all items and re-add all item (currently in "simple-repeater")
> >>- confusion between simple and classic repeater binding... I understand
> >>that we have two strategies that both have their special uses cases, but
> >>I would like to have a more syntactic similarities between both to lower
> >>the usage confusion (and switching effort) ... in fact maybe we should
> >>even go for a single <wb: element-name for both and switch between both
> >>by using some @strategy, @flavour or @type
>
> in every case, since my comment here was about user-confusion:
> I would like the fact that we make this chosing of binding strategy
> reflected in a very explicit attribute (rather then the more implicit
> changing behaviour you have now?)
+1 to using a single wb: element name with @strategy.
> as a consequence we should probably keep the implementation classes
> separate as well (although since more and more declaration stuff gets
> shared between both some strategy pattern might make sense)
Because they share a lot of code, I don't see why we should keep the
implementing classes separate. Could you explain?
<snip name discussion/>
The names are intriquing , but lets decide if we even need split
classes if we use @strategy.
> >>- in any case we should remove the XML only limitation from the simple
> >>repeater, since it's somewhat fighting with the principle of least
> >>surprise, no?
...
> yep, Jeremy in the mentioned thead above
> but even without it, it just makes sense to maintain this (implicit?)
> contract of the JXPathBinding family: it is expected to both work for
> XML and Beans
> (subclasses should never lower contracts from their parents)
I agree in priciple, but do not have the will right now to fix it myself.
<snip new explaination of @row-path-insert/>
> I'm ready to commit this, supposedly the cvs-diff will make this very clear?
The new explaination and the diff make it very clear, thanks. Looks good.
> > But it cannot handle this:
> > <wt:repeater-widget>
> > <wt:widget-label id="sample-field"/>
> > <wt:widget id="sample-field"/>
> > </wt:repeater-widget>
>
> wow, you make me very curious here!!!
> are you doing what I think you are doing? mucho exciting stuff man!
Yes, I am trying to allow the editing of any XML file, with the intention
of round-tripping form definitions, templates, etc. in the CocoonForms-based
forms and reports development GUI.
> hm, a repeater of binding-context-nodes could do this?
> but maybe I'm missing something?
Would you explain what you mean? Your second explainations seem to be very
clear. My current code gets the underlying Node and adds children to it
directly. If you have a way that is more generic JXPath, I'm all ears.
> > Thanks for your consideration,
> happy to, sorry for the delay in the roundtrip, higher availability
> today (for some more hours)
Hope you get a good return on the time you spend on this.
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
simple-repeater binding sample?)
Posted by Marc Portier <mp...@outerthought.org>.
Timothy Larson wrote:
> --- Marc Portier <mp...@outerthought.org> wrote:
>
>>Timothy,
>>
>>the rudimentary dox (see wiki) on the simple-repeater-binding are
>>explaining this:
>>
>>It is currently only supporting binding back to XML (so I suspect that
>>you were testing versus a java beans backend model here?)
>
>
> I was attempting and failing to bind to an XML document. The load worked,
> but the save gave the exception.
>
Sylvain?
I know Sylvain created this:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/util/jxpath/DOMFactory.java
exactly to cater for the automatic creation (factory) of DOMNodes
triggered from jxpath createPath statements...
But I have to admit I can't find where that thingy gets registered on
the jxpath context (too much relying on the advanced search of eclipse?)
>
>>we briefly discussed this recently (and I was getting into doing it, but
>>am caught up on a local conference here the next few days)
>>
>>see this thread:
>>http://marc.theaimsgroup.com/?t=106976455300001&r=1&w=2
>>
>>the idea would be to have a similar entry for <on-insert-row> nested in
>>the simple-repeater-binding as borrowed from the classic repeater-binding?
>
>
> While waiting for a response about the simple repeater binding, I modified
> the main repeater binding to support binding without a unique id. You just
> leave off the unique-row-id and unique-path attributes, and it acts like a
> simple repeater binding but with the on-* elements added. Is this near what
> you are thinking? If it is, I will post it when I get back to work tomorrow.
>
not entirely
I see a need for a combination of the 'simple' strategy _and_ the use of
unique identifiers:
suppose your bean is only sparsely bound to the form-widgets: then you
would loose some fields when you just delete and rebuild --> so you
would need to
1/ copy them over from some back-up space
2/ when you find them back based on their unique ID
of course this kind of expects that we can augment the declarations
(more atts) to communicate the methods on the parent-bean to create that
clone of kids, and to reset/empty that list.
>
>>in fact I started thinking about this some more first (also based on
>>some private mails with Jeremy who was so kind to let me in on some more
>> hibernate details and issues in his current project)
>>
>>some (random order) observations/suggestions on repeater binding as is now:
>>
>>- repeater-bindings have no @readonly to shut down the save() operation
>> like the field-binding has it.
>>
>>- in fact it also struck me that the @readonly concept only allows us to
>>choose between two modes of operation : 1/ do load AND save 2/ do only
>>load. Maybe we should provide a generic attribute on all bindings that
>>looks like @direction and can hold load|save|both (probably even
>>implement this at the level of the abstract base class?)
>
>
> +1 I was thinking this also.
>
>
>>- confusion between simple and classic repeater binding... I understand
>>that we have two strategies that both have their special uses cases, but
>>I would like to have a more syntactic similarities between both to lower
>>the usage confusion (and switching effort) ... in fact maybe we should
>>even go for a single <wb: element-name for both and switch between both
>>by using some @strategy, @flavour or @type
>
>
> Please see the repeater modification mentioned above.
>
pls see my comments above :-)
in every case, since my comment here was about user-confusion:
I would like the fact that we make this chosing of binding strategy
reflected in a very explicit attribute (rather then the more implicit
changing behaviour you have now?)
as a consequence we should probably keep the implementation classes
separate as well (although since more and more declaration stuff gets
shared between both some strategy pattern might make sense)
which brings me to the aspect of developer-confusion: we should change
the names:
- RepeaterBinding suggests it is the only one (which is a claim we
cannot make given Sylvain's and Jeremy's use case ?)
- SimpleRepeaterBinding has a name which actually more reflects the
developer appreciation of the algorithm used, then it is giving a
functional hint about its usefulness
(as I was jokingly saying to Bruno: its a bit like naming your class
TheLessThen500LoCImplementation vs TheMoreThen1000LoCImplementation :-))
new suggestions coming to mind:
RepeaterBinding --> DiffRepeaterBinding (wb:repeater/@strategy="diff")
SimpleRepeaterBinding --> RebuildRepeaterBinding
(wb:repeater/@strategy="rebuild", which would be my default choice, even
if that breaks backwards compat, we are still beta after all)
of course using the Strategy pattern things would look slightly different.
>
>>- in any case we should remove the XML only limitation from the simple
>>repeater, since it's somewhat fighting with the principle of least
>>surprise, no?
>
>
> +1 I do not have a use case myself yet, but I faintly remember someone
> else may have presented one?
>
yep, Jeremy in the mentioned thead above
but even without it, it just makes sense to maintain this (implicit?)
contract of the JXPathBinding family: it is expected to both work for
XML and Beans
(subclasses should never lower contracts from their parents)
>
>>oh, I also thought some about this:
>>http://marc.theaimsgroup.com/?t=107035200100002&r=1&w=2
>>and currently have a patch on HD that is introducing an extra attribute
>>row-path-insert for the classic (not-simple) repeater-binding that is
>>used for depicting where the rows to be inserted should go in... (in
>>stead of just reusing the @row-path for that purpose)
>
>
> Not sure I understand this yet. Would you expand on this? Explain it
> in different words and I might catch the idea.
>
here comes:
you start off with a backend-model that has
[ITEM(@id=A, @x=1), ITEM(@id=B,@x=1), ITEM(@id=C,@x=2), ITEM(@id=D,@x=1)]
using current repeater impl you can load this stuff by filtering with an
xpath-predicate ./ITEM[@x=1]
which results in having a repeater-rows in the form only showing the
ITEMS A,B and D (which match the predicate)
now suppose an added row in the repeater ITEM(id=E) that needs to be
added after the existing D-ITEM... using the row-path with predicate
this will result in an error, since the repeater-strategy is just
building this xpath: ./ITEM[@x=1][5] which is (a bit logically) not
supported by jxpath's create-path statement (too much conditionals to
know what to explicitely build?)
my first naieve thought was to autmatically parse/remove the predicate
from the row-path to deduce the row-path-insert (to use for the inserts)
however these predicates can occur inside every step of the row-path,
and why not just make it explicit so the user can even specify another
location for the inserted-rows?
I'm ready to commit this, supposedly the cvs-diff will make this very clear?
>
>>but maybe we should take a more holistic view on things and maybe first
>>discuss a broader binding-syntax redo starting from above suggestions?
>>
>>(by the way: any suggestions from users having a more usability opinion
>>is welcome, maybe I was (we are) a tad too much focussed on processing
>>the thing when we defined the original semantics of the file?)
>>
>>
>>in any case I hope we can synchronize our updating efforts here?
>>
>>wdot?
>
>
> I think so.
>
>
>>PS: sorry for lagging behind on your new widget-types, but wouldn't they
>>require separate and specific binding-types rather then fixing the
>>repeater-binding to work on them as well?
>
>
> I *am* creating new specific binding types, but I also have some repeater
ah ok, didn't catch that, thx for explaining
> needs that are not satified yet when using the new binding types to create
> the form design gui's binding. I need the repeater to load and save items
> that are not wrapped in a commonly named element. The current repeater
> binding can deal with this:
> <contacts>
> <contact>
> <name>John Doe</name>
> </contact>
> <contact>
> <name>John Doe's twin</name>
> </contact>
> </contacts>
> But it cannot handle this:
> <wt:repeater-widget>
> <wt:widget-label id="sample-field"/>
> <wt:widget id="sample-field"/>
> </wt:repeater-widget>
wow, you make me very curious here!!!
are you doing what I think you are doing? mucho exciting stuff man!
> because the row elements "wt:widget-label" and "wt:widget" differ and are
> not each wrapped in a commonly named row element like "contact" in the
> first example.
>
hm, a repeater of binding-context-nodes could do this?
but maybe I'm missing something?
> I tried to continue my modifications to the repeater binding to support
> this, but it is difficult due to the semantics of the path and context
> calls in jxpath. Loading works now, but if you have any ideas how to do
> the saving without invasive changes to the existing bindings I would jump
> for joy. I just want each bound vidget to be appended as the last child
> of the containing element. I almost have a very inefficent method working.
>
see above?
> Thanks for your consideration,
happy to, sorry for the delay in the roundtrip, higher availability
today (for some more hours)
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms simple-repeater binding sample?)
Posted by Timothy Larson <ti...@yahoo.com>.
--- Marc Portier <mp...@outerthought.org> wrote:
> Timothy,
>
> the rudimentary dox (see wiki) on the simple-repeater-binding are
> explaining this:
>
> It is currently only supporting binding back to XML (so I suspect that
> you were testing versus a java beans backend model here?)
I was attempting and failing to bind to an XML document. The load worked,
but the save gave the exception.
> we briefly discussed this recently (and I was getting into doing it, but
> am caught up on a local conference here the next few days)
>
> see this thread:
> http://marc.theaimsgroup.com/?t=106976455300001&r=1&w=2
>
> the idea would be to have a similar entry for <on-insert-row> nested in
> the simple-repeater-binding as borrowed from the classic repeater-binding?
While waiting for a response about the simple repeater binding, I modified
the main repeater binding to support binding without a unique id. You just
leave off the unique-row-id and unique-path attributes, and it acts like a
simple repeater binding but with the on-* elements added. Is this near what
you are thinking? If it is, I will post it when I get back to work tomorrow.
> in fact I started thinking about this some more first (also based on
> some private mails with Jeremy who was so kind to let me in on some more
> hibernate details and issues in his current project)
>
> some (random order) observations/suggestions on repeater binding as is now:
>
> - repeater-bindings have no @readonly to shut down the save() operation
> like the field-binding has it.
>
> - in fact it also struck me that the @readonly concept only allows us to
> choose between two modes of operation : 1/ do load AND save 2/ do only
> load. Maybe we should provide a generic attribute on all bindings that
> looks like @direction and can hold load|save|both (probably even
> implement this at the level of the abstract base class?)
+1 I was thinking this also.
> - confusion between simple and classic repeater binding... I understand
> that we have two strategies that both have their special uses cases, but
> I would like to have a more syntactic similarities between both to lower
> the usage confusion (and switching effort) ... in fact maybe we should
> even go for a single <wb: element-name for both and switch between both
> by using some @strategy, @flavour or @type
Please see the repeater modification mentioned above.
> - in any case we should remove the XML only limitation from the simple
> repeater, since it's somewhat fighting with the principle of least
> surprise, no?
+1 I do not have a use case myself yet, but I faintly remember someone
else may have presented one?
> oh, I also thought some about this:
> http://marc.theaimsgroup.com/?t=107035200100002&r=1&w=2
> and currently have a patch on HD that is introducing an extra attribute
> row-path-insert for the classic (not-simple) repeater-binding that is
> used for depicting where the rows to be inserted should go in... (in
> stead of just reusing the @row-path for that purpose)
Not sure I understand this yet. Would you expand on this? Explain it
in different words and I might catch the idea.
> but maybe we should take a more holistic view on things and maybe first
> discuss a broader binding-syntax redo starting from above suggestions?
>
> (by the way: any suggestions from users having a more usability opinion
> is welcome, maybe I was (we are) a tad too much focussed on processing
> the thing when we defined the original semantics of the file?)
>
>
> in any case I hope we can synchronize our updating efforts here?
>
> wdot?
I think so.
> PS: sorry for lagging behind on your new widget-types, but wouldn't they
> require separate and specific binding-types rather then fixing the
> repeater-binding to work on them as well?
I *am* creating new specific binding types, but I also have some repeater
needs that are not satified yet when using the new binding types to create
the form design gui's binding. I need the repeater to load and save items
that are not wrapped in a commonly named element. The current repeater
binding can deal with this:
<contacts>
<contact>
<name>John Doe</name>
</contact>
<contact>
<name>John Doe's twin</name>
</contact>
</contacts>
But it cannot handle this:
<wt:repeater-widget>
<wt:widget-label id="sample-field"/>
<wt:widget id="sample-field"/>
</wt:repeater-widget>
because the row elements "wt:widget-label" and "wt:widget" differ and are
not each wrapped in a commonly named row element like "contact" in the
first example.
I tried to continue my modifications to the repeater binding to support
this, but it is difficult due to the semantics of the path and context
calls in jxpath. Loading works now, but if you have any ideas how to do
the saving without invasive changes to the existing bindings I would jump
for joy. I just want each bound vidget to be appended as the last child
of the containing element. I almost have a very inefficent method working.
Thanks for your consideration,
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
[cforms] New Repeater Binding Semantics (was Re: CocoonForms simple-repeater
binding sample?)
Posted by Marc Portier <mp...@outerthought.org>.
Timothy,
the rudimentary dox (see wiki) on the simple-repeater-binding are
explaining this:
It is currently only supporting binding back to XML (so I suspect that
you were testing versus a java beans backend model here?)
we briefly discussed this recently (and I was getting into doing it, but
am caught up on a local conference here the next few days)
see this thread:
http://marc.theaimsgroup.com/?t=106976455300001&r=1&w=2
the idea would be to have a similar entry for <on-insert-row> nested in
the simple-repeater-binding as borrowed from the classic repeater-binding?
in fact I started thinking about this some more first (also based on
some private mails with Jeremy who was so kind to let me in on some more
hibernate details and issues in his current project)
some (random order) observations/suggestions on repeater binding as is now:
- repeater-bindings have no @readonly to shut down the save() operation
like the field-binding has it.
- in fact it also struck me that the @readonly concept only allows us to
choose between two modes of operation : 1/ do load AND save 2/ do only
load. Maybe we should provide a generic attribute on all bindings that
looks like @direction and can hold load|save|both (probably even
implement this at the level of the abstract base class?)
- confusion between simple and classic repeater binding... I understand
that we have two strategies that both have their special uses cases, but
I would like to have a more syntactic similarities between both to lower
the usage confusion (and switching effort) ... in fact maybe we should
even go for a single <wb: element-name for both and switch between both
by using some @strategy, @flavour or @type
- in any case we should remove the XML only limitation from the simple
repeater, since it's somewhat fighting with the principle of least
surprise, no?
oh, I also thought some about this:
http://marc.theaimsgroup.com/?t=107035200100002&r=1&w=2
and currently have a patch on HD that is introducing an extra attribute
row-path-insert for the classic (not-simple) repeater-binding that is
used for depicting where the rows to be inserted should go in... (in
stead of just reusing the @row-path for that purpose)
but maybe we should take a more holistic view on things and maybe first
discuss a broader binding-syntax redo starting from above suggestions?
(by the way: any suggestions from users having a more usability opinion
is welcome, maybe I was (we are) a tad too much focussed on processing
the thing when we defined the original semantics of the file?)
in any case I hope we can synchronize our updating efforts here?
wdot?
regards,
-marc=
PS: sorry for lagging behind on your new widget-types, but wouldn't they
require separate and specific binding-types rather then fixing the
repeater-binding to work on them as well?
Timothy Larson wrote:
> --- Timothy Larson <ti...@yahoo.com> wrote:
>
>>Does anybody have a working sample of a simple-repeater binding?
>>I am trying to adapt the binding to work with (you guessed it)
>>class, new, struct, and union, but I am having trouble getting
>>the simple-repeater binding working.
>
>
> More information:
> The regular repeater binding works for me, but the simple-repeater
> throws an exception about the factory not being set on the jxpath
> context.
>
> <!-- Regular repeater binding: works -->
> <wb:repeater id="contacts"
> parent-path="contacts"
> row-path="contact"
> unique-row-id="id"
> unique-path="@id">
> <wb:on-bind>
> <wb:value id="sample" path="name"/>
> </wb:on-bind>
> </wb:repeater>
>
> <!-- Simple repeater binding: does not work -->
> <wb:simple-repeater id="contacts"
> parent-path="contacts"
> row-path="contact">
> <wb:value id="sample" path="name"/>
> </wb:simple-repeater>
>
> Exception:
>
> cause: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath contact[1];
> Factory is not set on the JXPathContext - cannot create path:
> /wd:form[1]/wd:widgets[1]/contacts[1]
>
> -----------------------------------------------
> Interesting part of exception chain stacktrace:
>
> Original Exception: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath
> contact[1]; Factory is not set on the JXPathContext - cannot create path:
> /wd:form[1]/wd:widgets[1]/contacts[1]
>
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:420)
>
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:397)
>
> at
> org.apache.cocoon.woody.binding.SimpleRepeaterJXPathBinding.saveFormToModel(SimpleRepeaterJXPathBinding.java:149)
>
> at
> org.apache.cocoon.woody.binding.ComposedJXPathBindingBase.saveFormToModel(ComposedJXPathBindingBase.java:108)
>
> at
> org.apache.cocoon.woody.binding.ContextJXPathBinding.saveFormToModel(ContextJXPathBinding.java:107)
>
> at org.apache.cocoon.woody.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:119)
>
> at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
>
> -------------------------------
> Interesting part of stacktrace:
>
> Caused by: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath contact[1];
> Factory is not set on the JXPathContext - cannot create path:
> /wd:form[1]/wd:widgets[1]/contacts[1]
>
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:420)
>
> at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:397)
>
> at
> org.apache.cocoon.woody.binding.SimpleRepeaterJXPathBinding.saveFormToModel(SimpleRepeaterJXPathBinding.java:149)
>
> at
> org.apache.cocoon.woody.binding.ComposedJXPathBindingBase.saveFormToModel(ComposedJXPathBindingBase.java:108)
>
> at
> org.apache.cocoon.woody.binding.ContextJXPathBinding.saveFormToModel(ContextJXPathBinding.java:107)
>
> at org.apache.cocoon.woody.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:119)
>
> at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
>
> ------------
> --Tim Larson
>
>
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: CocoonForms simple-repeater binding sample?
Posted by Timothy Larson <ti...@yahoo.com>.
--- Timothy Larson <ti...@yahoo.com> wrote:
> Does anybody have a working sample of a simple-repeater binding?
> I am trying to adapt the binding to work with (you guessed it)
> class, new, struct, and union, but I am having trouble getting
> the simple-repeater binding working.
More information:
The regular repeater binding works for me, but the simple-repeater
throws an exception about the factory not being set on the jxpath
context.
<!-- Regular repeater binding: works -->
<wb:repeater id="contacts"
parent-path="contacts"
row-path="contact"
unique-row-id="id"
unique-path="@id">
<wb:on-bind>
<wb:value id="sample" path="name"/>
</wb:on-bind>
</wb:repeater>
<!-- Simple repeater binding: does not work -->
<wb:simple-repeater id="contacts"
parent-path="contacts"
row-path="contact">
<wb:value id="sample" path="name"/>
</wb:simple-repeater>
Exception:
cause: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath contact[1];
Factory is not set on the JXPathContext - cannot create path:
/wd:form[1]/wd:widgets[1]/contacts[1]
-----------------------------------------------
Interesting part of exception chain stacktrace:
Original Exception: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath
contact[1]; Factory is not set on the JXPathContext - cannot create path:
/wd:form[1]/wd:widgets[1]/contacts[1]
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:420)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:397)
at
org.apache.cocoon.woody.binding.SimpleRepeaterJXPathBinding.saveFormToModel(SimpleRepeaterJXPathBinding.java:149)
at
org.apache.cocoon.woody.binding.ComposedJXPathBindingBase.saveFormToModel(ComposedJXPathBindingBase.java:108)
at
org.apache.cocoon.woody.binding.ContextJXPathBinding.saveFormToModel(ContextJXPathBinding.java:107)
at org.apache.cocoon.woody.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:119)
at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
-------------------------------
Interesting part of stacktrace:
Caused by: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath contact[1];
Factory is not set on the JXPathContext - cannot create path:
/wd:form[1]/wd:widgets[1]/contacts[1]
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:420)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:397)
at
org.apache.cocoon.woody.binding.SimpleRepeaterJXPathBinding.saveFormToModel(SimpleRepeaterJXPathBinding.java:149)
at
org.apache.cocoon.woody.binding.ComposedJXPathBindingBase.saveFormToModel(ComposedJXPathBindingBase.java:108)
at
org.apache.cocoon.woody.binding.ContextJXPathBinding.saveFormToModel(ContextJXPathBinding.java:107)
at org.apache.cocoon.woody.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:119)
at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
------------
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/