You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2007/11/22 10:09:43 UTC
[jira] Created: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544736 ]
Bertrand Delacretaz commented on SLING-109:
-------------------------------------------
I like the mixin idea, and it might also be useful to have a StreamProvider which returns an InputStream
> 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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-109.
-----------------------------------
Resolution: Fixed
Adapted now microsling and Sling to the new adapter model, which seems to be accepted.
Therefore closing this issue.
> 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
> Assignee: 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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547813 ]
Felix Meschberger commented on SLING-109:
-----------------------------------------
Modified the Sling API project as well as the scripting/javascript and the microsling project.
> 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
> Assignee: 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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546690 ]
Felix Meschberger commented on SLING-109:
-----------------------------------------
Implemented this enhancement to the API in Rev. 599405 :
- getInputStream, getObject and getRawData removed from the Resource interface
- Added NodeProvider, ObjectProvider, URLProvider and StreamProvider interfaces
> 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
> Assignee: 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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger reassigned SLING-109:
---------------------------------------
Assignee: Felix Meschberger
> 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
> Assignee: 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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546720 ]
Felix Meschberger commented on SLING-109:
-----------------------------------------
Adapted microsling to the modified API. All the tests pass, so I assume this migration succeeded.
> 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
> Assignee: 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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544735 ]
Felix Meschberger commented on SLING-109:
-----------------------------------------
Whichever approach is implemented, we define microsling to always return a Resource implementation, which also implements the appropriate interface to access the JCR node.
> 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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-109) Replace Resource.getRawData and
.getObject methods by better API
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547792 ]
Felix Meschberger commented on SLING-109:
-----------------------------------------
After some more discussion on the list (see link in the initial comment) highlighting sortcomings this interface extension model such as missing extensibility and keeping a single point reference to the JCR API in the new NodeProvider interface, we seem to settle on a further possibility: Define a new adapter method in the Resource interface:
<AdapterType> AdapterType adaptTo(Class<AdapterType> adapterType);
This method returns the resource adapted to another type. This allows the implementation to dynamically support adapters upon support. For example the microsling JcrNodeResource might implement the method as follows (simplified, ignoring exceptions) :
<AdapterType> AdapterType adaptTo(Class<AdapterType> adapterType) {
if (adapterType == Node.class) {
return (AdapterType) node;
} else if (adapterType == InputStream.class) {
return (AdapterType) getInputStream();
}
return null;
}
The Sling JcrNodeResoure supporting URLs and object mapping might be :
<AdapterType> AdapterType adaptTo(Class<AdapterType> adapterType) {
if (adapterType == Node.class) {
return (AdapterType) node;
} else if (adapterType == InputStream.class) {
return (AdapterType) getInputStream();
} else if (adapterType == URL.class) {
return (AdapterType) getURL();
} else if (adapterType == Object.class || adapterType.isInstance(getObject())) {
return (AdapterType) getObject();
}
return null;
}
> 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
> Assignee: 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/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.