cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] Repeater Binding Revisited.
Date Tue, 30 Mar 2004 21:13:23 GMT

Antonio Gallardo wrote:

> Joerg Heinicke dijo:

<snip />

> I am not sure if here my DB oriented mind is strongly playing with me. But
> I really see the connection between both models. Maybe I am wrong, but I
> strongly believe it will be obvios in the future when people will get more
> in touch with JXPath.
> It is just an optional way to "save" typing". We can define it as:
> The default value of @path is @id is @path is not defined.

I'm quite -0 but if more people like this it's easy enough
actually while reading up your other comments I have to conclude that 
the only value that would be a meaningful default value for @path is "."

<snip />

>>>Don't know the current RepeaterBinding do that! It distribute the result
>>>on 3 diferent sets? It would be useful in some cases.
>>See the links including the line numbers above.
> I tought about the behavior for the user. Not about the internal
> implementation. Interesting for user is what get back and not how it
> compute the return value.

nope, all of that is internal processing

<snip />

> After 4 hours dreaming.... Here is the proposal:
> 1- repeater/@parent-path -> deprecated, use <fb:context> instead.
> =================================================================
> The fact is while you wrote repeaters you will see you writing
> parent-path="." over and over with no change. Then you start thinking why

hm, I do think this is a consequence of binding to beans, no?

when binding to xml one often has a groupinbg-element
   <item id="" />
   <item id="" />

for this use case the 'always need to wrap in a fb:context ends up being 
more typing!

it would be more useful, to e.g. let the parent-path default to '.' IMHO

but of course that collides with your other proposal: @path defaulting 
to @id :-)

but we are very close, you know: when we change @parent-path to @path we 
are actually saying: pull in the fb:context@path into this element right 

> it is so important? I already wrote it more than 100 times in diferent
> forms of a variety of complexity.
> 2-repeater/@row-path --> repeater/@path
> =======================================
> We know the binding is a map between 2 models: The Widget Object Model
> (WOM) and the Businnes Object Model (BOM). But in fact, both models are
> often very similar.
> <fb:value id="field1" path="field1">
> <fb:repeater id="list" row-path="list">
> Is not clear the analogy?

euh, no :-)

> =======
> Given a bean defined as:
> Bean b {
>   int field1;
>   int field2;
>   List list;  // This is a repeater it contains other Beans of type BO.
> }
> Based on the JXPath theory, the Bean is easily mapped to XML as:
> <b>
>   <field1/>
>   <field2/>
>   <list>
>     <BO>
>     <BO>
>     ...
>   </list>
> </b>

sorry, but in jxpath speak these two are NOT equivalent

first item in the bean's list: ./list[1]
first item in the xml list: /b/list/bo[1]

the correct XML mapping would have been something odd like:


I know this is counter-intuitive to how you transpose bean modeling to 
xml modelling, but jxpath is not about modelling it is about 

in any case we recently had that observation on the list already, as I 
argued back then, intuition is not always giving good advise:
"Will the melon fall faster then the apple?"

> Then the current binding is:
> <fb:context path="/">   <!-- This is the path for the bean -->
>   <!-- Here we are at the Bean context -->
>   <fb:value id="field1" path="field1">
>   <fb:value id="field2" path="field2">
>   <fb:repeater id="repeaterId" parent-path="." row-path="collection">
where you mean collection should have been 'list', right?

>    <!-- Here we are at the repeater context -->

and sorry, but this comment should read: here we are at the row vs. item 
context, meaning that nested bindings will talk about the properties of 
the BO type

>   ...
>   </fb:repeater>
> </fb:context>

for the XML you provided the binding would have needed to look like this:

  <fb:context path="/b">   <!-- This is the path for the ROOT_NODE -->
    <!-- Here we are at the ROOT_NODE context -->
    <fb:value id="field1" path="field1">
    <fb:value id="field2" path="field2">
    <fb:repeater id="repeaterId" parent-path="list" row-path="bo">
     <!-- Here we are at the row-vs-item context,
          meaning we are looking at mappings to the nested elements
          of the BO element -->


> In fact the path of the repeater's rows is not in @parent-path context. In
> most cases the @parent-path context is the Bean context. Here the question
> is: Why define a @parent-path for <fb:repeaters> and not for <fb:values>?

for the classic XML case, where <item> elements get wrapped in a parent 

> It is not enough given the already given <fb:context>? (See the first line
> of defined binding).

see above, I think you have a focus on bean binding

> Note: we already have a context "/" (<fb:context> and if we add the
> @parent-path to the current XPath context we got again: "/".
> It is not the same?
> If we need to change the current context path, then use the specific
> instruction to do that: <fb:context>.
> In that way @parent-path of repeaters can be deprecated.
> And given the fact that we are at already at Bean context while declaring
> the repeater => it is why is enough a "." value.
> -------------------------------------------------------------------------
> The @row-path define the path where each item of the repeater resides.

actually: where each 'item' of the 'contextbean' resides
(see my original drawing where I propose to see a repeater as a list of 
rows mapping to a collection of items, just to get some nomenclature 
installed so we talk about the same things here)

> This is the same as for <fb:value> And here is where I see the analogy to
> the @path attribute in <fb:value> and not in the above case. Note, in the
> case of <fb:value> we don't have a @parent-path. If we have one then we
> will to write:
> <fb:value id="value1" parent-path="." item-path="value1"/>
> Hope it explain my POV.

and I hope you can now look at it from the angle brought in by XML backends

> Best Regards,
> Antonio Gallardo

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message