jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: value conversions, and relative paths in Oak
Date Thu, 10 May 2012 08:43:50 GMT
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
>


Mime
View raw message