Apache Sling is one of the technology stack of AEM/CQ5 CMS on which AEM is built on. Sling is a Web application framework based on REST principles that provides easy
development of content-oriented applications. In general terms we can say Sling is used to resolve the resources or URI in our application. Sling uses a JCR repository, such
as Apache Jackrabbit or Day's CRX, as its data
store.
Sling maps HTTP request URLs to content resources based on the request's path, extension and selectors.
The Resource is one of the central parts of Sling. Extending from JCR, Everything is Content, and Sling assumes that Everything is a Resource.
Apache Sling is included in the
installation of CQ5. Sling has since been contributed to the Apache Software
Foundation - further information can be found at Apache Sling.
Using Apache 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. This provides excellent
support for Web content authors to build
Pages which 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/viewed
differently.
How sling used to resolve a URL (Resource) in AEM? and How sling works internally?
The following diagram explains
the Sling script resolution. It shows how to get from HTTP request to content
node, from content node to resource type, from resource type to script and what
scripting variables are available.
 |
| Sling Resource resolver |
The following diagram explains
all the hidden, but powerful request parameters you can use when dealing with
the SlingPostServlet, the default handler for all POST requests that gives you
endless options for creating, modifying, deleting, copying and moving nodes in
the repository.
We will now see how sling resolve a URL by using the above resolution diagram.
1. Actual URL get divided into the following chunks. e.g. we have a URL " www.rashidjorvee.blogspot.com/blog/post/aboutrashid.print.html/printable?height=400,width=200" and now we will see how sling will resolve my URL.
- Request Method: This information comes in request header.
- Content Path: [/blog/post/aboutrashid]
- Query parameter : [height=400,width=200]
2. Sling will go to the requested content path.
3. Then it will check whether that content path or component has property sling:resourceSuperType or sling:resourceType. If request found any of these property in that node then sling request move to that path which is present in the sling:resourceType or sling:resourceSuperType.
sling:resourceType is used to render to script files.
sling:resourceSuperType is used to overload or inherit a existing component.
4. Then render to the path given in resourceType and resourceSuperType property to load the script or inherit the functionality. To resolve this first sling will find the path under apps directory, in case that content path is not available in apps then request will move under libs directory.
5. In this step sling will look for script name and try to match with the exact request URL with requested selector and extension. There is a set of rules which sling follow to match the selector and extension. Following are the rules:
- Folders (i.e. nodes of type nt:folder) take precedence over jsp file names when resolving using selectors, at least for the first selector.
- Only one selector in a file name has any effect - any files with names containing two selectors don't ever get selected, but names of folders can be used to match the selectors in the request.
- Scripts with HTTP method names (e.g.,GET.jsp) is selected as a last resort, (after the default script: jobs.jsp, in this case).
- Scripts with names that include HTTP methods in addition to another selector or extension in a .jsp file name are never selected.