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:
{scriptPathPrefix}/{resourceTypePath}
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.
WDYT ?
Regards
Felix
[1]
http://www.mail-archive.com/[email protected]/msg02365.html
[2] http://issues.apache.org/jira/browse/SLING-278
Am Freitag, den 25.04.2008, 16:40 +0200 schrieb David Nuescheler:
> hi guys,
>
> after going through this entire discussion and looking at issue:
> https://issues.apache.org/jira/browse/SLING-387
> 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
>
> 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.
>
> regards,
> david
>
>
>
>
>
> On Fri, Apr 18, 2008 at 6:34 PM, Tobias Bocanegra
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > > Felix Meschberger wote:
> > >
> > >
> > > > Hi,
> > > >
> > > > 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
> > >
> > > --
> > > Carsten Ziegeler
> > > [EMAIL PROTECTED]
> > >
> >
>
>
>
