Joerg Heinicke wrote:
Vadim Gritsenko <vadim <at> reverycodes.com> writes:
<wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath"> <wb:unique-row> <wb:value id="myId1" path="myId1"/> <wb:value id="myId2" path="myId2"/> </wb:unique-row> <wb:on-bind> <wb:value id="field1" path="field1"/> <wb:value id="field2" path="field2"/> </wb:on-bind> </wb:repeater>
I also tend to prefer this approach - same reasoning with ambiguity of unique attribute.
Yes, I only see that wb:unique-row (grouped by type: unique or not unique) is outside of wb:on-bind (grouped by event: on-bind, on-insert, on-delete) though it is executed also at on-bind event.
yes, but do you find that surprising? (in fact all of the on-bind is implicit on-insert as well)
Maybe a third alternative helps for that:
<wb:repeater> <wb:on-bind> <wb:unique-row> <wb:value id="myId1" path="myId1"/> <wb:value id="myId2" path="myId2"/> </wb:unique-row> <wb:value id="field1" path="field1"/> <wb:value id="field2" path="field2"/> </wb:on-bind> </wb:repeater>
And a fourth one is to specify values used for uniqueness independent on binding:
<wb:repeater> <wb:unique-row> <!-- here *no* binding happens! --> <wb:element ref="myId1"/> <wb:element ref="myId2"/> </wb:unique-row> <wb:on-bind> <wb:value id="myId1" path="myId1"/> <wb:value id="myId2" path="myId2"/> <wb:value id="field1" path="field1"/> <wb:value id="field2" path="field2"/> </wb:on-bind> </wb:repeater>
I used wb:element because I had no name in mind. It also must be clear if you refer to path (bean or XML) or to id (form model widget). From the XML this is very similar to Antonio's original proposal and current implementation, but there is the important difference that there does *not* happen any binding on wb:unique-row and children. Therefore it's probably clearer than the other proposals but more verbose.
WDYT?
see my question about 'suprise' above: I don't think the cost in verbosity is gained by clarity here?
I think replacing wb:unique-row with wb:identity does a far better job at adding clarity.
IMHO the behaviour of what happens on the on-bind event is more related to the 'strategy' of the repeater as discussed here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107062679414114&w=2
my proposal would be to mix-in the @strategy and have the docos introduce the clarity on what happens in 'on-bind'
wdyt?
Joerg
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
