jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Path handling in Oak
Date Tue, 27 Nov 2012 15:21:55 GMT
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

Mime
View raw message