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 .