AEM 6.3: Developing with the new Core Components

The new AEM 6.3 brings with it the WCM Core Components Library, a set of reusable and production ready components. Learn how to take advantage of them.

In the last couple of years developing components for AEM has become more accesible. We got HTL (formerly Sightly) and Sling models, and TouchUI became more mature and stable. Still, when it was time to get your hands dirty it was difficult to find good examples of how things should be implemented. Geometrixx (and their spin-offs like outdoors or media) had been for very long time the standard reference of how components should be implemented.

Unfortunately, as you might know, Geometrixx in many cases was more an example of how you should NOT do things rather than how to do them. Luckily for us, AEM 6.3 brings in the Adobe WCM Core Components and a new implementation of the We.Retail demo site, which will serve as an actual showcase of good component development practices. As a side note, Geometrixx has been completely removed on AEM 6.3.

What are Core Components?

The Adobe WCM Core Components are a set of basic but feature complete components developed by Adobe that are meant to be easily reused and expanded upon for AEM projects. Some advantages are:

Note about deployment: The Core Components are not part of the AEM 6.3 installation, but you might find them installed since they are part of the We.Retail packages. If you use the production-ready "nosamplecontent" runmode they will not be installed. I recommend deploying them along your project packages.

I'm not going to go deep into which exact components are available since you can just go the project and check out yourself. Instead, I will give a short introduction of how they can be used in your projects.

Example: simple extension

Let's create a small requirement and see how we can use the Core Components. Let's start with a component that allows the editor to create titles for sections of a web page. The title text should be editable by the author and should always use the H1 HTML Tag.

Choose a component to extend

In our case this is very straight forward, there is a Title component that has features very similar to what we need. The component by default allows you to choose the type of tag that will be used to render the title. We need to eliminate this possibility.

First of all, as with other provided components like the ones on AEM foundation, you should not rely directly on them. That means that editors will not directly drag and drop the Core Components into pages. Instead, you should create new components that extend the Core Components and modify whatever you need (if needed). This is nothing new and has been a standard good practice for a long time.

Create the new component

Modify behaviour

Now the fun part begins. We need to remove functionality instead of adding it or modifying, so it should be straight forward.

First thing we should do is to adapt the dialog. Fortunately, the Sling Resource Merger is completely leveraged so we can use it to hide part of the original dialog:


As you can see this was incredibly simple.

Example 2: some backend changes

After using your component for a while, your client tells you that the feature in which the page title is used by default in the component is no good for them. Instead, they want it to show the navigation title by default and the page title as a fallback and the title as a final fallback for both.

This will require us to implement a new backend for our component.

If you examine the title.html file, you'll see that it imports com.adobe.cq.wcm.core.components.models.Title. This is actually an interface, not an implementation. The actual implementation is not exported by the Core Components bundle, but since it is open source, we can have a look at it.

Let's create our own implementation of the Title interface.

Disclaimer: These instructions assume you are able to create, compile and deploy an OSGi bundle. If you do not know how to do this, find out and come back when you do.

Firstly, we should create in a bundle a new implementation of the Title Interface. It has only two methods, so it is straight forward. The interesting part comes in the @Model annotation. In Sling Models 1.3.0 (included in AEM 6.3) it is possible to define precisely to which resource types our implementation should be bound to. See this demo implementation:


@Model(adaptables=SlingHttpServletRequest.class,adapters=Title.class ,resourceType="netcentric/example/components/title")
public class CustomTitle implements Title {


Take a close look at the @Model annotation. The type parameter allows us to define the interface from which the model should be adapted, and the resourceType parameter allows us to bind our implementation to a specific component type. That way our implementation will not interfere with other components expanding on the core Title component.

Compile and deploy your bundle. Now your custom backend Title should be preferred over the default one.


We have briefly examined how the new Adobe Core Components allow us to easily expand them and modify them as needed. We have very easily created customizations both in the backend and the frontend of the component thanks to HTL, the Sling Resource Merger and Sling Models.