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
             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) print.esp
   (2) print.a4.esp
   (3) print.html.esp
   (4) print.GET.html.esp
   (5) print.a4.html.esp
   (6) print.a4.GET.html.esp

It would probably be (6) - (5) - (2) - (4) - (3) - (1). Note that (2) is a 
better match than (4) because it matches more selectors even though (4) has a 
method name and extension match where (2) 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.

Reply via email to