RE: Formalized URL decomposition (was Re: sling.include "cleansing" URI?)

[Mike Müller <mi...@mysign.ch>]

Hi

The documentation under [1] is not quite up to date (as mentioned
on the top of the page). The page is subject to be dropped out in
the future. I created a new page with current information
about URL decomposition under [2]. I hope this will clarify it.


[1] http://sling.apache.org/site/sling-api.html
[2] http://cwiki.apache.org/confluence/display/SLINGxSITE/URL+decomposition

best regards
mike


> Hi everyone,
>
> I'd like to keep this discussion rolling from here, because I
> think this
> an important aspect of Sling that should be clear and
> accurately documented.
>
> If we can formalize this through discussion, I can update a
> wiki (if I
> may be granted access) with the final result. If the URL
> decomposition
> in the sling-api wiki is in fact how it should be, I can
> create the bug
> reports (if I may be granted access) and hopefully clean up the unit
> test cases.
>
> Can anyone clarify how this algorithm should be working?
>
> Thanks,
>
> Branden
>
> Alexander Klimetschek wrote:
> > On Tue, Aug 25, 2009 at 7:19 PM, Branden
> Visser<br...@uwindsor.ca> wrote:
> >> The rules under "Request Processing" at:
> >> http://sling.apache.org/site/sling-api.html say that the
> request path is the
> >> longest substring resolving to a resource that is either
> the complete
> >> request URL, or the next character is either a dot
> (beginning of selectors
> >> and extension) or a slash (beginning of suffix).
> >
> > Not exactly sure, but I guess the actual way it works (and
> technically
> > the only stable way) is that it
> > a) splits the uri at the first dot
> > b) finds the longest matching resource path of the first
> part of the split
> >
> > c) the second part is separated into selectors (in between dots)
> > d) last dot-separated part is extension
> > e) starting with a slash after the extension will be the suffix
> >
> > Given that, the documentation is probably not exact. But someone
> > (Felix?) should clarify on that.
> >
> > Regards,
> > Alex
> >
>

RE: Formalized URL decomposition (was Re: sling.include "cleansing" URI?)

[Mike Müller <mi...@mysign.ch>]

Hi Branden

AFAIK the sling.include is not treated like the normal GET request.
sling.include is designed to load another resource in the same request.
So in case of sling.include the path should be the path to the resource
and nothing else (absolute or relative to the "main" resource). Optionally
you can add or replace selectors or replace the suffix and/or force the
resourceType.
To get an overview over the whole request dispatching process have a
look at [1].

[1] http://sling.apache.org/site/dispatching-requests.html

best regards
mike

> -----Original Message-----
> From: Branden Visser [mailto:branden@uwindsor.ca]
> Sent: Wednesday, September 02, 2009 3:11 PM
> To: dev@sling.apache.org
> Subject: Re: Formalized URL decomposition (was Re: sling.include
> "cleansing" URI?)
>
>
> Great! Thanks Mike.
>
> So, that said, I'd like to report a bug with the following case (the
> original post about sling.include):
>
> sling.include('/a/b./c/d');
>
> This does not follow the chart. Sling will treat this as:
>
> Resource Path: /a/b/c/d
> Selectors: null
> Extension: null
> Suffix: null
> Resource Found: no!
>
> The GET request at /a/b./c/d works properly.
>
> Thanks,
>
> Branden
>
> Mike Müller wrote:
> > Hi
> >
> > The documentation under [1] is not quite up to date (as mentioned
> > on the top of the page). The page is subject to be dropped out in
> > the future. I created a new page with current information
> > about URL decomposition under [2]. I hope this will clarify it.
> >
> >
> > [1] http://sling.apache.org/site/sling-api.html
> > [2]
> http://cwiki.apache.org/confluence/display/SLINGxSITE/URL+deco
> mposition
> >
> > best regards
> > mike
> >
> >
> >> Hi everyone,
> >>
> >> I'd like to keep this discussion rolling from here, because I
> >> think this
> >> an important aspect of Sling that should be clear and
> >> accurately documented.
> >>
> >> If we can formalize this through discussion, I can update a
> >> wiki (if I
> >> may be granted access) with the final result. If the URL
> >> decomposition
> >> in the sling-api wiki is in fact how it should be, I can
> >> create the bug
> >> reports (if I may be granted access) and hopefully clean
> up the unit
> >> test cases.
> >>
> >> Can anyone clarify how this algorithm should be working?
> >>
> >> Thanks,
> >>
> >> Branden
> >>
> >> Alexander Klimetschek wrote:
> >>> On Tue, Aug 25, 2009 at 7:19 PM, Branden
> >> Visser<br...@uwindsor.ca> wrote:
> >>>> The rules under "Request Processing" at:
> >>>> http://sling.apache.org/site/sling-api.html say that the
> >> request path is the
> >>>> longest substring resolving to a resource that is either
> >> the complete
> >>>> request URL, or the next character is either a dot
> >> (beginning of selectors
> >>>> and extension) or a slash (beginning of suffix).
> >>> Not exactly sure, but I guess the actual way it works (and
> >> technically
> >>> the only stable way) is that it
> >>> a) splits the uri at the first dot
> >>> b) finds the longest matching resource path of the first
> >> part of the split
> >>> c) the second part is separated into selectors (in between dots)
> >>> d) last dot-separated part is extension
> >>> e) starting with a slash after the extension will be the suffix
> >>>
> >>> Given that, the documentation is probably not exact. But someone
> >>> (Felix?) should clarify on that.
> >>>
> >>> Regards,
> >>> Alex
> >>>
>

Re: Formalized URL decomposition (was Re: sling.include "cleansing" URI?)

[Branden Visser <br...@uwindsor.ca>]

Great! Thanks Mike.

So, that said, I'd like to report a bug with the following case (the 
original post about sling.include):

sling.include('/a/b./c/d');

This does not follow the chart. Sling will treat this as:

Resource Path: /a/b/c/d
Selectors: null
Extension: null
Suffix: null
Resource Found: no!

The GET request at /a/b./c/d works properly.

Thanks,

Branden

Mike Müller wrote:
> Hi
> 
> The documentation under [1] is not quite up to date (as mentioned
> on the top of the page). The page is subject to be dropped out in
> the future. I created a new page with current information
> about URL decomposition under [2]. I hope this will clarify it.
> 
> 
> [1] http://sling.apache.org/site/sling-api.html
> [2] http://cwiki.apache.org/confluence/display/SLINGxSITE/URL+decomposition
> 
> best regards
> mike
> 
> 
>> Hi everyone,
>>
>> I'd like to keep this discussion rolling from here, because I
>> think this
>> an important aspect of Sling that should be clear and
>> accurately documented.
>>
>> If we can formalize this through discussion, I can update a
>> wiki (if I
>> may be granted access) with the final result. If the URL
>> decomposition
>> in the sling-api wiki is in fact how it should be, I can
>> create the bug
>> reports (if I may be granted access) and hopefully clean up the unit
>> test cases.
>>
>> Can anyone clarify how this algorithm should be working?
>>
>> Thanks,
>>
>> Branden
>>
>> Alexander Klimetschek wrote:
>>> On Tue, Aug 25, 2009 at 7:19 PM, Branden
>> Visser<br...@uwindsor.ca> wrote:
>>>> The rules under "Request Processing" at:
>>>> http://sling.apache.org/site/sling-api.html say that the
>> request path is the
>>>> longest substring resolving to a resource that is either
>> the complete
>>>> request URL, or the next character is either a dot
>> (beginning of selectors
>>>> and extension) or a slash (beginning of suffix).
>>> Not exactly sure, but I guess the actual way it works (and
>> technically
>>> the only stable way) is that it
>>> a) splits the uri at the first dot
>>> b) finds the longest matching resource path of the first
>> part of the split
>>> c) the second part is separated into selectors (in between dots)
>>> d) last dot-separated part is extension
>>> e) starting with a slash after the extension will be the suffix
>>>
>>> Given that, the documentation is probably not exact. But someone
>>> (Felix?) should clarify on that.
>>>
>>> Regards,
>>> Alex
>>>