URI path split is content dependent
-----------------------------------
Key: SLING-60
URL: https://issues.apache.org/jira/browse/SLING-60
Project: Sling
Issue Type: Improvement
Components: microsling
Reporter: Felix Meschberger
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.
