[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672259#action_12672259
]
Carsten Ziegeler commented on SLING-848:
----------------------------------------
Ok, as I really would like to get this feature implemented let's recap:
- the uri parameter is a good way of expressing the requested version
- we only allow one version to be specified, so the uri parameter can only be
added once
- the uri parameter should be added to the end of the resource path but before
selectors and extensions to make it simple to generate urls (like
resource.getPath() + ".html")
- the above shows that resource.getPath() should include the version
information (if available)
This all leads us to urls, like
/content/somewhere/over/the/rainbow[versionInfo][.selectorstring][.extension]
As the version information can contain dots, a url like
/mycontent;v=1.0.a.b.c.html is not easy to pass as the passing algorithm can't
decide where the version information ends and where the selectors start.
Escaping the dot is an ugly (and I think forbidden) solution, so we should just
add the version information in quotes:
/mycontent;v='1.0.a'.b.c.html
The sling resource resolver will extract uri parameters from the uri and pass
them to the resource providers in an additional parameter. Currently the
resource providers just get a path; we will extend this to be a path and a map
of all uri parameters.
The map of uri parameters will later on also end up in the resource meta data.
Does this make sense?
> Support getting versioned resources by using uri path parameters
> ----------------------------------------------------------------
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: JCR Resource
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
