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<[email protected]> 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 > > >
