cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [CForms] Support for multipe unique-row-id in Repeater
Date Wed, 17 Mar 2004 09:23:48 GMT
On 12.03.2004 18:29, Marc Portier wrote:

>> You don't have access to the field and its value of the child binding by
>> default. For the repeater you now need the values, otherwise you can 
>> not build the identity of a row.
> yep, you only have a ref to a binding (in the abstract sense) that is 
> there for all of the identity fields
> hence my proposal: in stead of asking it for internal details it should 
> just be able to reply to some isIdentical(formContext, modelContext) 
> question...
>> But fb:identity is a composed binding that would need to collect the 
>> values of its child bindings (fb:value or others, there is also no 
>> access to those ATM).
> just like the load() and save() of this composite binding delegates to 
> it's children, it would need to do so for the isIdentical()
> do {
>   stillIdentical &&= nextChildBinding.isIdentical()
> }
> while(stillIdentical and hasmoreChildBindings)
> return stillIdentical;
> by the introduction of the 'identity' as a potential complex binding we 
> have now a third mode of operation of the abstract binding interface:
> 1/ load
> 2/ save
> 3/ check for identity (or equivalence, or valuematch, or whatever name 
> we find most appropriate)
> this change would mean that each of the bindings would need to implement 
> this mode of operation in order for them to be used as an 'identity' 
> inside the repeater.
> for most of them I think it's pretty straightforward, for those we can't 
> figure out yet how it should work we could throw a runtime exception 
> which would mean that this type of binding can not be used as an 
> identity mapping...
> this in combination with the builder, checking it at runtime would be 
> great...
> hm, this actually calls for a separate interface: IdentityBindingSupport 
> that holds the isIdentical() method... that is even nicer, right? If we 
> don't know how to support it, then we just don't implement the interface
> the builder then just waits for the identity-binding to be built and 
> checks for an instanceof, downcasts, and hands over to the constructor 
> of the actual repeater (or generates a building-error)
> making sense?

Yes, indeed. If there is nobody faster than me I will also try to get 
this implemented myself. I will see if I will came across other problems.

>> Yes, I put the blame on jxpath.
> I'ld like to give those blokes a break, like said earlier in those cases 
> I encountered I'ld have to confess (after giving it appropriate thought) 
> that they just did a very logical thing... it just doesn't manifest 
> itself as logical thing at first...
> Will the melon fall faster then the apple?
> (This makes me remember the toy-shop in London where they had the 
> hourglas inside the tube that was waiting a bit first and then going up 
> in stead of down when you turned it... all logic, but still surprising. 
>  Some things are just like that I'm afraid... )


>>> however, thinking about it constructively I think here and now the 
>>> best we can do is build some docos/catalogue offering the real 
>>> XML/jxpath view on some classic bean constructs?
>> Yes, though it would belong more to JXPath itself and should be 
>> maintained there. Maybe it already exists.
> maybe, then we could just provide a link.

Ok, I will have a look for that page.


View raw message