Introduction to Sling
Sling is an innovative web framework which is developed by Apache software foundation. It takes the place on top of JCR in technology stack. It uses Java Content Repository for storing and managing data in JCR. Sling applications use either scripts or Java servlets, selected based on simple name conventions, to process HTTP requests in a RESTful way.
Being a REST framework, Sling is oriented around resources, which usually map into JCR nodes.
Again, just to remind you – Apache Sling is all about Resource-first request processing!
Advantages
- Uses well documented, well established, well used technology and methodology
- Resource-centric rather than method-centric
- Given a URI anyone already knows how to access it
- Response payload can be of any format·
- Uses the inherent HTTP security model
- Stateless and RESTful
- Content-driven, using a JCR content repository
- Powered by OSGi
- Scripting inside, multiple languages (JSP, server-side javascript)
- Apache open source project.
Sling Architecture
- OSGi—Sling applications are built as OSGi bundles and makes heavy use of a number of OSGi core and services.
- Sling API—The Sling API extends the Servlet API and provides more functionality to work on the content.
- Request Processing —Sling takes a unique approach to handling requests in that a request URL is first resolved to a resource, then based on the resource (and only the resource) it selects the actual servlet or script to handle the request.
- Resources—Sling considers everything in the JCR as a Resource. Based on the resource, a servlet or script is accessed to actually handle the request.
- Servlets and Scripts —Servlets and Scripts are handled uniformly in that they are represented as resources themselves and are accessible by a resource path.
AEM Sling APIs
- TheSling APIdefines a presentation framework to build Web Applications.
- The Sling API is resource centric. That is, the request URL does not address a servlet or a portletbut a resource represented by an instance of the org.apache.sling.api.resource.Resource interface
- The Sling API uses the URL to select a resource to be delivered. You can retrieve content from the AEM JCR using Sling APIs. You can use the Sling API from within an OSGi bundle to retrieve a resource from within the AEM JCR.
- To use the Sling API from within an OSGi component, you inject an org.apache.sling.api.resource.ResourceResolverFactory instance into the service
- When using the Sling API to query the AEM JCR, you have access to helper methods that are not available when using the JCR API. For example, the adaptTo method converts a resource into an appropriate object representing a certain aspect of this resource
- For example to translate a Resourceobject to the corresponding Node object, you invoke the adaptTo method:
Node node= resource.adaptTo(Node.class);
AEM/CQ5 with Sling
As discussed, Sling purely focuses on resources. The Resource is one of the central concepts of Sling. JCR is content centric (Everything is content) whereas Sling is resource centric (Everything is resource). Sling takes a unique approach to handling requests in that a request URL is first resolved to a resource, and then based on the resource (and only the resource) it selects the actual servlet or script to handle the request.
In Sling, and therefore also AEM/CQ5, processing is driven by the URL of the HTTP request. This defines the content to be displayed by the appropriate scripts. To do this, information is extracted from the URL.
If we analyze the following URL:
http://myhost/tools/spy.print.a4.html/a/b?x=12
We can break it down into its composite parts:
Sling request decomposition table
When the appropriate resource (content node) is located, the resource type is extracted. This is a path, which locates the script to be used for rendering the content. The path specified by the sling:resourceType property can be either absolute or relative to a configuration parameter. Relative paths are recommended as they increase portability.
All Sling scripts are stored in subfolders of either /apps or /libs, which will be searched in this order. The following diagram illustrates how a script resolution is resolved.
Sling request decomposition
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.
The priority for best match will be as follows
1. <component_name>.html.jsp [selector+extension will be the best match.]
2. html.jsp
3. <component_name>.jsp
4. <component_name>.html
Finally, if anybody wants to develop RESTful web applications use nothing but Apache Sling. It’s dynamic and real which is very comfortable player with Java too.
Thank you
Adobe Experience Manager 