Joerg Heinicke wrote:
On 05.03.2004 17:45, Marc Portier wrote:
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>
yep, sounds like the best we have ATM
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
pfew, you are a brave man :-)
I need some time to list all changes, proposals, enhancements that were partially discussed but haven't got into code yet
different repeater bindings is desirable goal. @strategy or @type or ... is a good way to specify this explicitely.
yeah that is the approach that is gaining popularity in my head as well, thx for confirming
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.
hm, I've experienced this myself now and then, but I'm afraid this is out of our league, jxpath imposes an XML way of looking at your java-bean that is sometimes 'surprising':
what most naturally looks like the standard java version of an xml snippet seems (often due to technical limitations that however logic need some thought to grasp) to be behaving different in the jxpath view
next to this observation however I'ld like to question the real-life relevance: IMHO the advantage of jxpath under the hood of the binding is that it allows for reusing the syntax-metafor of xpath regardless of the backend. Being the mix of using slashes over dots, not needing parentheses and having a single expression that equally works for getting and setting (LHV/RHV)
I don't see it as a common use case that people during the lifetime would want to switch the backend from XML to JavaBeans (or vice versa) and actually expect to have all binding expressions work 'justlikethat'.
(as such I think this mismatch-experience is mainly something that will overcome us developers, sample-makers, functional testers...)
but all IMHO, so wdot? -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]
