You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Tomek Rękawek (JIRA)" <ji...@apache.org> on 2015/01/16 23:11:35 UTC
[jira] [Comment Edited] (SLING-4318) Sling resource API does not
expose any versioning features - bounty offered.
[ https://issues.apache.org/jira/browse/SLING-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280893#comment-14280893 ]
Tomek Rękawek edited comment on SLING-4318 at 1/16/15 10:10 PM:
----------------------------------------------------------------
Right now, Sling RESTful API provides checkin and checkout operations. Following sequence of curls will create a new version of the /content/test node:
{code}
curl -F :operation=checkout localhost:4502/content/test
curl -F property=newValue localhost:4502/content/test
curl -F :operation=checkin localhost:4502/content/test
{code}
There are also :autoCheckout and :autoCheckin parameters that allows to automatically checkout versionable nodes before modification and check them in after modification. Above curls could be rewritten as:
{code}
curl -F :autoCheckin=true -F :autoCheckout=true -F property=newValue localhost:4502/content/test
{code}
These parameters could be use implicitly if the Sling is properly configured \[1].
In the discussion \[2] Bertrand suggested creating servlets that allows to manage versions. Servlets should be bound to a pre-defined selector, like {{V}}. I think the existing checkin/checkout operations covers creating new versions pretty well. I think the most important operations that we miss are:
1. listing versions,
2. getting the base (current) version number,
3. restoring a version,
4. presenting different version of the resource (as in SLING-848).
There are also merges and activity-related operations, but they seem to be quite complicated and I'm not sure if the RESTful API is a good place for them. Please find my proposal below:
{code}
# 1+2. Listing versions & getting the base version
curl -X GET localhost:4502/content/test.V.json
# Result:
{
"jcr:rootVersion": {
"created": "Mon Sep 29 2014 12:08:56 GMT+0200",
"successors": [ "1.0" ],
"baseVersion": false
},
"1.0": {
"created": "Mon Sep 29 2014 12:08:57 GMT+0200",
"successors": [ "1.1", "1.0.0" ],
"baseVersion": false
},
"1.1": {
"created": "Mon Sep 29 2014 12:08:58 GMT+0200",
"successors": [],
"baseVersion": false
},
"1.0.0": {
"created": "Mon Sep 29 2014 12:08:59 GMT+0200",
"successors": [],
"baseVersion": true
}
}
# 3. Restoring a version
curl -X POST -F :operation=restoreVersion -F :version=1.0 localhost:4502/content/test
# Presenting different version of the resource as in SLING-848
curl -X GET localhost:4502/content/test.html;v=1.1
curl -X GET localhost:4502/content/test;v='1.1'.html
{code}
Ad. 1 - Actually, this is the only place where we use the {{V}} selector. Maybe we could replace it with {{versions}}?
Ad. 3 - I know that the parameters in the restoreVersion operation are not beautiful, but they are consistent with current Sling operations (like move, copy, delete, etc.) \[3].
I'd love to have some feedback from more experienced Sling devs.
\[1] http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#versionable-node-support
\[2] http://thread.gmane.org/gmane.comp.apache.sling.user/1610
\[3] http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#slingpostservlet-operations
was (Author: tomek.rekawek):
Right now, Sling RESTful API provides checkin and checkout operations. Following sequence of curls will create a new version of the /content/test node:
{code}
curl -F :operation=checkout localhost:4502/content/test
curl -F property=newValue localhost:4502/content/test
curl -F :operation=checkin localhost:4502/content/test
{code}
There are also :autoCheckout and :autoCheckin parameters that allows to automatically checkout versionable nodes before modification and check them in after modification. Above curls could be rewritten as:
{code}
curl -F :autoCheckin=true -F :autoCheckout=true -F property=newValue localhost:4502/content/test
{code}
These parameters could be use implicitly if the Sling is properly configured \[1].
In the discussion \[2] Bertrand suggested creating servlets that allows to manage versions. Servlets should be bound to a pre-defined selector, like {{V}}. I think the existing checkin/checkout operations covers creating new versions pretty well. I think the most important operations that we miss are:
1. listing versions,
2. getting the base (current) version number,
3. restoring a version,
4. presenting different version of the resource (as in SLING-848).
There are also merges and activity-related operations, but they seem to be quite complicated and I'm not sure if the RESTful API is a good place for them. Please find my proposal below:
{code}
# 1+2. Listing versions & getting the base version
curl -X GET localhost:4502/content/test.V.json
# Result:
{
"jcr:rootVersion": {
"created": "Mon Sep 29 2014 12:08:56 GMT+0200",
"label":
"successors": [ "1.0" ],
"baseVersion": false
},
"1.0": {
"created": "Mon Sep 29 2014 12:08:57 GMT+0200",
"successors": [ "1.1", "1.0.0" ],
"baseVersion": false
},
"1.1": {
"created": "Mon Sep 29 2014 12:08:58 GMT+0200",
"successors": [],
"baseVersion": false
},
"1.0.0": {
"created": "Mon Sep 29 2014 12:08:59 GMT+0200",
"successors": [],
"baseVersion": true
}
}
# 3. Restoring a version
curl -X POST -F :operation=restoreVersion -F :version=1.0 localhost:4502/content/test
# Presenting different version of the resource as in SLING-848
curl -X GET localhost:4502/content/test.html;v=1.1
curl -X GET localhost:4502/content/test;v='1.1'.html
{code}
Ad. 1 - Actually, this is the only place where we use the {{V}} selector. Maybe we could replace it with {{versions}}?
Ad. 3 - I know that the parameters in the restoreVersion operation are not beautiful, but they are consistent with current Sling operations (like move, copy, delete, etc.) \[3].
I'd love to have some feedback from more experienced Sling devs.
\[1] http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#versionable-node-support
\[2] http://thread.gmane.org/gmane.comp.apache.sling.user/1610
\[3] http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#slingpostservlet-operations
> Sling resource API does not expose any versioning features - bounty offered.
> ----------------------------------------------------------------------------
>
> Key: SLING-4318
> URL: https://issues.apache.org/jira/browse/SLING-4318
> Project: Sling
> Issue Type: New Feature
> Components: Documentation, JCR, Servlets
> Affects Versions: Servlets Resolver 2.3.8
> Environment: N/A
> Reporter: Bruce Edge
> Labels: api, crud, servlet-api, versioning, versions
>
> The javax.jcr.version.VersionManager is not exposed in the sling resource API:
> http://thread.gmane.org/gmane.comp.apache.sling.user/1610
> My company is interested in paying for this development. Please contact if interested.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)