Components in AEM

In Adobe Experience Manager (AEM), components are the building blocks of web pages. They are modular, reusable units of code and content that allow authors to create and manage page content without needing technical knowledge.¹ Think of them like LEGO bricks, where each brick (component) has a specific function and can be assembled in various ways to build a complete structure (web page).

What is an AEM Component?

An AEM component is essentially a collection of scripts, configuration files, and often Java code (Sling Models) that collectively define:²

1. How content is rendered: The HTML output displayed on the web page.³

2. How content is authored: The user interface (dialog) that allows content authors to input and configure the component's content.⁴

3. How content is stored: The structure of the data in the JCR (Java Content Repository) that the component uses.

4. Any associated logic: Business logic, data fetching, or manipulation.

Key Characteristics of AEM Components:

• Modularity: Each component is a self-contained unit responsible for a specific piece of content or functionality (e.g., a text block, an image, a navigation menu, a carousel).⁵

• Reusability: Components can be used multiple times on the same page, across different pages, and even across different websites within the same AEM instance.⁶

• Authorability: They provide a user-friendly interface (dialogs) for content authors to easily add, edit, and configure content without writing code.⁷

• Separation of Concerns: A well-designed component separates the presentation (HTL), logic (Sling Model/Java), and content (JCR properties via dialog).

• Extensibility: Components can be extended or adapted from existing ones, promoting code reuse and consistency.⁸

• Templating: Components are used within AEM page templates (especially Editable Templates) to define the structure and allowed content areas of a page.⁹

Anatomy of an AEM Component:

A typical AEM component in a modern (Touch UI) setup consists of the following parts, usually residing under /apps/<your-project>/components/content/<component-name>:

1. Component Definition (.content.xml):

   • Located directly inside the component's folder (e.g., /apps/my-project/components/content/mycomponent/.content.xml).

   • Defines the basic properties of the component, such as:

     • jcr:primaryType="cq:Component": Identifies it as an AEM component.

     • jcr:title: The display name shown in the AEM Components browser.¹⁰

     • componentGroup: Groups components in the AEM UI for better organization.¹¹

     • sling:resourceSuperType: (Optional) Specifies a parent component from which this component inherits properties and rendering logic (crucial for extending Core Components).¹²

2. HTL Template (.html file):

   • The main rendering script for the component (e.g., /apps/my-project/components/content/mycomponent/mycomponent.html).

   • Written in HTML Template Language (HTL), which is AEM's preferred templating language.¹³

   • Responsible for generating the HTML markup that will be displayed on the web page.

   • Uses HTL expressions to access content properties (from JCR or Sling Models) and control flow (conditionals, loops).

3. Dialog (_cq_dialog/.content.xml):

   • Defines the authoring interface for the component (e.g., /apps/my-project/components/content/mycomponent/_cq_dialog/.content.xml).¹⁴

   • Uses Granite UI components (for Touch UI) to create form fields (text fields, image uploads, dropdowns, rich text editors, etc.).¹⁵

   • Each field in the dialog maps to a JCR property where the author's input will be stored on the component's content node.¹⁶

4. Sling Model (Java Class):

   • (Highly Recommended) A Java POJO (Plain Old Java Object) located in your project's core module (e.g., core/src/main/java/com/myproject/core/models/MyComponentModel.java).

   • Used to encapsulate business logic, retrieve data from the JCR, external services, or perform any necessary data manipulation before it's passed to the HTL template.

   • Annotated with @Model to be adaptable from a Sling Request or Resource.¹⁷

   • Provides methods that the HTL template can call to get processed data. This promotes clean separation of concerns.

5. Client Libraries (clientlibs folder):

   • Contains component-specific CSS and JavaScript (e.g., /apps/my-project/components/content/mycomponent/clientlibs/all.css, /apps/my-project/components/content/mycomponent/clientlibs/all.js).

   • Organized into cq:ClientLibraryFolder nodes with categories, allowing them to be included efficiently on pages.¹⁸

6. Edit Configuration (_cq_editConfig.xml):

   • (Optional but useful) Defines how the component behaves in the AEM editor (e.g., /apps/my-project/components/content/mycomponent/_cq_editConfig.xml).¹⁹

   • Can configure:

     • Listeners: Actions to be triggered on specific events (e.g., afteredit to refresh the component after dialog submission).²⁰

     • Drag & Drop: Rules for dropping assets (like images) onto the component.²¹

     • In-place Editing: Enabling direct editing of text on the page without opening a dialog.

Content Component vs. Design Component:

It's important to differentiate between the primary dialog (_cq_dialog) and the design dialog (_cq_design_dialog):

• Content Dialog (_cq_dialog):

  • Used by content authors to edit the content and functional properties specific to a particular instance of the component on a page.

  • The data entered here is stored on the page's content node in the JCR.

• Design Dialog (_cq_design_dialog):

  • Used by template authors (in Design Mode) to define design-related configurations for a component that apply globally to all instances of that component based on a specific template.²²

  • Examples: Allowed image sizes, default text styles, specific styling options that can be applied to a component.²³

  • The data entered here is stored in the content policies associated with the page template (under /conf).

Core Components:

Adobe provides a set of AEM Core Components which are highly optimized, flexible, and robust components that serve as a strong foundation for most AEM projects.²⁴ They are built following best practices, are fully responsive, and highly extensible.²⁵ It's highly recommended to use and extend Core Components rather than building every component from scratch.

In essence, AEM components are the backbone of content authoring, providing a powerful and flexible system for building and managing rich web experiences.²⁶