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 14:45:18 GMT


Joerg Heinicke wrote:

> On 11.03.2004 17:31, Marc Portier wrote:
> 
>>> 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
> 
> 
> So, I implemented this myself. To be honest, I'm proud of this work. Not 

this is utter good news

> only that I got it working, I also had the feeling I know what I'm doing 

even better :-)

> :) Ok, it took a while to understand all the things in the code, but now 
> it works. I tested it with the form2 binding samples.
> 
> Some issues:
> 1. I removed the old attributes and convertor. I will also add this to 
> the woody2cforms upgrade task. Obviously this must by solved by a 
> stylesheet.

I missed the reason to do away with the convertor, or you moved it down 
to the identity-binding?

> 2. The repeater binding has to know stuff (fieldId, xpath, convertor, 
> etc.) from its child bindings - and this dependency is bad. With the 

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

> both attributes all details where known to the repeater binding builder 
> (therefore it implemented the functionality of a second builder) and so 
> to the repeater binding. 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

> This issue goes on: I expect value bindings as child bindings, nothing 
> else (would result in ClassCastException at the moment). I could imagine 
> the use of other bindings here too: the simplest is the context binding, 
> which seems to be absolutely valid, but not working, because there is no 
> chance to get the values from a value binding which is a child of a 
> context binding which is a child of the identity binding. The extreme 
> would be a repeater binding: imagine a list of persons that have a list 
> of biometrical data that constitute the identity of those persons.
> 
> 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?

>>> 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
> 
> 
> That would be interesting. I guess while reading I lost at least half of 
> the stuff ...
> 
>>> 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':
> 
> 
> Yes, I know and fear this.
> 
>> 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)
> 
> 
> 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

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 :-)

>> 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'.
> 
> 
> 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'?

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

regards,
-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