[
https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592393#action_12592393
]
David Nuescheler commented on SLING-387:
----------------------------------------
i think it is important that this change was originally suggested to
make the simple cases as simple and intuitive as possible for
the user of sling and not to come up with something that is really
easy and consistent to map for the sling implementation.
let me try to explain with an example:
as a user of sling i would like to have my app in
/apps/myapp and lets say i have a node of resourceType
"myapp/homepage" at "/content/myapp".
i would like to to be able to structure my applications as follows:
(1) /apps/myapp/homepage/hompage.esp (or html.esp or GET.esp)
(2) /apps/myapp/homepage/edit.esp (or edit.html.esp)
(3) /apps/myapp/homepage/header/highlight.jpg.esp
(4) /apps/myapp/homepage/header/selected.jpg.esp
(5) /apps/myapp/homepage/header/small.jpg.esp
where
/content/myapp.html -> (1)
/content/myapp.edit.html -> (2)
/content/myapp.header.highlight.jpg -> (3)
/content/myapp.header.selected.jpg -> (4)
/content/myapp.header.small.jpg -> (5)
i think it is important that we avoid unnecessary repetition at any point
and we would allow for enough flexibility in the /apps directory allow
the user to come up with something short, distinct and meaningful.
> Simplify script paths and names
> -------------------------------
>
> Key: SLING-387
> URL: https://issues.apache.org/jira/browse/SLING-387
> Project: Sling
> Issue Type: Bug
> Components: Scripting, ServletResolver
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> According to the findings in the dev list thread "Simplifying script paths
> and names?" at [1] I would now like to propose the implementation of this
> change in script/servlet path resolution:
> Note: This issue talks about scripts. But as servlets are mirrored into the
> virtual Resource Tree accessible through the ResourceResolver, servlets are
> treated exactly the same as scripts (or vice-versa actually). So the
> discussion applies to servlets as well as to scripts.
> (1) Script Location
> Scripts to handle the processing or a resource are looked up in a single
> location:
> {scriptPathPrefix}/{resourceTypePath}
> Where {scriptPathPrefix} is an absolute path prefix (as per
> ResourceResolver.getSearchPath()) to get absolute paths and
> {resourceTypePath} is the resource type converted to a path. If the
> {resourceTypePath} is actually an absolute path, the {scriptPathPrefix} is
> not used.
> Example: Given the search path [ "/apps", "/libs" ] and a resource type of
> sling:sample, the following locations will be searched for scripts:
> * /aps/sling/script
> * /libs/sling/script
> (2) Within the location(s) found through above mechanism a script is searched
> whose script name matches the pattern
>
> {resourceTypeLabel}.{selectorString}.{requestMethod}.{requestExtension}.{scriptExtension}
> where the fields have the following meaning:
> {resourceTypeLabel} - the last segment of the {resourceTypePath} (see
> above)
> This part is required. Only scripts whose name starts
> with this name are considerd
> {selectorString} - the selector string as per
> RequestPathInfo.getSelectorString
> This part is optional. The more selectors of the selector
> string match, the
> better.
> {requestMethod}
> The request method name. This is optional for GET or HEAD
> requests
> and is required for non-GET/non-HEAD requests
> {requestExtension}
> The extension of the request. This is optional.
> {scriptExtension}
> The extension indicating the script language. Not used
> for selecting
> the script but for selecting the ScriptEngine. This is
> of course not existing
> for servlets.
> If multiple scripts would apply for a given request, the script with the best
> match is selected. Generally speaking a match is better if it is more
> specific. More in detail, a match with more selector matches is better than a
> match with less selector matches, regardless of any request extension or
> method name match.
> For example, consider a request to resource /foo/bar.print.a4.html of type
> sling:sample. Assuming we have the following list of scripts in the correct
> location:
> (1) sample.esp
> (2) sample.GET.esp
> (3) sample.GET.html.esp
> (4) sample.html.esp
> (5) sample.print.esp
> (6) sample.print.a4.esp
> (7) sample.print.html.esp
> (8) sample.print.GET.html.esp
> (9) sample.print.a4.html.esp
> (10) sample.print.a4.GET.html.esp
> It would probably be (10) - (9) - (6) - (8) - (7) - (5) - (3) - (4) - (2) -
> (1). Note that (6) is a better match than (8) because it matches more
> selectors even though (8) has a method name and extension match where (6)
> does not.
> If there is a catch, e.g. between print.esp and print.jsp, the first script
> in the listing would be selected (of course, there should not be a catch...)
> [1] http://markmail.org/message/odduiwskv7ogdtz2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
