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/04/18 13:14:21 UTC
[jira] Created: (SLING-387) Simplify script paths and names
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.
[jira] Commented: (SLING-387) Simplify script paths and names
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593369#action_12593369 ]
Bertrand Delacretaz commented on SLING-387:
-------------------------------------------
I haven't found out how to hook a script to POST with a "delete" selector, tried POST.delete.html.esp and various other options but that didn't work.
Looking at the code, I think that might not work at all, and I didn't find tests related to this.
> 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.
[jira] Updated: (SLING-387) Simplify script paths and names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-387:
------------------------------------
Attachment: SLING387.patch
This patch should implemented the latest decision from [1]
As soon as SVN gets back up, I will try to check this in.
[1] http://markmail.org/message/tksvk4xfwapdpkwo
> 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
>
>
> 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.
[jira] Updated: (SLING-387) Simplify script paths and names
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Delacretaz updated SLING-387:
--------------------------------------
Attachment: SLING387.patch
Updated patch that also removes some classes under sling/servlets-get
> 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.
[jira] Closed: (SLING-387) Simplify script paths and names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-387.
-----------------------------------
Resolution: Fixed
In Rev. 654438 finalized implementation of this issue:
* Refactored resolution of error handler servlets/scripts to use new mechanism
* Removed unused methods and classes
* Renamed helper classes to reflect their functionality
Closing this issue for now. Errors in the new implementation should be reported in new issues.
> 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.
[jira] Issue Comment Edited: (SLING-387) Simplify script paths and
names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SLING-387) Simplify script paths and names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594196#action_12594196 ]
Felix Meschberger commented on SLING-387:
-----------------------------------------
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.
[jira] Commented: (SLING-387) Simplify script paths and names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593395#action_12593395 ]
Felix Meschberger commented on SLING-387:
-----------------------------------------
The correct script path would be .../delete/POST.esp
> 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.
[jira] Updated: (SLING-387) Simplify script paths and names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-387:
------------------------------------
Description:
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
was:
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
> 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) 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.
[jira] Commented: (SLING-387) Simplify script paths and names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594160#action_12594160 ]
Felix Meschberger commented on SLING-387:
-----------------------------------------
Implemented first step of refactoring in Rev. 653326.
Remains: Check error handler script/servlet resolution and clean up unused code.
> 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.
[jira] Commented: (SLING-387) Simplify script paths and names
Posted by "David Nuescheler (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SLING-387) Simplify script paths and names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590431#action_12590431 ]
Felix Meschberger commented on SLING-387:
-----------------------------------------
the initial "*" in the lines is just a numbering symbol. It has no code significance. And yes, your fixes are correct.
> 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) 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.
[jira] Commented: (SLING-387) Simplify script paths and names
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590425#action_12590425 ]
Bertrand Delacretaz commented on SLING-387:
-------------------------------------------
> 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
I think this should be
/apps/sling/sample
/lib/sling/sample
And I'm not sure what the initial */ means in your example, I thought the search paths were absolute.
> 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) 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.
[jira] Commented: (SLING-387) Simplify script paths and names
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594193#action_12594193 ]
Bertrand Delacretaz commented on SLING-387:
-------------------------------------------
Added ScriptSelectionTest in revision 653378, with the testHtmlPostSelectors commented out as it fails.
> 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.
[jira] Commented: (SLING-387) Simplify script paths and names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590391#action_12590391 ]
Felix Meschberger commented on SLING-387:
-----------------------------------------
To be clear: This new mechanism replaces the script resolution mechanism of today. As such this change is not backwards compatible and existing applications will have to be adapted.
> 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.
[jira] Assigned: (SLING-387) Simplify script paths and names
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger reassigned SLING-387:
---------------------------------------
Assignee: Felix Meschberger
> 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.