Path handling in Oak

[Michael Dürig <md...@apache.org>]

Hi,

There is some discussion around how (relative) paths should be handled 
within Oak [1, 2, 3].

Initially (well, way back) there was a clear definition what an oak path 
(in contrast to a JCR path) is. That definition got somewhat 
lost/blurred along the way.

Currently an oak path as returned by PathMapper.getOakPath() is a string 
consisting of elements separated by a forward slashes. Elements are 
names or the special element parent (..). The parent element never 
occurs after a name element (that is, parent elements only occur at the 
beginning of an oak path. An oak path starting with a forward slash is 
an absolute path. All other paths are relative. Only relative oak paths 
may contain parent elements.

Semantically an absolute oak path refers to an item in a tree such that
- / refers to the root of the tree,
- <absolute-oak-path>/name refers to the child "name" of the node 
referred to by <absolute-oak-path>,

and a relative oak path refers to an item in a tree such that for any item i
- "" refers to i,
- <relative-oak-path>/name refers to the child "name" of the node 
referred to by <relative-oak-path>,
- <relative-oak-path>/.. refers to the parent of the node referred to by 
<relative-oak-path>.

As I mentioned in OAK-426 I think it is unnecessary and even wrong to 
push handling of special path elements down to oak-core since this would 
mix the concerns of interpreting names with tree navigation and access. 
It further breaks modularisation since this would tear plugin 
functionality into core. Interpretation of paths and names should stay 
entirely in oak-jcr and the respective plugins.

However, this currently leads to some amount of duplicate code in 
oak-jcr (LocationUtil, NodeUtil.getOrAddTree, 
NodeDelegate.getChildLocation). To factor this out I see two possibilities:

1. Consolidate the three different implementations into one factoring 
out the commonalities and simplify by levering the properties of above 
path definition.

2. Pass the functionality down to TreeImpl.getChild() through a new 
parameter of type NameResolver:

interface NameResolver {
   TreeLocation resolve(String name, TreeLocation location);
}

With the first approach client code would have to go through a utility 
class explicitly. With the second approach clients would be forced to 
used the utility through having to pass it to TreeLocation.getChild(). 
The second approach could also be made working on JCR paths directly by 
implementing a JCR version of above NameResolver.

Michael


[1] http://markmail.org/message/66q4nf2aj4b424z3
[2] https://issues.apache.org/jira/browse/OAK-426
[3] https://issues.apache.org/jira/browse/OAK-369

Re: Path handling in Oak

[Angela Schreiber <an...@adobe.com>]

hi michael

thanks for the summary.

i don't agree with your statement that it was "unnecessary and even 
wrong" to delegate handling of the special elements current (".") and 
parent ("..") in the OAK API and fail to see any benefit of allowing
child nodes with such names on that level.

so, it seems we can't reach consensus here :-)

from the 2 possibilities outlined below i somehow prefer the second one
as it seems less error prone (people will forget to use the utility).

kind regards
angela

On 11/21/12 11:59 AM, Michael Dürig wrote:
>
> Hi,
>
> There is some discussion around how (relative) paths should be handled
> within Oak [1, 2, 3].
>
> Initially (well, way back) there was a clear definition what an oak path
> (in contrast to a JCR path) is. That definition got somewhat
> lost/blurred along the way.
>
> Currently an oak path as returned by PathMapper.getOakPath() is a string
> consisting of elements separated by a forward slashes. Elements are
> names or the special element parent (..). The parent element never
> occurs after a name element (that is, parent elements only occur at the
> beginning of an oak path. An oak path starting with a forward slash is
> an absolute path. All other paths are relative. Only relative oak paths
> may contain parent elements.
>
> Semantically an absolute oak path refers to an item in a tree such that
> - / refers to the root of the tree,
> -<absolute-oak-path>/name refers to the child "name" of the node
> referred to by<absolute-oak-path>,
>
> and a relative oak path refers to an item in a tree such that for any item i
> - "" refers to i,
> -<relative-oak-path>/name refers to the child "name" of the node
> referred to by<relative-oak-path>,
> -<relative-oak-path>/.. refers to the parent of the node referred to by
> <relative-oak-path>.
>
> As I mentioned in OAK-426 I think it is unnecessary and even wrong to
> push handling of special path elements down to oak-core since this would
> mix the concerns of interpreting names with tree navigation and access.
> It further breaks modularisation since this would tear plugin
> functionality into core. Interpretation of paths and names should stay
> entirely in oak-jcr and the respective plugins.
>
> However, this currently leads to some amount of duplicate code in
> oak-jcr (LocationUtil, NodeUtil.getOrAddTree,
> NodeDelegate.getChildLocation). To factor this out I see two possibilities:
>
> 1. Consolidate the three different implementations into one factoring
> out the commonalities and simplify by levering the properties of above
> path definition.
>
> 2. Pass the functionality down to TreeImpl.getChild() through a new
> parameter of type NameResolver:
>
> interface NameResolver {
>     TreeLocation resolve(String name, TreeLocation location);
> }
>
> With the first approach client code would have to go through a utility
> class explicitly. With the second approach clients would be forced to
> used the utility through having to pass it to TreeLocation.getChild().
> The second approach could also be made working on JCR paths directly by
> implementing a JCR version of above NameResolver.
>
> Michael
>
>
> [1] http://markmail.org/message/66q4nf2aj4b424z3
> [2] https://issues.apache.org/jira/browse/OAK-426
> [3] https://issues.apache.org/jira/browse/OAK-369