cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [CForms] Support for multipe unique-row-id in Repeater
Date Fri, 12 Mar 2004 17:29:39 GMT


Joerg Heinicke wrote:

> Marc Portier <mpo <at> outerthought.org> writes:
> 
> 
>>I missed the reason to do away with the convertor, or you moved it down 
>>to the identity-binding?
> 
> 
> The convertor was only for @unique-row-id and @unique-path and as I removed
> these I also removed that. The identity binding itself is just a composed
> binding. The value bindings do have a convertor themselves.
> 
> 

sure, I didn't rehash my mail after starting to see the light, ignore this

>>>2. The repeater binding has to know stuff (fieldId, xpath, convertor, 
>>>etc.) from its child bindings - and this dependency is bad.
>>
>>IIRC we just duplicated that info during building in order to make sure 
>>there would not be added coupling between the repeater and it's possible 
>>children
> 
> 

and you might as well ignore this

> Maybe I understand something wrong, but I don't agree with your recall:
> The handling of @unique-row-id and @unique-path was completely in
> RepeaterJXPathBindingBuilder [1] and RepeaterJXPathBinding [2]. So the repeater
> binding did also the work of the ValueJXPathBindingBuilder and so knew all
> values for latter usage. Nothing was duplicated AFAICS.
> 

IIRC, the duplication wqas in the fact that the repeater-binding had its 
own memory of the unique-row-id and unique-path PLUS is had a reference 
to a distinct value-binding that was initialised with the same values

but again: not relevant now that there is 'identity' for composed keys

> 
>>>This is no longer true for the elements. I can 
>>>get the child bindings from the composed binding, but I had to open 
>>>(additional getters) the value binding to get the values no longer 
>>>available to the repeater binding otherwise.
>>
>>afraid I don't understand completely yet
> 
> 
> 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...

> 
>>>All together: there is now a dependency of the repeater binding on its 
>>>child bindings. We can restrict the allowed child elements of 
>>>fb:identity to fb:value that reduces the problem to current minimum, but 
>>>maybe something else is needed.
>>
>>oh, I'm starting to see the light again...
>>
>>damn, I have to check in the maillinglist to see if this was just a 
>>personal mental note or a discussed proposal, but in any case:
>>
>>IMHO this calls for an additional method on the binding interface, next 
>>to load() and save() we should be able to ask for isMatch() or even 
>>better isIdentical()
>>
>>wdyt?
> 
> 
> 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?

> 
>>>>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)
>>>
>>>When it would work "regardless of the backend" ...
>>
>>yeah, but currently the regardless only realtes to the syntax being 
>>portable over to the backend, not the semantics
> 
> 
> An important difference indeed :)
> 
> 
>>or in other words: the semantics are imposed onto the backend by jxpath
>>
>>what I want to say is: it DOES work, but only if the backends are equal 
>>in the jxpath sense of the word 
> 
> 
> 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... )

> 
>>>While developing we often encoupled the backend from the frontend. The 
>>>interface between both was a simple XML structure. The frontend knows 
>>>what it will get, the backend what it has to deliver when the system is 
>>>running. This allows independent development. Additionally we had static 
>>>test XML files for the frontend, so that "real life" test is possible. 
>>>The switching was just in the sitemap (XML from disk or from backend). 
>>>Now I would have to maintain two binding files.
>>
>>hm, all falls with the line
>>'backend knows what it has to deliver'
>>
>>is that *knowing* really according to 'semantics as imposed by jxpath' 
>>and not according to 'most naive/simplistic view of the structure'?
> 
> 
> It was with Cocoon 2.0 (no JXPath, no beans, no woody) and just an arbitrary
> complex XML comming either from disk (static file) or XSP (the backend), but
> this XML structure was the interface.
> 
> 
>>I could go on questioning if the static XML is a big gain over a static 
>>hard-coded Java that builds some bean instances rather then load them 
>>from the real backend...
> 
> 
> Indeed, new techniques sometimes need adapted developing.
> 
> 
>>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.

> Thanks for your reply,
> 

no, thank YOU for your coding effort!

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message