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.
Joerg
