AEM Core Concepts aem-core-concepts

Prerequisites for Developing on AEM prerequisites-for-developing-on-aem

You need the following skills for developing on top of AEM:

It is also recommended that you read and follow the Guidelines and Best Practices.

Java™ Content Repository java-content-repository

The Java™ Content Repository (JCR) standard, JSR 283, specifies a vendor-independent and implementation-independent way to access content bi-directionally on a granular level within a content repository.

Specification lead is held by Adobe Research (Switzerland) AG.

The JCR API 2.0 package, javax.jcr.* is used for the direct access and manipulation of repository content.

Experience Server (CRX) and Jackrabbit experience-server-crx-and-jackrabbit

The Experience Server provides the Experience Services which AEM is built on, and which can be used to build custom applications, and it embeds the Content Repository based on Jackrabbit.

Apache Jackrabbit is an open source, fully conforming, implementation of the JCR API 2.0.

Sling Request Processing sling-request-processing

Introduction to Sling introduction-to-sling

AEM is built using Sling, a Web application framework-based on REST principles that provides easy development of content-oriented applications. Sling uses a JCR repository, such as Apache Jackrabbit or, if there is AEM, the CRX Content Repository, as its data store. Sling has been contributed to the Apache Software Foundation - further information can be found at Apache.

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. 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. In particular, when implementing a Web Content Management system such as the WCM in the AEM solution.

See Discover Sling in 15 minutes for the first steps for developing with Sling.

The following diagram explains 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.

The following diagram explains all the hidden, but powerful, request parameters that you can use when dealing with the SlingPostServlet. It includes the default handler for all POST requests that gives you endless options for creating, modifying, deleting, copying, and moving nodes in the repository.

Sling is Content Centric sling-is-content-centric

Sling is content-centric. This means that processing is focused on the content as each (HTTP) request is mapped onto content in the form of a JCR resource (a repository node):

RESTful Sling restful-sling

Due to the content-centric philosophy, Sling implements a REST-oriented server and thus features a new concept in web application frameworks. The advantages are:

URL Decomposition url-decomposition

In Sling, processing is driven by the URL of the user request. This defines the content to be displayed by the appropriate scripts. To do this, information is extracted from the URL.

If you analyze the following URL:

https://myhost/tools/spy.printable.a4.html/a/b?x=12

You can break it down into its composite parts:

protocol HTTP

host Name of the website.

content path Path specifying the content to be rendered. Used with the extension. In this example, they translate to tools/spy.html.

selectors Used for alternative methods of rendering the content; in this example a printer-friendly version in A4 format.

extension Content format; also specifies the script to be used for rendering.

suffix Can be used to specify additional information.

params Any parameters required for dynamic content.

From URL to Content and Scripts from-url-to-content-and-scripts

Using these principles:

The image below illustrates the mechanism used, which is discussed in more detail in the following sections.

With Sling, you specify which script renders a certain entity (by setting the sling:resourceType property in the JCR node). This mechanism offers more freedom than one in which the script accesses the data entities (as an SQL statement in a PHP script would do) as a resource can have several renditions.

Mapping requests to resources mapping-requests-to-resources

The request is broken down and the necessary information extracted. The repository is searched for the requested resource (content node):

Sling also allows things other than JCR nodes to be resources, but this is an advanced feature.

Locating the script locating-the-script

When the appropriate resource (content node) is located, the sling 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 can be either:

All Sling scripts are stored in subfolders of either /apps or /libs, which is searched in this order (see Customizing Components and Other Elements).

A few other points to note are:

The list of script engines supported by the given instance of AEM are listed on the Felix Management Console ( http://<host>:<port>/system/console/slingscripting).

Also, Apache Sling supports integration with other popular scripting engines (for example, Groovy, JRuby, Freemarker), and provides a way of integrating new scripting engines.

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

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 you have the following list of scripts in the correct location:

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

In addition to the resource types (primarily defined by the sling:resourceType property), there is also the resource super type. This is indicated by the sling:resourceSuperType property. These super types are also considered when trying to find a script. The advantage of resource super types is that they may form a hierarchy of resources where the default resource type sling/servlet/default (used by the default servlets) is effectively the root.

The resource super type of a resource may be defined in two ways:

For example:

The type hierarchy of:

This is because /y has the sling:resourceSuperType property whereas /x does not and therefore its supertype is taken from its resource type.

Sling Scripts cannot be called directly sling-scripts-cannot-be-called-directly

Within Sling, scripts cannot be called directly as this would break the strict concept of a REST server; you would mix resources and representations.

If you call the representation (the script) directly you hide the resource inside your script, so the framework (Sling) no longer knows about it. Thus you lose certain features:

Sling API sling-api

This uses the Sling API package, org.apache.sling.*, and tag libraries.

Referencing existing elements using sling:include referencing-existing-elements-using-sling-include

A final consideration is the need to reference existing elements within the scripts.

More complex scripts (aggregating scripts) must access multiple resources (navigation, sidebar, footer, elements of a list, for example) and do so by including the resource.

To do this, use the sling:include(“/<path>/<resource>”) command. This effectively includes the definition of the referenced resource, as in the following statement which references an existing definition for rendering images:

%><sling:include resourceType="geometrixx/components/image/img"/><%

OSGI osgi

OSGi defines an architecture for developing and deploying modular applications and libraries (it is also known as the Dynamic Module System for Java™). OSGi containers let you break your application into individual modules (which are jar files with additional meta information and called bundles in OSGi terminology) and manage the cross-dependencies between them with:

These services and contracts provide an architecture which enables individual elements to dynamically discover each other for collaboration.

An OSGi framework then offers you dynamic loading/unloading, configuration, and control of these bundles - without requiring restarts.

This architecture lets you extend Sling with application-specific modules. Sling, and therefore CQ5, uses the Apache Felix implementation of OSGI (Open Services Gateway initiative) and is based on the OSGi Service Platform Release 4 Version 4.2 Specifications. They are both collections of OSGi bundles running within an OSGi framework.

This enables you to perform the following actions on any of the packages within your installation:

See the Web Console, OSGI Configuration, and OSGi Configuration Settings for more information.

Development Objects in the AEM Environment development-objects-in-the-aem-environment

The following are of interest for development:

Item An item is either a node or a property.

For detailed information on manipulating Item objects, see the Java™ docs of the Interface javax.jcr.Item

Node (and their properties) Nodes and their properties are defined in the JCR API 2.0 specification (JSR 283). They store content, object definitions, rendering scripts and other data.

Nodes define the content structure, and their properties store the actual content and metadata.

Content nodes drive the rendering. Sling gets the content node from the incoming request. The property sling:resourceType of this node points to the Sling rendering component to be used.

A node, which is a JCR name, is also called a resource in the Sling environment.

For example, to get the properties of the current node, you can use the following code in your script:

PropertyIterator properties = currentNode.getProperties();

The currentNode being the current node object.

For more information on manipulating Node objects, see the Java™ docs.

Widget In AEM all user input is managed by widgets. These are often used to control the editing of a piece of content.

Dialogs are built by combining Widgets.

AEM has been developed using the ExtJS library of widgets.

Dialog A dialog is a special type of widget.

To edit content, AEM uses dialogs defined by the application developer. These combine a series of widgets to present the user with all fields and actions necessary to edit the related content.

Dialogs are also used for editing metadata, and by various administrative tools.

Component A software component is a system element offering a predefined service or event, and able to communicate with other components.

Within AEM, a component is often used to render the content of a resource. When the resource is a page, the component rendering it is called a Top-Level Component or a Page component. However, a component does not have to render content, nor be linked to a specific resource. For example, a navigation component displays information about multiple resources.

The definition of a component includes the following:

Template A template is the base for a specific type of page. When creating a page in the Websites tab, the user has to select a template. The new page is then created by copying this template.

A template is a hierarchy of nodes that has the same structure as the page to be created, but without any actual content.

It defines the page component used to render the page and the default content (primary top-level content). The content defines how it is rendered as AEM is content-centric.

Page Component (Top-Level Component) The component to be used to render the page.

Page A page is an ‘instance’ of a template.

A page has a hierarchy node of type cq:Page and a content node of type cq:PageContent. The property sling:resourceType of the content node points to the Page Component used for rendering the page.

For example, to get the name of the current page, you can use the following code in your script:

String pageName = currentPage.getName();

TcurrentPage being the current page object. For more information on manipulating Page objects, see the Java™ docs.

Page Manager The page manager is an Interface that provides methods for page level operations.

For example, to get the containing page of a resource, you can use the following code in your script:

Page myPage = pageManager.getContainingPage(myResource);

The pageManager being the page manager object, and myResource a resource object. For more information on the methods provided by the page manager, see the Java™ docs.

Structure within the Repository structure-within-the-repository

The following list gives an overview of the structure that you see within the repository.

Environments environments

With AEM, a production environment often consists of two different types of instances: an Author and a Publish instances.

The Dispatcher the-dispatcher

The Dispatcher is Adobe’s tool for both caching and/or load balancing. Further information can be found under the Dispatcher.

FileVault (source revision system) filevault-source-revision-system

FileVault provides your JCR repository with file system mapping and version control. It can be used to manage AEM development projects with full support for storing and versioning project code, content, configurations, and so on, in standard version control systems (for example, Subversion).

See the FileVault tool documentation for detailed information.

Workflows workflows

Your content is often subject to organizational processes, including steps such as approval and sign-off by various participants. These processes can be represented as workflows, defined and developed within AEM, then applied to the appropriate content pages or digital assets as required.

The Workflow Engine is used to manage the implementation of your workflows, and their subsequent application to your content.

Multi-Site Management multi-site-management

Multi Site Manager (MSM) enables you to easily manage multiple web sites that share common content. MSM lets you define relations between the sites so that content changes in one site are automatically replicated in other sites.

For example, web sites are often provided in multiple languages for international audiences. When the number of sites in the same language is low (three to five), a manual process for synchronizing content across sites is possible. However, when the number of sites grows or when multiple languages are involved, it becomes more efficient to automate the process.

For more information, see Multi Site Manager.