On 10.5.12 9:43, Julian Reschke wrote:
On 2012-05-10 10:29, Michael Dürig wrote:
2) we didn't round-trip a relative path of ".". Now we do, but I'm not
sure I got the mapping correct. What is a same-node reference in Oak
path syntax? "." or empty string?
well, i would expect "."
Indeed.
Currently there is no notion for .. and . in Oak paths and I would leave
it at that. I.e. oak-jcr needs to take care to normalize paths before it
passes them to the Oak API. But of course we should use the
JcrPathParser to do that.
So how do you express a reference to the parent node in a path property
inside Oak Core?
My thinking was to make this opaque to oak-core. That is, set the value
of the path property to the jcr path and let oak-jcr handle it. Unless
there is a case (which might well be) where we need to dereference such
paths properties from within oak-core this should work.
I also fear that we need to be able to
round-trip relative paths like "../foo/bar" in path values, which we
currently do not. Do we need a "normalize" flag???
i would expect that we need it sooner or later.
+1
The JcrPathParser does already normalise. What it can't do is
normalising "negative" paths like ../foo or foo/../..
Yup. What I meant is that we may need a way to switch off normalizing.
Ah ok. That shouldn't be difficult.
See my other mail how that could be handled with the current setup.
Alternatively we could also have the JcrPathParser accept a prefix path
against which normalisation is done.
This might break assumptions on stability of path property values. If
the client sets a relative path it probably expects it to stay relative,
so that the path continues to work when the node is moved.
I was just talking of resolving it (under the above opaqueness
assumption). I didn't mean to save that dereferenced and normalized path
to the path property. That surely doesn't work.
Michael
3) Node.getNode(".") failed because it looked for a child called
".". If
have added a hack to make this work, but I'm wondering how to do this
properly.
imo oak paths should always be normalized except for path values.
Which means that we need to expose that in the path mapping API, right?
In the sense I described above yes.
Michael
