jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Assigned] (OAK-275) Introduce TreeLocation interface
Date Thu, 23 Aug 2012 13:22:42 GMT

     [ https://issues.apache.org/jira/browse/OAK-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Dürig reassigned OAK-275:
---------------------------------

    Assignee: Michael Dürig
    
> Introduce TreeLocation interface
> --------------------------------
>
>                 Key: OAK-275
>                 URL: https://issues.apache.org/jira/browse/OAK-275
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>
> In order to address the issues revolving around access control (i.e OAK-212, OAK-214,
OAK-218, OAK-220, OAK-226,...) I'd like to introduce a new interface {{TreeLocation}}: 
> {code}
> /**
>  * A {@code TreeLocation} denotes a location inside a tree.
>  * It can either refer to a inner node (that is a {@link org.apache.jackrabbit.oak.api.Tree})
>  * or to a leaf (that is a {@link org.apache.jackrabbit.oak.api.PropertyState}).
>  * {@code TreeLocation} instances provide methods for navigating trees. {@code TreeLocation}
>  * instances are immutable and navigating a tree always results in new {@code TreeLocation}
>  * instances. Navigation never fails. Errors are deferred until the underlying item itself
is
>  * accessed. That is, if a {@code TreeLocation} points to an item which does not exist
or
>  * is unavailable otherwise (i.e. due to access control restrictions) accessing the tree
>  * will return {@code null} at this point.
>  */
> public interface TreeLocation {
>     /**
>      * Navigate to the parent
>      * @return  a {@code TreeLocation} for the parent of this location.
>      */
>     @Nonnull
>     TreeLocation getParent();
>     /**
>      * Navigate to a child
>      * @param name  name of the child
>      * @return  a {@code TreeLocation} for a child with the given {@code name}.
>      */
>     @Nonnull
>     TreeLocation getChild(String name);
>     /**
>      * Get the underlying {@link org.apache.jackrabbit.oak.api.Tree} for this {@code
TreeLocation}.
>      * @return  underlying {@code Tree} instance or {@code null} if not available.
>      */
>     @CheckForNull
>     Tree getTree();
>     /**
>      * Get the underlying {@link org.apache.jackrabbit.oak.api.PropertyState} for this
{@code TreeLocation}.
>      * @return  underlying {@code PropertyState} instance or {@code null} if not available.
>      */
>     @CheckForNull
>     PropertyState getProperty();
> }
> {code}
> Such an interface would decouple navigation from the tree itself while at the same time
unifying node and property access. This allows us to enforce access control restriction on
the tree itself while still being able to access items which we are "unlinked" by access control
restrictions. In addition unification of node and property access will simplify the code in
many places. Finally {{TreeLocations}} might better encapsulate the resolution of a location
in a tree to the actual tree. This is something which currently done in {{Node/PropertyDelegate.resolve}}
but always bothered me as too ad-hoc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message