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:[EMAIL PROTECTED] 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:where you mean collection should have been 'list', right?
<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">
<!-- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
