Apache Sling Resource Resolution (Sling Request Processing)

Introduction to Sling
Sling is a Web application framework based on REST principles. It provides easy development of content-oriented applications. Sling uses a JCR repository as its data store.

CQ/AEM is built using Sling.

“Using Sling, the type of content to be rendered is not the first processing consideration. Instead, the main consideration is whether the URL resolves to a content object for which a script can then be found to perform the rendering.”

URL Decomposition
In CQ/AEM, the processing is solely driven by the URL. URL entered by a user defines the content to be displayed using an appropriate script.

1. Content path is first extracted from the request URL, the context path used to locate the resource.

2. The sling resource type is extracted from the located resource, the sling resource type is then used to locate the script to be used for rendering the content.

To do this, information is extracted from the URL. If we analyze the following URL:

http://myhost/tools/spy.printable.a4.html/a/b?x=12
URL can be broken into its composite parts:



· Protocol
HTTP

· host
Name of the website. (ex: http://www.aem4beginner.blogspot.com)

· content path
the content path is used in combination with the extension. It specifies the content to be rendered. In this example, it translates to tools/spy.html.

· selector(s)
selector specifies for alternative methods of rendering the content; in this example a printer-friendly version in A4 format.

· Extension
Extension specifies the Content format of the response; It also specifies the script to be used for rendering.

· suffix
Suffixes are used to specify additional information.

· param(s)
Any parameters required for dynamic content.

The figure below illustrates the mechanism of the sling to locate content and scripts


The request is broken down and the necessary information extracted.

Given the URL http://myhost/content/corporate/jobs/developer.html

Mapping Request to Resource
The repository is searched for the requested resource (content node):

1. Sling first checks whether a node exists at /content/corporate/jobs/developer.html

2. If no node is found, the extension is dropped and the search repeated. i.e. now Sling will search at /content/corporate/jobs/developer.

3. If no node is found then Sling will return the http code 404 (Not Found).

Locating the script
When the appropriate resource (content node) is located, Sling will extract the sling resource type from the content node. This is a path, which locates the script to be used for rendering the content. All Sling scripts are stored in subfolders of either /apps or /libs.

Using the above example, if the sling:resourceType is hr/jobs then for:

· GET/HEAD requests, and URLs ending in .html (default request types, default format)

The script will be /apps/hr/jobs/jobs.esp; the last section of the sling:resourceType forms the file name.

· POST requests (all request types excluding GET/HEAD, the method name must be uppercase)

POST will be used in the script name.

The script will be /apps/hr/jobs/POST.esp.

· URL/s in other formats, not ending with .html
For example ../content/corporate/jobs/developer.pdf

The script will be /apps/hr/jobs/jobs.pdf.esp; the suffix is added to the script name.

· URLs with selectors

Selectors can be used to display the same content in an alternative format. For example a printer friendly version, an RSS feed or a summary.

If we look at a printer friendly version where the selector could be print; as in ../content/ corporate/jobs/developer.print.html

The script will be /apps/hr/jobs/jobs.print.esp; the selector is added to the script name.

· If no sling:resourceType has been defined then:

1. the content path will be used to search for an appropriate script (if the path based ResourceTypeProvider is active).

For example, the script for ../content/corporate/jobs/developer.html would generate a search in /apps/content/corporate/jobs/.

2. the primary node type will be used.

· If no script is found at all then the default script will be used.

The default rendition is currently supported as plain text (.txt), HTML (.html) and JSON (.json), all of which will list the node’s properties (suitably formatted). The default rendition for the extension .res, or requests without a request extension, is to spool the resource (where possible).

· For http error handling (codes 404 or 500) Sling will look for a script at /libs/sling/ servlet/errorhandler/404.esp, or 500.esp, respectively.

If multiple scripts apply for a given request, the script with the best match is selected. The more specific a match is, the better it is; in other words, the more selector matches the better, regardless of any request extension or method name match.

For example, consider a request to access the resource /content/corporate/jobs/ developer.print.a4.html of type sling:resourceType=”hr/jobs”. Assuming we have the following list of scripts in the correct location:

1. jobs.esp
2. jobs.GET.esp
3. jobs.GET.html.esp
4. jobs.html.esp
5. jobs.print.esp
6. jobs.print.a4.esp
7. jobs.print.html.esp
8. jobs.print.GET.html.esp
9. jobs.print.a4.html.esp
10.jobs.print.a4.GET.html.esp

Then the order of preference would be (10) – (9) – (6) – (8) – (7) – (5) – (3) – (4) – (2) – (1).

This provides excellent support for web content authors to build pages that are easily customized to their requirements. The advantages of this flexibility are apparent in applications with a wide range of different content elements, or when you need pages that can be easily customized. In particular, when implementing a Web Content Management system such as CQ WCM.