[
https://issues.apache.org/jira/browse/SLING-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280893#comment-14280893
]
Tomek Rękawek commented on SLING-4318:
--------------------------------------
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)
