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)
I see.
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.
All together we are at:
<fb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<fb:identity>
<fb:value id="myId1" path="myId1"/>
<fb:value id="myId2" path="myId2"/>
</fb:identity>
<fb:on-bind>
<fb:value id="field1" path="field1"/>
<fb:value id="field2" path="field2"/>
</fb:on-bind>
</fb:repeater>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?
I read all the threads and use cases. And yes, a unification of the different repeater bindings is desirable goal. @strategy or @type or ... is a good way to specify this explicitely.
Also the unification for binding to bean or XML is a one. This ends at the latest with the repeater at the moment as the @parent-path/@row-path is different for beans and XML.
Joerg
