You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2008/05/05 13:49:55 UTC

[jira] Issue Comment Edited: (SLING-387) Simplify script paths and names

    [ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594196#action_12594196 ] 

fmeschbe edited comment on SLING-387 at 5/5/08 4:47 AM:
-----------------------------------------------------------------

Request Selectors are ignored for non-GET/HEAD requests. Hence the POST-related test is expected to fail. This is related to issue (III) in [1] stating that not all request methods are equal.

Hence, I suggest to for the moment comment out these tests with a comment stating this situation and not implementing that support. Reason for this is, that a resource URL should address the resource (and at most give some hint for a specific representation, such as html or txt) but not include an operation such as delete.

[1] http://markmail.org/message/tksvk4xfwapdpkwo

      was (Author: fmeschbe):
    Ah ! The request selectors are not considered for non-GET requests. This is probably an error.
  
> 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
>
>         Attachments: SLING387.patch, SLING387.patch
>
>
> 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.