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
Maybe this is would be bad design, but to me it makes sense to first and
foremost find the deepest resolvable resource before the first '.',
rather than rely on a dot or the full URL to tell it where the resource
should be.
One use case I have (which is why I've been trying to extract a suffix
from this) is that I have a content structure like so:
.../pages/home/widgets/hello_world
Where 'home' is of type 'portal/page', and was created by a user.
When the 'home' page is created, somehow that 'widgets' directory needs
to be created. So, if I try and access the list of widgets that belong
to the 'home' page, I can do:
.../pages/home/widgets.html
If the /widgets folder doesn't exist yet, I have a GET.esp file that
maps to 'portal/page' type that can create the subdirectory for me
(verifying that this is what the request is looking for, of course),
then do a sling.include(.../pages/home/widgets.html) to transparently
fill in the structure.
If anyone has a better way to accomplish this without using suffix, I am
all ears (eyes?) :-)
Thanks,
Branden
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
