You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2007/10/17 08:59:50 UTC
[jira] Commented: (SLING-60) URI path split is content dependent
[ 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-60) URI path split is content dependent
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/17/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...Lets make the ResourceResolver a service called by
> the SlingRequestContext on demand...
cool
> ...btw, the SlingRequestContext must
> then probably have a reference to the request, right ?)....
Yes, agreed.
-Bertrand
Re: [jira] Commented: (SLING-60) URI path split is content
dependent
Posted by Felix Meschberger <fm...@gmail.com>.
I completely agree with respect to not using a Filter for
ResourceResolution. Lets make the ResourceResolver a service called by
the SlingRequestContext on demand (btw, the SlingRequestContext must
then probably have a reference to the request, right ?).
Regards
Felix
Am Mittwoch, den 17.10.2007, 09:11 +0200 schrieb Bertrand Delacretaz:
> On 10/17/07, Carsten Ziegeler <cz...@apache.org> wrote:
> > Could we please discuss things in the mailing list and not in Jira...
>
> Sure, let me restate what I said in JIRA-60 here:
>
> I agree with what Felix says in JIRA-60, about the RequestPathInfo
> (selectors, extension, suffix, etc) being dependent on the way the
> Resource is resolved. So the current microsling
> SlingRequestPathInfoParser is wrong in its current state.
>
> But I'm not sure if resolving the Resource in a Filter is the best
> idea: 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?
>
> I think Filters are good for either manipulating the Request before
> processing it, or enhancing the Request attributes with "small" things
> that are not always needed, like the detected Locale for example.
>
> But something as fundamental as finding the Resource to act on (and
> computing the RequestPathInfo) should not be "hidden" in a Filter,
> IMHO.
>
> -Bertrand
Re: [jira] Commented: (SLING-60) URI path split is content dependent
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/17/07, Carsten Ziegeler <cz...@apache.org> wrote:
> Could we please discuss things in the mailing list and not in Jira...
Sure, let me restate what I said in JIRA-60 here:
I agree with what Felix says in JIRA-60, about the RequestPathInfo
(selectors, extension, suffix, etc) being dependent on the way the
Resource is resolved. So the current microsling
SlingRequestPathInfoParser is wrong in its current state.
But I'm not sure if resolving the Resource in a Filter is the best
idea: 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?
I think Filters are good for either manipulating the Request before
processing it, or enhancing the Request attributes with "small" things
that are not always needed, like the detected Locale for example.
But something as fundamental as finding the Resource to act on (and
computing the RequestPathInfo) should not be "hidden" in a Filter,
IMHO.
-Bertrand
Re: [jira] Commented: (SLING-60) URI path split is content dependent
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org