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