[
https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544734
]
Felix Meschberger commented on SLING-109:
-----------------------------------------
An alternative approach to extending the Resource interface with the new
NodeResource and ObjectResource interfaces would be "mixin" interfaces:
// mixin for objects returning nodes
public interface NodeProvider {
Node getNode();
}
// mixin for objects return (OCM or ORM) objects
public interface ObjectProvider {
Object getObject();
}
So a resource implementation returned by microsling might be defined as
public MicroSlingNodeResource implements Resource, NodeProvider {
....
}
And an implementation of the Sling jcr/resource project might be
public SlingNodeResource implements Resource, NodeProvider, ObjectProvider {
....
}
> Replace Resource.getRawData and .getObject methods by better API
> ----------------------------------------------------------------
>
> Key: SLING-109
> URL: https://issues.apache.org/jira/browse/SLING-109
> Project: Sling
> Issue Type: Improvement
> Components: API
> Reporter: Felix Meschberger
> Fix For: 2.0.0
>
>
> David brought up an issue on the dev list [1] regarding the
> Resource.getRawData() method. In short, David suggests to replace the
> getRawData method with a signature, which more closely reflects the
> definition of Sling as a web application framework for JCR. The general
> consesus on the list is that the getRawData() method is badly named and that
> we should have a method which shows the JCR integration yet does not tie the
> API too much into JCR.
> So I propose the following:
> > Remove the getRawData() and getObject() methods from the Resource
> interface
> > Add new interfaces NodeResource and ObjectResource:
> // resources backed by JCR nodes
> public interface NodeResource extends Resource {
> Node getNode();
> }
> // resources mapped using JCR OCM for example
> public interface ObjectResource extends Resource {
> Object getObject();
> }
> This way, we have the Resource interfaces completely storage-agnostic and
> provide for a wide range of extensions, such as an URLResource, which may be
> backed by a URL such as an entry in an OSGi bundle.
> [1] http://www.mail-archive.com/[email protected]/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
