Components in AEM

Components in AEM

 

AEM has provided the foundation components and core components for development

Paths for foundation components are:

 

JSP: /libs/foundation/components (Deprecated)

HTL: /libs/wcm/foundation/components (Deprecated)

 

However, both are deprecated and Adobe has clearly mentioned the deprecated reason

Go to,

/libs/foundation/components/text (JSP) with text.jsp    

Now Go to,

/libs/wcm/foundation/components/text (HTL) with text.html

Adobe recommends using Core Components which are available at /apps/core/

Go to,

/apps/core/wcm/components/text/v2/text (V2-Latest) of Text Core Component

 Core components are built on the latest technology and best practices.

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

Note:

Core Components require AEM 6.3 and above and require the use of editable templates.

They do not work with the Classic UI nor with static templates.

The Core Components are by default part of a hidden group and are not visible within the component browser.

Benefits of using Core Components:

• ·        Pre-Configurable
• ·        Versatile
• ·        Easy-to-Use
• ·        Production-Ready
• ·        Easy to Style
• ·        Extensible
• ·        SPA/App Ready
• ·        Open Source
• ·        Versioned

 

Difference between Core components and foundation Components:

 Migration Guide to Coral UI3 from Coral UI2 Components

 

In AEM, we have two sets of Granite UI components based on Coral UI2 and Coral UI3, below are the differences mentioned as per Adobe documentation:

 

Coral UI2 Components Path	/libs/granite/ui/components/foundation/*
Coral UI3 Components Path	/libs/granite/ui/components/coral/foundation/*
Coral UI2 Clientlibs	granite.ui.foundation, granite.ui.foundation.admin, coralui2
Coral UI3 Clientlibs	granite.ui.coral.foundation, coralui3

 

The new set will not be just a copy-paste of the old set, rather they are more cleaned up (e.g. streamlining, removing deprecated feature)

It is recommended that a page only use either CoralUI 3-based or CoralUI 2-based set (i.e. not mixed)

 

Some Example of replacements:

 

1.     While creating touch UI dialog, we create a node named "layout"

 

Coral UI 2: granite/ui/components/foundation/layouts/tabs.

Coral UI 3: granite/ui/components/coral/foundation/tabs.

 

2.     Section component has been replaced with container component

 

Coral UI 2: granite/ui/components/foundation/section (use to define for each of the tabs)

Coral UI 3: granite/ui/components/coral/foundation/container

  

3.     Text Component

 

Coral UI 2: /libs/granite/ui/components/foundation/textfield/render.jsp

Coral UI 3: /libs/granite/ui/components/coral/foundation/textfield/render.jsp

 

When migrating a component from classic UI to touch-enabled UI (either solely or jointly) the following issues should be considered:

 

HTL

Use of HTL is not compulsory, but if your component needs updating then it is an ideal time to consider migrating from JSP to HTL.

 

Components

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

    ·        RTE plugin, for text component.

 

Dialogs

You will need to create a new dialog for use in the touch-enabled UI. However, for compatibility purposes the touch-enabled UI can use the definition of a classic UI dialog, when no dialog has been defined for the touch-enabled UI.

 ·        The Dialog Conversion Tool is provided to help you extend existing components.

 ·        Mapping ExtJS to Granite UI Components provides a convenient overview of ExtJS xtypes and node types with their equivalent Granite UI resource types.

 ·        Customizing fields

 ·        Migrate from vtypes to Granite UI validation

 ·        Using JS listeners, for more information see Handling Field Events and the AEM Gems session on Customizing Dialog Fields .

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