You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2009/02/03 10:35:59 UTC
[jira] Created: (SLING-848) Support getting versioned resources by
using uri path parameters
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 Install
Affects Versions: JCR Resource 2.0.2
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
Fix For: JCR Resource 2.0.4
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.
[jira] Issue Comment Edited: (SLING-848) Support getting versioned
resources by using uri path parameters
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670266#action_12670266 ]
fmeschbe edited comment on SLING-848 at 2/3/09 11:25 PM:
------------------------------------------------------------------
Yes, according to rfc3986
/content/home;v=1.0/tobi;v=1.5
would be perfectly valid. But we won't support it, since this leads into areas which are too complicated to grasp and which can almost not be described. For this reason, we define, that the ;v= URI parameter is only recognized and used on the last segment.
Now, for the location of the ;v= specification. The intened location is of course to be at the end, as in
/content/home/tobi.html;v=1.5
If we would have Resource.getPath() include the ;v= we would of course also have to support things like
/content/home/tobi;v=1.5.selector.html
You are right, that this is neither nice nore very logic, though not necessairily violating the spec.
Maybe we should think about this some more.
was (Author: fmeschbe):
Yes, according to rfc3986
/content/home;v=1.0/tobi;v=1.5
would be perfectly valid. But we won't support it, since this leads into areas which are too complicated to grasp and which can almost not be described. For this reason, we define, that the ;v= URI parameter is only recognized and used on the last segment.
Now, for the location of the ;v= specification. The intened location is of course to be at the end, as in
/content/home/tobi.html;v=1.5
If we would have Resource.getPath() include the ;v= we would of course also have to support things like
/content/home/tobi;v=1.5.selector.html
You are right, that this is neither nice nore very logic, though not necessairily violating the spec.
Maybe we should think about this some more.
> btw: i think the "component" of this issue is wrong.
Probably yes, but this is the only component available currently for treating ResourceResolver issues. We should probably create another one -- also in light of the proposed extension of the ResourceResolver infrastructure.
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Andreas Hartmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670713#action_12670713 ]
Andreas Hartmann commented on SLING-848:
----------------------------------------
@Tobias:
> i'd rather see a "global" query parameter or cookie that controls the version selection.
you mean that the version selection would apply to the whole repository (from the point of view of the user session)? IMO this would be a major restriction; the use case "View revision x of a document" is provided by virtually all CMS/DMS applications, and the URI path parameter would make it very easy to implement this use case.
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672286#action_12672286 ]
Tobias Bocanegra commented on SLING-848:
----------------------------------------
> Resource.adaptTo(Version.class): This would be Resource.adaptTo(Node.class).getBaseVersion(), right ?
no, the node addressed by the versioned path is the jcr:frozenNode of the version. so actually it would be:
Resource.adaptTo(Node.class).getParent()
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669957#action_12669957 ]
Carsten Ziegeler commented on SLING-848:
----------------------------------------
No, I don't want to change the existing API: the idea is to provide an utility method which can be used by all resource provider implementations.
And change the jcr implementation to support this version handling.
> 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 Install
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> 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.
[jira] Updated: (SLING-848) Support getting versioned resources by
using uri path parameters
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler updated SLING-848:
-----------------------------------
Component/s: (was: JCR Install)
JCR Resource
Fix Version/s: (was: JCR Resource 2.0.4)
Assignee: (was: Carsten Ziegeler)
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670266#action_12670266 ]
Felix Meschberger commented on SLING-848:
-----------------------------------------
Yes, according to rfc3986
/content/home;v=1.0/tobi;v=1.5
would be perfectly valid. But we won't support it, since this leads into areas which are too complicated to grasp and which can almost not be described. For this reason, we define, that the ;v= URI parameter is only recognized and used on the last segment.
Now, for the location of the ;v= specification. The intened location is of course to be at the end, as in
/content/home/tobi.html;v=1.5
If we would have Resource.getPath() include the ;v= we would of course also have to support things like
/content/home/tobi;v=1.5.selector.html
You are right, that this is neither nice nore very logic, though not necessairily violating the spec.
Maybe we should think about this some more.
> btw: i think the "component" of this issue is wrong.
Probably yes, but this is the only component available currently for treating ResourceResolver issues. We should probably create another one -- also in light of the proposed extension of the ResourceResolver infrastructure.
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672282#action_12672282 ]
Felix Meschberger commented on SLING-848:
-----------------------------------------
VersionedResource: I dont think we need that. What we might want to have, though is a new ResourceMetadata property which provides the URI parameters. This may be a map with all the URI parameters.
Resource.getName(): We have ResousourceUtil.getName(Resource) which is supposed to return the name of the resource. This must of course be extended to "cut off" the URI parameter from the path, too. Whether we really need a Resource.getName() method is not related to this issue -- it might make sense from a usability POV
Resource.adaptTo(Version.class): This would be Resource.adaptTo(Node.class).getBaseVersion(), right ?
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670722#action_12670722 ]
Carsten Ziegeler commented on SLING-848:
----------------------------------------
I don't think that the semicolon is really a problem in most browsers as the java session id is appended to the url in this way for years. If browsers have
problems with this (as Marc reported) then it's most likely that a lot of web sites are not working in these browsers today, so I guess sooner or later
these problems will be fixed or the users switch to other browsers. :)
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670273#action_12670273 ]
Bertrand Delacretaz commented on SLING-848:
-------------------------------------------
I think
/content/home/tobi.html;v=1.5
breaks existing logic, as IMHO programmers assume that things that affect the representation come at the end of the URL.
I much prefer
/content/home/tobi;v=1.5.selector.html
Where the URI parameters (which affect the selected content) come first, and the selectors and extensions (which affect the representation) last.
Also, why not change the API? If we start supporting URI parameters as specified, the least surprising way would be to add a (backwards-compatible) getURIParameters method to the SlingHttpServletRequest interface. Hacking the content path downstream feels wrong.
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Andreas Hartmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669986#action_12669986 ]
Andreas Hartmann commented on SLING-848:
----------------------------------------
A problem with predefined parameter names is that they restrict the available space for application parameter names. In Lenya, we prefix all framework-level request parameters with "lenya.", e.g. for revisions we use lenya.revision=xyz. I'm not sure if this also applies to URI path parameters, though.
> 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 Install
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670026#action_12670026 ]
Carsten Ziegeler commented on SLING-848:
----------------------------------------
@Andreas: I don't think that we have to prefix the uri path parameters. The parameter is used to get the corresponding representation of the resource and I think it's unlikely that someone else is using the same at the same time.
@Tobias: The check is added to the jcr resource provider which provides the resource for a given path (being it the path from the http request or a path passed in to the resource resolver). So we can handle this transparently in the resource provider. Noone else is affected by this.
> 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 Install
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669953#action_12669953 ]
Tobias Bocanegra commented on SLING-848:
----------------------------------------
you mean: something/hello.html;v=1.1 ?
this will set a resource resolver option v=1.1 ?
so in general, the resource resolver should have a new method:
getResource(String path, Sring versionName)
or should there be a 'VersionSelector' interface, that is resposible to select the proper version for a requested path?
> 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 Install
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670136#action_12670136 ]
Tobias Bocanegra commented on SLING-848:
----------------------------------------
so consequently (according to rfc3986) , the v= parameter should be applicable to each segment. eg:
/content/home;v=1.0/tobi;v=1.5
(assuming /content/home/tobi is currently deleted and did only exist in the version 1.0 of the 'home')
what is the "external" form of this?, probably:
/content/home;v=1.0/tobi.html;v=1.5
having the .html at the end makes no sense.
but this makes each script logic that just appends the .html to the resource path pretty useless.
the problem you have is:
- if you include the v= to the resource.getPath() the resource gets unusable for "normal" scripts,
- if you omit it from the path, the getResource() / getPath() is not symmetric
so maybe this is not such a good idea after all?
btw: i think the "component" of this issue is wrong.
> 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 Install
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670717#action_12670717 ]
Bertrand Delacretaz commented on SLING-848:
-------------------------------------------
> i'd rather see a "global" query parameter or cookie that controls the version selection.
Aaargh no! Calling the REST gods to the rescue ;-)
If the semicolon is a problem in URLs (damn browsers), why not one of the following:
content/home/tobi=v=1.5.selector.html
content/home/tobi/sling:v1.5.selector.html
content/home/tobi.selector.html?sling:v=1.5
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Marc (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670281#action_12670281 ]
Marc commented on SLING-848:
----------------------------
Supporting versions is a great feature. Just for the record of future bug hunters: Mac OS 10.4 + HTTP Basic Authentication cannot handle these links [1]. BTW this was also one of the reasons Rails dropped using ; in URLs [2]. One of the other reasons was caching but I'm not sure if this still applies.
[1] https://bugs.webkit.org/show_bug.cgi?id=10073
[2] http://dev.rubyonrails.org/changeset/6485
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672270#action_12672270 ]
Tobias Bocanegra commented on SLING-848:
----------------------------------------
i'm still not convinced that this does not lead to severe inconsistencies in the way resources are used.
to achieve better stability, i also suggest to
* mark those resources clearly with an own interface, eg: VersionedResource
* add Resource.getName() which returns the last segment of the path, without any parameter
* versioned resource should be adaptable to javax.jcr.Version (although this is NOT the actual resource, i.e. frozen node)
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670035#action_12670035 ]
Felix Meschberger commented on SLING-848:
-----------------------------------------
The point of using the URI parameter notation is based on a discussion I once had with Roy Fielding about encoding the version of a JCR node in an URL. He pointed me to this feature, which is also described in Section 3.3, Path, of RFC 3986 [1].
I think, this functionality is as simple as it is flexible.
We also chose this option because we explicitly did not want to extend the API at this point in time.
One thing, we might well consider in the future, is that we might add some thing like a VersionSelector to the ResourceResolver, which is used by the ResourceProviders to further select versions.
One thing to not forget about is, that this ;v= functionality is not only supported for ResourceResolver.resolve but also for ResourceResolver.getResource. Consquently, the ResourceResolver.map should generate URI strings, which also contain the ;v= URI parameters in case the resource is based on a certain version (of a Node or similar).
Maybe the Resource.getPath() should also include the ;v= parameter since it is transparently supported by the ResourceResolver and its ResourceProviders.
Finally, the ResourceMetadata map should probably also contain the an entry with key "v" and the respective value.
[1] http://www.faqs.org/rfcs/rfc3986.html
> 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 Install
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672263#action_12672263 ]
Felix Meschberger commented on SLING-848:
-----------------------------------------
+1 with enhancements:
The URI parameter parser should also recognize this: /a/path.selector.html;v=5.0 (version at the end with or without quotes)
and the ResourceResolver.map(String) method might want to convert something like
/a/patch;v='5.0'.sel.html
to
/a/patch.sel.html;v=5.0
for nicer optics.
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670288#action_12670288 ]
Tobias Bocanegra commented on SLING-848:
----------------------------------------
that's was i feared. using the ; parameters is not widely used, and causes problems, as marc pointed out.
i think it's ok to use the parameters for the resource resolver - but then you can also extend the api. i would avoid using them on the URI from the request, especially, because the generation of such links is a bit special. i'd rather see a "global" query parameter or cookie that controls the version selection.
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669988#action_12669988 ]
Tobias Bocanegra commented on SLING-848:
----------------------------------------
but do you want to add this to the resource resolver, or the request resolver?
so should a ResourceResolver.getResource("/something/hello;v=1.1") return a different version?
or should a request to "/something/hello.html;v=1.1" trigger a resource resolution to the respective version? (which eventually needs the former, too)
> 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 Install
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> 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.
[jira] Issue Comment Edited: (SLING-848) Support getting versioned
resources by using uri path parameters
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670136#action_12670136 ]
tripod edited comment on SLING-848 at 2/3/09 2:06 PM:
----------------------------------------------------------------
so consequently (according to rfc3986) , the v= parameter should be applicable to each segment. eg:
/content/home;v=1.0/tobi;v=1.5
(assuming /content/home/tobi is currently deleted and did only exist in the version 1.0 of the 'home')
what is the "external" form of this?, probably:
/content/home;v=1.0/tobi.html;v=1.5
having the .html at the end makes no sense.
but this makes every script logic that just appends the .html to the resource path pretty useless.
the problem you have is:
- if you include the v= to the resource.getPath() the resource gets unusable for "normal" scripts,
- if you omit it from the path, the getResource() / getPath() is not symmetric
so maybe this is not such a good idea after all?
btw: i think the "component" of this issue is wrong.
was (Author: tripod):
so consequently (according to rfc3986) , the v= parameter should be applicable to each segment. eg:
/content/home;v=1.0/tobi;v=1.5
(assuming /content/home/tobi is currently deleted and did only exist in the version 1.0 of the 'home')
what is the "external" form of this?, probably:
/content/home;v=1.0/tobi.html;v=1.5
having the .html at the end makes no sense.
but this makes each script logic that just appends the .html to the resource path pretty useless.
the problem you have is:
- if you include the v= to the resource.getPath() the resource gets unusable for "normal" scripts,
- if you omit it from the path, the getResource() / getPath() is not symmetric
so maybe this is not such a good idea after all?
btw: i think the "component" of this issue is wrong.
> 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 Install
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4
>
>
> 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.
[jira] Commented: (SLING-848) Support getting versioned resources
by using uri path parameters
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670740#action_12670740 ]
Tobias Bocanegra commented on SLING-848:
----------------------------------------
> content/home/tobi.selector.html?sling:v=1.5
that's what i meant.
> 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.