cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
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
<items>
   <item id="" />
   <item id="" />
</items>

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 
away

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

> SAMPLE:
> =======
> 
> 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:

    <field1/>
    <field2/>
    <list>
    <list>
    <list>
    <list>
    <list>
    <list>

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

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

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



> 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 
<items>

> 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=
-- 
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