cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [CForms] Support for multipe unique-row-id in Repeater
Date Thu, 11 Mar 2004 16:31:35 GMT

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:
>> 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 Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message