Core component in AEM

 

Core component in AEM

In AEM, components are elements that are used to create the pages in AEM.

 

Core components come by default with AEM, located at: /apps/core/components

Latest versions of core components can be downloaded from Github repository anytime.

 

Components have always been a fundamental element of the AEM. It makes page creation simple and powerful for the author and the development of components - flexible and extensible for the developers.

 

Core Components were introduced by Adobe to provide robust and extensible base components, built on the latest technology and best practices, and adhering to accessibility guidelines.

 

Core components make page authoring more flexible and customizable, and extending them to offer custom functionality is simple for the developers.

 

Developers can use core components directly on the pages or can be customized as per need.

 

The latest version of core components provides below components with advanced features:

1.     Accordion

2.     Breadcrumb

3.     Button

4.     Container

5.     Carousel

6.     Content Fragment

7.     Content Fragment List

8.     Download

9.     Embed

10.Experience Fragment

11.Form Button

12.Form Container

13.Form Hidden

14.Form Options

15.Form Text

16.Image

17.Language Navigation

18.List

19.Navigation

20.Page

21.Quick Search

22.Separator

23.Social Media Sharing

24.Tabs

25.Text

26.Title

 

Note: Core components can be made available and pre-configured via the template editor for that poject.

 

You can view and see usage of component through component library at below URL:

https://www.aemcomponents.dev/

 

The current release of the Core Components is 2.8.0 and is compatible with AEM as a Cloud Service and on-premise AEM installations. It was released in December 2019.

It introduced new components along with v2 updates of existing components.

Extending Component in your Project

When extending or customing an existing component or dialog, you can copy or replicate either the entire structure or the structure required for the dialog before making your changes.

 

It is also possible to override a component dialog using the property sling:resourceSuperType.

 

This means you only need to redefine the required differences, as opposed to redefining the entire dialog (using sling:resourceSuperType). This is now recommended method for extending a component dialog.

 

Configuring the Edit Behavior

You can configure the edit behavior of a component including attributes such as:

1.     Actions available for the component,

2.     characteristics of the inplace editor,

3.     The listeners related to events on the component.

 

The configuration is common to both the touch-enabled and classic UI, with certain, specific differences.

 

The edit behavior of a component is configured by adding a cq:editConfig node of type cq:EditConfig below the component node (of type cq:Component) and by adding specific properties and child nodes.

 

Creating and Configuring a Dialog

Dialogs are used to allow author to interact with the component. Using a dialog allows authors and/or administrators to edit content, configure the component or define design parameters (using a Design Dialog).

 

·        Dialogs for the touch-enabled UI are named cq:dialog.

·        They are defined as an nt:unstructured node with the sling:resourceType property set.

·        They are located under their cq:Component node and next to their component definition.

·        They are rendered on the server-side (as Sling components), based on their content structure and the sling:resourceType property.

·        They use the Granite UI framework.

 

Creating and Configuring a Design Dialog

The Design dialog is provided when a component has design details that can be edited in Design Mode.

The definition is very similar to that of a dialog used for editing content, with the difference that it is defined as a node:

Node name: cq:design_dialog

Type: nt:unstructured

 

Migrating from a Classic Component

When migrating a component that was designed for use with the classic UI to a component that can be used with the touch-enabled UI the following issues should be considered:

Note:

·        Use of HTL is not compulsory, but if your component needs updating then migrate them from JSP to HTL.

·        Migrate cq:listener code that use classic UI specific functions

·        You will need to create a new dialog for use in the touch-enabled UI.

 

When to Use the Core Components?

As the Core Components offer multiple benefits, it is recommended for new AEM projects to use them.

For existing projects, a migration should be part of a larger project effort, overall refactoring.

Adobe provides following recommendations:

New Projects: New projects should always attempt to use Core Components. If Core Components cannot be used directly or extended to satisfy project requirements, then create a custom component following from core components but avoid using the foundation components .

Existing Projects: Recommendation is keep using the foundation components , unless a site or component refactoring is planned. As they are very widely used by most existing projects, the foundation components will continue to be supported.

New Custom Components: If an existing Core Component may be customized . If not, recommendation is to build a new custom component following the Component Guidelines provided by AEM.

Existing Custom Components: If your components work as expected, then keep them as they are. If not, create "New Custom Components".