Could we please discuss things in the mailing list and not in Jira? This would make it much easier for others to see what is discussed and participate.
Thanks Carsten Bertrand Delacretaz (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/SLING-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535432 > ] > > Bertrand Delacretaz commented on SLING-60: > ------------------------------------------ > > Ok, I see your point...I started looking at the Sling code before > implementing this yesterday and then got lazy ;-) > > I'm not sure if resolving the Resource in a Filter is the best idea though: > how about making the ResourceResolver a first-class Sling API citizen > instead, and calling that from the SlingRequestContext on-demand, when the > Resource of the RequestPathInfo is accessed? > > This might make it easier to make the ResourceResolver a plugin (in Sling > OSGi mostly), and might also make the code clearer to follow? > > And I agree that the ResourceResolver must provide the URI parts after > resolving the resource. > >> 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. > -- Carsten Ziegeler [EMAIL PROTECTED]
