Naming conventions in the JCR

Adhering to naming conventions in Java Content Repository (JCR) enhances code consistency, reduces the occurrence of defects, and boosts developer productivity within the system. Adobe employs the following conventions in the development of AEM:

Node names

• All lower case
• Word separation using hyphens

Property names

• Camel case, starting with a lower case letter

Components (JSP/HTML)

• All lower case
• Word separation using hyphens

References

• https://experienceleague.adobe.com/docs/experience-manager-65/developing/bestpractices/content-architecture.html

Bundle is NOT whitelisted in AEM

While using the loginAdministrative() method of SlingRepository class you might see an error "Bundle is not whitelisted". To get this method work we have to whitelist the bundle in OSGi configuration "Apache Sling Login Admin Whitelist" this helps us to defines which bundles can use SlingRepository.loginAdministrative().

Below is the code snippet of creating session using loginAdministartive method.

@Reference
private SlingRepository repository

Session session = repository.loginAdministrative(null);

What is Sling and why have multiple scripts/renderers for a Component?

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] 

• Seletor: [print]

• Extension: [html]

• Suffix:

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