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 "."
Got the same feeling when reading Antonio's mail.
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?
Indeed, at the end we stand again infront of different behaviours for XML and beans in JXPath.
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
IMO it's obvious that the current use of @path and partly @parent-path is the same as an additional fb:context. So if it were possible to not specify those attributes we would not change any context. And this means there values default to ".".
IMO this proposal is very comprehensible, no "to much typing" and weirdness to find.
Joerg
