atom feed55 messages in Simplifying script paths and names?
FromSent OnAttachments
29 earlier messages
Felix MeschbergerApr 18, 2008 6:45 am 
Carsten ZiegelerApr 18, 2008 6:53 am 
Bertrand DelacretazApr 18, 2008 6:54 am 
Felix MeschbergerApr 18, 2008 7:07 am 
Felix MeschbergerApr 18, 2008 7:08 am 
Carsten ZiegelerApr 18, 2008 7:12 am 
Carsten ZiegelerApr 18, 2008 7:22 am 
Felix MeschbergerApr 18, 2008 7:30 am 
Carsten ZiegelerApr 18, 2008 7:35 am 
Felix MeschbergerApr 18, 2008 7:43 am 
Carsten ZiegelerApr 18, 2008 7:49 am 
Tobias BocanegraApr 18, 2008 9:34 am 
David NueschelerApr 25, 2008 7:40 am 
Felix MeschbergerApr 25, 2008 8:52 am 
Tobias BocanegraApr 25, 2008 9:35 am 
Dominik SüßApr 25, 2008 10:09 am 
Dominik SüßApr 25, 2008 12:07 pm 
Carsten ZiegelerApr 26, 2008 10:16 am 
Tobias BocanegraApr 26, 2008 10:45 am 
Dominik SüßApr 26, 2008 1:45 pm 
Tobias BocanegraApr 26, 2008 2:14 pm 
David NueschelerApr 27, 2008 4:37 am 
Bertrand DelacretazApr 28, 2008 6:22 am 
Felix MeschbergerApr 28, 2008 6:41 am 
Felix MeschbergerApr 28, 2008 8:33 am 
Bertrand DelacretazApr 29, 2008 12:50 am 
Subject:Re: Simplifying script paths and names?
From:Felix Meschberger (
Date:Apr 28, 2008 8:33:38 am

Hi all,

After re-reading this proposal and discussing it with David, also considering any consequences with respect to backwards compatibility, performance and usability, I would like to summarize, what we came up with.

(0) Fundamental: Scripts and Servlets are equal

In the following discussion, I will write about scripts. This will always include servlets as well. In fact, internally, Sling only handles with Servlets, whereas scripts are packed inside a Servlet wrapping and representing the script.

(I) Base: Resource Type Inheritance

While not exactly part of our discussion, resource type inheritance as implemented for SLING-278 plays a vital role in script resolution.

Each resource type may have a resource super type, which may be defined in various ways. One example is having a sling:resourceSuperType property in the node addressed by the resource type. See [1] and [2] for more details.

If a resource type has no explicit resource super type, the resource super type is assumed to be "sling/servlet/default". That is the resource type used for default script selection is also acting as a basic resource type much like java.lang.Object does for other types in the Java language.

(II) Script Locations

Scripts are looked up in a series of locations defined by the ResourceResolver.getSearchPath() and the resource type (and resource super types) of the requested resource:


The pseudo code for iterating the locations would be something like:

var type = resource.getResourceType(); while (type != null) { for (String root: resourceResolver.getSearchPath()) { String path = root + type.toPath(); findScriptsIn(path); }

if (type == defaultServlet) { type = null; } else { type = getResourceSuperType(type); if (type == null) { type = defaultServlet; } } }

(III) All requests are NOT equal

GET and HEAD request methods are treated differently than the other request methods. Only for GET and HEAD requests will the request selectors and extension be considered for script selection. For other requests the servlet or script name (without the script extension) must exactly match the request method.

That is for a PUT request, the script must be PUT.esp or PUT.jsp. For a GET request with a request extension of html, the script name may be html.esp or GET.esp.

(IV) Scripts for GET requests

Apart for supporting scripts named after the request method, scripts handling GET and HEAD requests may be named differently for Sling to support a more elaborate processing order.

Depending on whether request selectors are considered, a script may have two forms:

a. Ignoring request selectors (e.g. there are none in the request URI) {resourceTypeLabel}.{requestExtension}.{scriptExtension}

b. Handling request selectors {selectorStringPath}.{requestExtension}.{scriptExtension}

The constituents of these script names are as follows:

{resourceTypeLabel} - The last path segment of the path created from the resource type. This part is optional if the {requestExtension} is used in the script name. {requestExtension} - The request extension. This part may be ommitted if the request extension is "html", otherwise this part is required. If this part is ommitted, the {resourceTypeLabel} is required in the case of ignoring the selectors. {scriptExtension} - The extension, e.g. "esp" or "jsp", identifying the scripting langauage used. {selectorStringPath} - The selector string converted to a path, along the lines of selectorString.replace('.', '/').

(V) Priority

The rules for script path priorization is defined as follows:

* The more request selectors are matched, the better * A script including the request extension matches better than one without a request extension (for html only) * A script found earlier matches better than a script found later in the processing order. This means, that script closer to the original resource type in the resource type hierarchy is considered earlier.

(VI) Examples

Taking up again the list of potential script paths for a request of a resource whose resource type is sling:sample and the request selectors are "print.a4" and the request extension is "html" could be:

(0) GET.esp (1) sample.esp (2) html.esp (3) print.esp (4) print/a4.esp (5) print.html.esp (6) print/a4.html.esp

The priority of script selection would (6) - (4) - (5) - (3) - (2) - (1) - (0). Note that (4) is a better match than (5) because it matches more selectors even though (5) has an extension match where (4) does not.


Regards Felix

[1] [2]

Am Freitag, den 25.04.2008, 16:40 +0200 schrieb David Nuescheler:

hi guys,

after going through this entire discussion and looking at issue: i would like to raise the following point.

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


/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.

regards, david

On Fri, Apr 18, 2008 at 6:34 PM, Tobias Bocanegra <> wrote:

hi, i just want to add, that most of the requests that actually hit sling will probably be plain .html requests with no selectors. so the /apps/foo/foo.jsp will probably resolve those requests. since requests that usually need selectors are image requests which are very good cacheable in a higher teer. so i don't think that in a real-live scenario, the resource resolution performance is that relevant. and of course it can easily be cached.

-- toby

On 4/18/08, Carsten Ziegeler <> wrote:

Felix Meschberger wote:


Am Freitag, den 18.04.2008, 16:35 +0200 schrieb Carsten Ziegeler:

Having scripts in /apps and /libs where /libs has precendence of /apps still feels not very intuitive for me.

It is the other way around: /apps has precedence over /libs. And this is IMHO intuitive.

Hehe, you see, it's not intuitive for me (ok, I'll write down 100 times "apps has precedence over libs, apps has precedence over libs..."


-- Carsten Ziegeler