[jira] Updated: (SLING-60) SlingRequestPathInfo values must depend on path used by ResourceResolver

["Bertrand Delacretaz (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bertrand Delacretaz updated SLING-60:
-------------------------------------

    Summary: SlingRequestPathInfo values must depend on path used by ResourceResolver  (was: URI path split is content dependent)

> SlingRequestPathInfo values must depend on path used by ResourceResolver
> ------------------------------------------------------------------------
>
>                 Key: SLING-60
>                 URL: https://issues.apache.org/jira/browse/SLING-60
>             Project: Sling
>          Issue Type: Improvement
>          Components: microsling
>            Reporter: Felix Meschberger
>            Assignee: Bertrand Delacretaz
>             Fix For: 2.0.0
>
>
> I have a conceptual issue with the SlingRequestPathInfoParser because the idea of cutting an URI path into pieces is different and the SlingRequestPathInfoParser just does not have enough knowledge to break the URI path apart.
> The initial intent of breaking the URI apart such, that the resource path is the the longest prefix of the URI path matching a repository item (I think we should move to enabling addressing items and not just nodes...) and the rest of the breakup depends on the first part.
> So a simple implementation would be to cut off pieces of the URI path from the end at dots and slashes until a repository item may be addressed. What has been cut off is then further treated like this:
>    * Any pieces separated by a dot from the path in the same path segement are considered the
>      selectors and extension.
>    * All pieces together after the last segement of the item path make up the suffix.
> Examples:
> /a/b/c.print.a4.html/some/suffix.pdf with an item at /a/b/c would be broken apart as resourcePath=/a/b/c, selectors=[print,a4], ext=html, suffix=/some/suffix.pdf
>         
> /a/b.special/c.print.a4.html/some/suffix.pdf with an item at /a/b.special/c would be broken apart as resourcePath=/a/b.special/c, selectors=[print,a4], ext=html, suffix=/some/suffix.pdf
>         
> Simple string operations cannot account for this subtelity. For this reason I propse to drop the SlingRequestPathInfoParser class and implement the split up in the ResourceResolverFilter or an abstract base class thereoff.
> See also the ContentResolverFilter in the Sling Core project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.