In AEM 6.3 Core Components were introduced to provide robust and extensible base components, built on the latest technology and best practices. Core components make page authoring more flexible and customisable and the extending them is simple for the developer to offer custom functionality.
Versions and Releases
Core Components are distributed via GitHub. This will allow Adobe to more quickly add functionality to the components and also allow for community input.
In the past, the Foundation Components were tied to a specific version of AEM. Going forward, the Core Components will be made available with defined AEM versions with which they are compatible. Therefore one AEM version may support multiple versions or releases of the Core Components.
Versions
The major iteration of the Core Components are the versions. Versions are denoted with a nonzero, positive integer and introduce new components, features to existing components, and additional new functionality.
Developers and administrators can recognise versions of the core components via by a number in their resource type path, and in the fully qualified Java class names of their implementations. This version number represents a major version as defined by semantic versioning guidelines, which is incremented only for changes that are not backward-compatible.
For more details about core component versions, see the developer documentation of the Core Components.
Releases
The minor iteration of the Core Components are the releases. Releases are denoted with two nonzero, positive decimals appended to the version number. Releases represent the actual published artifacts available on GitHub and contain mostly bug fixes and improvements with occasional new features.
A version can have multiple releases.
Compatibility
The following table provides an overview of the currently available and supported AEM versions and Core Components releases and their mutual compatibility.
AEM VersionCore Components v1
Release 1.0.0 – 1.0.6 Core Components v1
Release 1.1.0
AEM 6.1 Not Compatible Not Compatible
AEM 6.2 Not Compatible Not Compatible
AEM 6.3 Compatible Compatible*
Note:
* Using release 1.1.0 with AEM 6.3 requires feature packs to enable certain content services functionality
Feature pack 19614 is required for content fragment functionality
Feature pack 19008 is required for JSON export functionality
See the content services feature pack documentation for details.
Note:
Adobe recommends that developers use the latest release of the Core Components available to benefit from the most up-to-date fixes and features.
Note:
Core components are not immediately available to authors, the development team must first integrate them to your environment. Once integrated, they may be made available and pre-configured via the template editor or in design mode.
When to Use Core Components
As the Core Components are all-new for 6.3, and 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, for example a rebranding or overall refactoring.
Therefore, Adobe provides following recommendations:
New Projects
Use the Core Components wherever they match the needs of the project, or optionally extend them.
Except for the various Layout Containers and Paragraph Systems, don’t use 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
Assess if an existing Core Component may be customized.
If not, recommendation is to build a new custom component following the Component Guidelines.
Existing Custom Components
If your components work as expected, then keep them as they are.
If not, refer to “New Custom Components” above.
Core Components Support
Core Components are an integral part of AEM and supported as is, under the same terms and conditions as if they were delivered as part of the Quickstart.
Like other product features, the general rule of end-of-life is:
Components are first announced to be deprecated before being removed
At the earliest they are then removed from the AEM release following the announcement. This gives customers at least one release cycle to move to the new version of the component, before support ends.
The version of each component clearly states the AEM versions that it supports. When support ceases for a version of AEM, then so does the support of the Core Components for that version of AEM.
For details about the support of component customisations, see the Customizing Core Components page of the relevant Core Components Version.
Foundation Component Support
Since the Foundation Components have served as a basis of so much project development over many versions, they will continue to be supported into the foreseeable future.
However, Adobe’s development emphasis has shifted to the Core Components and new features will be added to them whereas only bug fixes will be made to the Foundation Components
Version 1 was the first version of the Core Components with an initial compatibility with AEM 6.3. Version 1 introduced the basic components essential to page composition including:
Page
Title
Text
Image
List
Breadcrumb
Sharing
Form Container
Form Text Input
Form Options
Form Hidden Field
Form Button Release 1.1.0 of the Core Components also introduced a new component to display content fragments as well as enabled JSON export for the existing components.
Content Fragment
The We.Retail reference site illustrates how the core components can be used.
Authoring with Core Components
In Adobe Experience Manager, components are the structural elements that constitute the content of the pages being authored. This section covers the core components, which provide essential content types to create pages.
The core components have been introduced with AEM 6.3 and offer flexible and feature-rich authoring functionality. The We.Retail reference site illustrates how the core components can be used.
Note:
Core components are not immediately available to authors, the development team must first integrate them to your environment. Once integrated, they may be made available and pre-configured via the template editor or in design mode.
Caution:
Core components require AEM 6.3 and do not work with the Classic UI.
Authoring with the core components does not differ substantially from the foundation components.
However, as an author, you will notice several advantages of the core components, including:
Simple to use and well-integrated with the page editor
Feature-rich capabilities to accomodate many use cases as illustrated in We.Retail
Pre-configurable to define which features are available to page authors
Via the teamplate editor for editable templates
Via design mode for static templates
Built around accessibility guidelines
Built to support responsive layout
The components are available on the Components tab of the side panel of the page editor when editing a page.
Components are grouped according to categories called component groups to easily organize and filter the components. The component group name is displayed with the component in the component browser and it is also possible to filter by group to easily find the right component.
Pre-Configuring Core Components
Configuring foundation components was the job of a developer. However with core components, a template author can now configure a number of capabilities via the template editor or in design mode.
For example if an image component should not allow image upload from the file system, or if a text component should only allow certain paragraph formatting, these features can be enabled or disabled with a simple click.
See Creating Page Templates for more information.
Edit and Design Dialogs
Because the core components can be pre-configured by template authors to define what options are allowed as part of a template, and then further configured by the page author to define actual page conent, each component can have options in two different dialogs.
* Using release 1.1.0 with AEM 6.3 requires feature packs to enable certain content services functionality
Feature pack 19614 is required for content fragment functionality
Feature pack 19008 is required for JSON export functionality
See the content services feature pack documentation for details.
Note:
Adobe recommends that developers use the latest release of the Core Components available to benefit from the most up-to-date fixes and features.
Note:
Core components are not immediately available to authors, the development team must first integrate them to your environment. Once integrated, they may be made available and pre-configured via the template editor or in design mode.
When to Use Core Components
As the Core Components are all-new for 6.3, and 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, for example a rebranding or overall refactoring.
Therefore, Adobe provides following recommendations:
New Projects
Use the Core Components wherever they match the needs of the project, or optionally extend them.
Except for the various Layout Containers and Paragraph Systems, don’t use 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
Assess if an existing Core Component may be customized.
If not, recommendation is to build a new custom component following the Component Guidelines.
Existing Custom Components
If your components work as expected, then keep them as they are.
If not, refer to “New Custom Components” above.
Core Components Support
Core Components are an integral part of AEM and supported as is, under the same terms and conditions as if they were delivered as part of the Quickstart.
Like other product features, the general rule of end-of-life is:
Components are first announced to be deprecated before being removed
At the earliest they are then removed from the AEM release following the announcement. This gives customers at least one release cycle to move to the new version of the component, before support ends.
The version of each component clearly states the AEM versions that it supports. When support ceases for a version of AEM, then so does the support of the Core Components for that version of AEM.
For details about the support of component customisations, see the Customizing Core Components page of the relevant Core Components Version.
Foundation Component Support
Since the Foundation Components have served as a basis of so much project development over many versions, they will continue to be supported into the foreseeable future.
However, Adobe’s development emphasis has shifted to the Core Components and new features will be added to them whereas only bug fixes will be made to the Foundation Components
Version 1 was the first version of the Core Components with an initial compatibility with AEM 6.3. Version 1 introduced the basic components essential to page composition including:
Page
Title
Text
Image
List
Breadcrumb
Sharing
Form Container
Form Text Input
Form Options
Form Hidden Field
Form Button Release 1.1.0 of the Core Components also introduced a new component to display content fragments as well as enabled JSON export for the existing components.
Content Fragment
The We.Retail reference site illustrates how the core components can be used.
Authoring with Core Components
In Adobe Experience Manager, components are the structural elements that constitute the content of the pages being authored. This section covers the core components, which provide essential content types to create pages.
The core components have been introduced with AEM 6.3 and offer flexible and feature-rich authoring functionality. The We.Retail reference site illustrates how the core components can be used.
Note:
Core components are not immediately available to authors, the development team must first integrate them to your environment. Once integrated, they may be made available and pre-configured via the template editor or in design mode.
Caution:
Core components require AEM 6.3 and do not work with the Classic UI.
Authoring with the core components does not differ substantially from the foundation components.
However, as an author, you will notice several advantages of the core components, including:
Simple to use and well-integrated with the page editor
Feature-rich capabilities to accomodate many use cases as illustrated in We.Retail
Pre-configurable to define which features are available to page authors
Via the teamplate editor for editable templates
Via design mode for static templates
Built around accessibility guidelines
Built to support responsive layout
The components are available on the Components tab of the side panel of the page editor when editing a page.
Components are grouped according to categories called component groups to easily organize and filter the components. The component group name is displayed with the component in the component browser and it is also possible to filter by group to easily find the right component.
Pre-Configuring Core Components
Configuring foundation components was the job of a developer. However with core components, a template author can now configure a number of capabilities via the template editor or in design mode.
For example if an image component should not allow image upload from the file system, or if a text component should only allow certain paragraph formatting, these features can be enabled or disabled with a simple click.
See Creating Page Templates for more information.
Edit and Design Dialogs
Because the core components can be pre-configured by template authors to define what options are allowed as part of a template, and then further configured by the page author to define actual page conent, each component can have options in two different dialogs.
List of Core Components Available
The following is a list of the available core components linked to pages describing their edit and design dialog capabilities in detail.
Form ButtonRelease 1.1.0 of the Core Components also introduced a new component to display content fragments as well as enabled JSON export for the existing components.
Content Fragment
Note:
Depending on your instance you may have customized components developed explicitly for your requirements. These may even have the same name as some of the components discussed here.
Note:
The form core components are not related to AEM Forms.
Page Component
The Page Component is an extensible page component designed to work with the template editor and allow page header/footer and structure components to be assembled with the template editor.
Usage
The page component forms the basis of all pages designed with the core components as well as editable templates. By using the page component, headers, footers, and the structure of the page can be defined as a template using the other core components.
Using the design dialog, custom client-side libraries can be defined for the page. Unlike other components which have an edit dialog accessible directly from the component, because the component is the page itself, the edit dialog of the page component is the page properties window.
Title Component
The Core Component Title Component is a section heading component that features in-place editing.
Usage
The title component is intended to be used as the title or heading of a section of content. The available heading levels can be defined by the template author in the design dialog. The content editor can select from available headings levels in the edit dialog. For added convenience, simple in-place editing of the heading text is also available.
Text Component
The Text Component is a rich text editing and composing component that features in-place editing.
Usage
The text component offers a robust rich text editor that allows for easy text editing in a simplified, in-line editor as well as a full screen format.
The edit dialog features in-line editing with limited options with full functionality available in the full-screen edit dialog. Using the design dialog, text formatting options such as headings, special characters, and paragraph styles can be configured for the template for the content author.
Image Component
The Core Component Image Component is an adaptive image component features in-place editing.
Usage
The image component allows easy placement of image assets and offers in-place editing. It features adaptive image selection with lazy loading as well as cropping for the content author. The allowed image widths as well as cropping and additional settings can be defined by the template author in the design dialog. The content editor can upload or select assets in the configure dialog and crop the image in the edit dialog. For added convenience, simple in-place modification of the image is also available.
List Component
The Core Component List Component allows for the easy creation of dynamic as well as static lists.
Usage
The list component can be used to create for example a dynamic list of child pages or a static list of arbitrarily defined items. The type of lists available and formatting options can be defined by the template author in the design dialog. The content editor can select from available list types and how to format the list elements in the edit dialog.
Breadcrumb Component
The Core Component Breadcrumb Component is a navigation component that builds a breadcrumb of links based on the page’s location in the content hierarchy.
Usage
The breadcrumb component displays the position of the current page within the site hierarchy, allowing page visitors to navigate the page hierarchy from their current location. This is often integrated into page headers or footers. Available options such as the default navigation level and the ability to show the current page or hidden pages can defined by the template author in the design dialog. The content editor can then choose if hidden pages should be shown or not and the actual navigation level for hte component in the edit dialog.
Sharing Component
The Core Component Sharing Component is a Facebook and Pinterest sharing widget.
Usage
The sharing component adds Facebook and Pinterest sharing links to the page. It is often included in page headers or footers. Unlike other components, the settings for the sharing component is done by the template author via Intial Page properties and by the content author via Page Properties.
Form Container Component
The Core Component Form Container Component allows for the creation of simple submission forms.
Usage
The form container component enabled the building of simple information submission forms and features by supporting simple WCM forms and by using a nested structure to allow additional form components. By using the setting dialog the content editor can define what type of action form submission triggers, where the submitted content should be stored, and if a workflow should be triggered. The template author can use the design dialog to define the allow components and their mappings similar to the design dialog for the standard layout container in the template editor.
Form Text Component
The Core Component Form Text component allows the entry of form text for submission.
Usage
The form text component allows for the submission of different types of text and is intended to be used along with the form container component. The type of text validation, labels, and help messages can be defined by the content editor in the configure dialog.
Form Options Component
The Core Component Form options component allows for the selection from pre-defined options in various formats.
Usage
The core component form options component allows for the submission of different types of options presented in many different ways and is intended to be used along with the form container component. The presentation of the options, labels, and individual options can be defined by the content editor in the configure dialog.
Form Hidden Component
The Core Component Form Hidden component allows for the display of a hidden field.
Usage
The core component form hidden component allows for the creation of hidden fields to pass information about the current page back to AEM and is intended to be used along with the form container component. The field properties can be defined by the content editor in the configure dialog.
Form Button Component
The Core Component Form Hidden component allows for the inclusion of a hidden field in a form.
Usage
The core component form button component allows for the creation of button field, often to trigger the submission of the field and is intended to be used along with the form container component. The button properties can be defined by the content editor in the configure dialog.
Developing Core Components
The core components have been released for AEM version 6.3. They provide robust and extensible base components, and their highlights are:
Feature-rich capabilities
Flexible configuration options to accommodate many use cases
Pre-configurable capabilities to define which features are available to page authors
Continuous delivery
Frequent incremental functionality improvements
Availability of the source code on GitHub to allow the developer community to give feedback and contribute
Installation through a separately released content package for component upgrades to be done independently from AEM upgrades
Component versioning
Ensure compatibility within a version, yet allow the components to evolve
Allow multiple versions of one component to coexist on the same environment
Modern implementation
Markup defined in HTML Template Language (HTL)
Content model logic implemented with Sling Models
Lean markup
Following the Bootstrap naming conventions
Built around accessibility guidelines
Capable to be used for responsive and mobile sites
Capability to serialize as JSON the content model for headless CMS use cases
Caution:
Core Components require AEM 6.3 and Java 8.
Core Components do not work with the Classic UI.
Delivered over GitHub
The Core Components are developed in and delivered through GitHub.
CODE ON GITHUB
You can find the code of this page on GitHub
Open aem-core-wcm-components project on GitHub
Download the project as a ZIP file
See the Using Core Components documentation page to learn how to get started using them in your project.
Having the Core Components on GitHub will allow to do frequent updates, and to listen to the feedback from the AEM developer community. Also, this should help customers and partners to follow similar patterns when building custom components.
Sample Content Run-Mode
The Core Components are visible in the Quickstart when the sample content is present, because the We.Retail reference site uses them. However, when running in production (in nosamplecontent runmode, without sample content enabled), the core components won’t be present anymore and must be installed on the AEM instances by the development and/or operations team.
Note:
In production environments, always run the Quickstart in nosamplecontent runmode. To use the Core Components in nosamplecontent runmode, follow the instructions of the Using Core Components documentation page.
Technical Capabilities
The following table gives an overview of the differences between core components and foundation components.
For details about their authoring capabilities and options to pre-configurable them, refer to the authoring page about them.
Component List
The following table lists the available Core Components, linking to their API, and indicates which foundation components they replace.
Upcoming components
Following core components are being actively worked on. They haven’t been released yet, but can be previewed in the development branch:
Navigation – a site navigation component that lists the nested page hierarchy
Language Navigation – a language and country switcher that lists the global language structure
Quick Search – a search component that displays the results as real-time suggestions in a drop-down menu
Teaser – a component to link to a different page with a preview image, title and description
Also, a styling capability is in the works, which will be released as a feature pack for 6.3, and will be implemented by all the core components. This will allow to define on the template different styles for each component, which the authors can then apply to the component instances. A very first tech preview of that feature is available through cq-6.3.0-featurepack-18678.
Upgrade of Core Components
One benefit of versioned components is that it allows to separate the migration to a new AEM version from the migration to new component versions. Also, if new component versions are available, it allows for the individual migration of each component to the new version.
Migrations to a new AEM version won’t impact how the Core Components work, provided that their versions also support the new AEM version that is being migrated to. Customizations made to the Core Components should not be affected either, as long as they don’t use APIs that have been deprecated or removed.
Migrations to new versions of the Core Components won’t impact how the component works either, but new features might be introduced to page authors, which might require some configuration by a template editor, in case the default behavior isn’t desired. Customizations however might need to be adapted, for more details see the Customizing Core Components page.
When to Use the Core Components?
As the Core Components are all-new for 6.3, and 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, for example a rebranding or overall refactoring.
Therefore, Adobe provides following recommendations:
New Projects
Use the Core Components wherever they match the needs of the project, or optionally extend them.
Except for the various Layout Containers and Paragraph Systems, don’t use 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
Assess if an existing Core Component may be customized.
If not, recommendation is to build a new custom component following the Component Guidelines.
Existing Custom Components
If your components work as expected, then keep them as they are.
If not, refer to “New Custom Components” above.Core Component Support
Core Components are an integral part of AEM and supported as is, under the same terms and conditions as if they were delivered as part of the Quickstart.
Title Component
The Core Component Title Component is a section heading component that features in-place editing.
Usage
The title component is intended to be used as the title or heading of a section of content. The available heading levels can be defined by the template author in the design dialog. The content editor can select from available headings levels in the edit dialog. For added convenience, simple in-place editing of the heading text is also available.
Text Component
The Text Component is a rich text editing and composing component that features in-place editing.
Usage
The text component offers a robust rich text editor that allows for easy text editing in a simplified, in-line editor as well as a full screen format.
The edit dialog features in-line editing with limited options with full functionality available in the full-screen edit dialog. Using the design dialog, text formatting options such as headings, special characters, and paragraph styles can be configured for the template for the content author.
Image Component
The Core Component Image Component is an adaptive image component features in-place editing.
Usage
The image component allows easy placement of image assets and offers in-place editing. It features adaptive image selection with lazy loading as well as cropping for the content author. The allowed image widths as well as cropping and additional settings can be defined by the template author in the design dialog. The content editor can upload or select assets in the configure dialog and crop the image in the edit dialog. For added convenience, simple in-place modification of the image is also available.
List Component
The Core Component List Component allows for the easy creation of dynamic as well as static lists.
Usage
The list component can be used to create for example a dynamic list of child pages or a static list of arbitrarily defined items. The type of lists available and formatting options can be defined by the template author in the design dialog. The content editor can select from available list types and how to format the list elements in the edit dialog.
Breadcrumb Component
The Core Component Breadcrumb Component is a navigation component that builds a breadcrumb of links based on the page’s location in the content hierarchy.
Usage
The breadcrumb component displays the position of the current page within the site hierarchy, allowing page visitors to navigate the page hierarchy from their current location. This is often integrated into page headers or footers. Available options such as the default navigation level and the ability to show the current page or hidden pages can defined by the template author in the design dialog. The content editor can then choose if hidden pages should be shown or not and the actual navigation level for hte component in the edit dialog.
Sharing Component
The Core Component Sharing Component is a Facebook and Pinterest sharing widget.
Usage
The sharing component adds Facebook and Pinterest sharing links to the page. It is often included in page headers or footers. Unlike other components, the settings for the sharing component is done by the template author via Intial Page properties and by the content author via Page Properties.
Form Container Component
The Core Component Form Container Component allows for the creation of simple submission forms.
Usage
The form container component enabled the building of simple information submission forms and features by supporting simple WCM forms and by using a nested structure to allow additional form components. By using the setting dialog the content editor can define what type of action form submission triggers, where the submitted content should be stored, and if a workflow should be triggered. The template author can use the design dialog to define the allow components and their mappings similar to the design dialog for the standard layout container in the template editor.
Form Text Component
The Core Component Form Text component allows the entry of form text for submission.
Usage
The form text component allows for the submission of different types of text and is intended to be used along with the form container component. The type of text validation, labels, and help messages can be defined by the content editor in the configure dialog.
Form Options Component
The Core Component Form options component allows for the selection from pre-defined options in various formats.
Usage
The core component form options component allows for the submission of different types of options presented in many different ways and is intended to be used along with the form container component. The presentation of the options, labels, and individual options can be defined by the content editor in the configure dialog.
Form Hidden Component
The Core Component Form Hidden component allows for the display of a hidden field.
Usage
The core component form hidden component allows for the creation of hidden fields to pass information about the current page back to AEM and is intended to be used along with the form container component. The field properties can be defined by the content editor in the configure dialog.
Form Button Component
The Core Component Form Hidden component allows for the inclusion of a hidden field in a form.
Usage
The core component form button component allows for the creation of button field, often to trigger the submission of the field and is intended to be used along with the form container component. The button properties can be defined by the content editor in the configure dialog.
Developing Core Components
The core components have been released for AEM version 6.3. They provide robust and extensible base components, and their highlights are:
Feature-rich capabilities
Flexible configuration options to accommodate many use cases
Pre-configurable capabilities to define which features are available to page authors
Continuous delivery
Frequent incremental functionality improvements
Availability of the source code on GitHub to allow the developer community to give feedback and contribute
Installation through a separately released content package for component upgrades to be done independently from AEM upgrades
Component versioning
Ensure compatibility within a version, yet allow the components to evolve
Allow multiple versions of one component to coexist on the same environment
Modern implementation
Markup defined in HTML Template Language (HTL)
Content model logic implemented with Sling Models
Lean markup
Following the Bootstrap naming conventions
Built around accessibility guidelines
Capable to be used for responsive and mobile sites
Capability to serialize as JSON the content model for headless CMS use cases
Caution:
Core Components require AEM 6.3 and Java 8.
Core Components do not work with the Classic UI.
Delivered over GitHub
The Core Components are developed in and delivered through GitHub.
CODE ON GITHUB
You can find the code of this page on GitHub
Open aem-core-wcm-components project on GitHub
Download the project as a ZIP file
See the Using Core Components documentation page to learn how to get started using them in your project.
Having the Core Components on GitHub will allow to do frequent updates, and to listen to the feedback from the AEM developer community. Also, this should help customers and partners to follow similar patterns when building custom components.
Sample Content Run-Mode
The Core Components are visible in the Quickstart when the sample content is present, because the We.Retail reference site uses them. However, when running in production (in nosamplecontent runmode, without sample content enabled), the core components won’t be present anymore and must be installed on the AEM instances by the development and/or operations team.
Note:
In production environments, always run the Quickstart in nosamplecontent runmode. To use the Core Components in nosamplecontent runmode, follow the instructions of the Using Core Components documentation page.
Technical Capabilities
The following table gives an overview of the differences between core components and foundation components.
For details about their authoring capabilities and options to pre-configurable them, refer to the authoring page about them.
Component List
The following table lists the available Core Components, linking to their API, and indicates which foundation components they replace.
Upcoming components
Following core components are being actively worked on. They haven’t been released yet, but can be previewed in the development branch:
Navigation – a site navigation component that lists the nested page hierarchy
Language Navigation – a language and country switcher that lists the global language structure
Quick Search – a search component that displays the results as real-time suggestions in a drop-down menu
Teaser – a component to link to a different page with a preview image, title and description
Also, a styling capability is in the works, which will be released as a feature pack for 6.3, and will be implemented by all the core components. This will allow to define on the template different styles for each component, which the authors can then apply to the component instances. A very first tech preview of that feature is available through cq-6.3.0-featurepack-18678.
Upgrade of Core Components
One benefit of versioned components is that it allows to separate the migration to a new AEM version from the migration to new component versions. Also, if new component versions are available, it allows for the individual migration of each component to the new version.
Migrations to a new AEM version won’t impact how the Core Components work, provided that their versions also support the new AEM version that is being migrated to. Customizations made to the Core Components should not be affected either, as long as they don’t use APIs that have been deprecated or removed.
Migrations to new versions of the Core Components won’t impact how the component works either, but new features might be introduced to page authors, which might require some configuration by a template editor, in case the default behavior isn’t desired. Customizations however might need to be adapted, for more details see the Customizing Core Components page.
When to Use the Core Components?
As the Core Components are all-new for 6.3, and 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, for example a rebranding or overall refactoring.
Therefore, Adobe provides following recommendations:
New Projects
Use the Core Components wherever they match the needs of the project, or optionally extend them.
Except for the various Layout Containers and Paragraph Systems, don’t use 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
Assess if an existing Core Component may be customized.
If not, recommendation is to build a new custom component following the Component Guidelines.
Existing Custom Components
If your components work as expected, then keep them as they are.
If not, refer to “New Custom Components” above.Core Component Support
Core Components are an integral part of AEM and supported as is, under the same terms and conditions as if they were delivered as part of the Quickstart.
Like other product features, the general rule is: Components are 1st announced to be deprecated, and the earliest removed for the following AEM release. That gives customers at least one release cycle to move to the new version of the component, before dropping its support.
The version of each component clearly states the AEM versions that it supports. When support ceases for a version of AEM, then so does the support of the Core Components for that version of AEM.
For details about the support of component customizations, see the Customizing Core Components page.
Foundation Component Support
Since the foundation components have served as a basis of so much project development over many versions, they will continue to be supported into the foreseeable future.
However, Adobe’s development emphasis has shifted to the core components and new features will be added to them whereas only bug fixes will be made to the foundation components
Component Guidelines
The Core Components follow modern implementation patterns that are quite different from the foundation components.
This page explains these patterns, and when to use them to build your own authorable components. The first section “General Component Patterns” applies to any kind of component, while the second section “Reusable Component Patterns” applies to components that are intended to be reused across sites or projects, like the Core Components for instance.
General Component Patterns
The guidelines in this section are recommended for any kind of component, regardless whether the component is specific to a single project, or whether the component is meant to be widely reused across sites or projects.
Configurable Components
Components can have dialogs with a variety of options. This should be leveraged to make components flexible and configurable, and avoid implementing multiple components that are mostly variations of each other.
Typically, if a wireframe or design contains variations of similar elements, these variations should not be implemented as different components, but as the one component with options to choose between the variations.
To take this a step further, if components are reused across sites or projects, also look the Pre-Configurable Capabilities section.
Separation of Concerns
Keeping the logic (or model) of a component separate from the markup template (or view) is usually a good practice. There are several ways to achieve that, however the recommended one is to use Sling Models for the logic and the HTML Template Language (HTL) for the markup, like the Core Components also do.
Sling Models are a set of Java annotations to easily access needed variables from POJOs, and therefore offer a simple, powerful and performant way to implement Java logic for components.
HTL has been designed to be a secure and simple template language that is tailored for AEM. It can call many forms of logic, which makes it very flexible.
Reusable Component Patterns
The guidelines in this section can be used as well for any kind of component, but they make most sense for components that are intended to be reused across sites or projects, like the Core Components for instance. These guidelines can therefore be ignored for components that are only used on a single site or project.
Pre-Configurable Capabilities
In addition to the edit dialog that is used by page authors, components can also have a design dialog for template authors to pre-configure them. The Template Editor allows to setup all these pre-configurations, which are called “Policies”.
To make components as reusable as possible, they should be provided with meaningful options to pre-configure. This will allow to enable or to disable features of the components to match the specific needs of different sites.
Proxy Component Pattern
As each content resource has a sling:resourceType property that references the component to render it, it is usually good practice to have these properties pointing to site-specific components, instead of pointing to components that are shared by multiple sites. This will offer more flexibility and avoid content refactoring if one site needs a different behavior for a component, because this customization can then be achieved on the site-specific component and won’t affect the other sites.
However, for the project-specific components no not duplicate any code, they should each refer to the shared parent component with the sling:resourceSuperType property. These project-specific components that mostly just refer to parent components are called “proxy components”. Proxy components can be entirely empty if they fully inherit the functionality, or they can redefine some aspects of the component.
Component Versioning
Components should be kept fully compatible over time, yet sometimes changes that cannot be kept compatible are necessary. One solution to these opposing needs is to introduce component versionning by adding a number in their resource type path, and in the fully qualified Java class names of their implementations. This version number represents a major version as defined by semantic versioning guidelines, which is incremented only for changes that are not backward-compatible.
Component versioning creates a form of contract that is important for upgrades as it clarifies when something might need to be refactored. See also the section Upgrade Compatibility of Customizations, which details what form of customization detailed version policy for the Core Components.
To avoid painful content migrations, it is important to never directly point to versioned components from content resources. As rule of thumb, a sling:resourceType of the content must never have a version number in it, or upgrading components will require the content to be refactored too. The best way to avoid this is to follow the Proxy Component Pattern described above.
Model Interfaces
This pattern is about HTL’s data-sly-use instruction to point to a Java interface, while the Sling Model implementation is also registering itself to the resource type of the component.
When combined with the Proxy Component Pattern described above, this form of double-binding offers following nice extension points:
A site can redefine the implementation of a Sling Model by registering it to the resource type of the proxy component, without having to mind about the HTL file, which can still point to the interface.
A site can redefine the HTL markup of a component, without having to mind about which implementation logic it should point to. Putting it all together
Below is an overview of the entire resource type binding structure, taking the example of the Title Core Component. It illustrates how a site-specific proxy component allows to resolve component versioning, to avoid that the content resource contains any version number. It then shows how the component’s title.html HTL file uses to the model interface, while the implementation binds to the specific version of the component through Sling Model annotations. 
Below is another overview, which doesn’t show the details of the implementation POJO, but reveals how the associated templates and policies are referenced.
The cq:allowedTemplates property tells which templates can be used for a site, and the cq:template tells for each page what the associated template is. Every template is made of following three parts:
structure contains the resources that will be forced on each page to be present, and that the page author won’t be able delete, like for instance the page header and footer components.
initial contains the initial content that will be duplicated to the page when it is created.
policies contains for each component the mapping to a policy, which is the component’s pre-configuration. This mapping allows policies to be reused across templates, and therefore to be centrally managed.
The version of each component clearly states the AEM versions that it supports. When support ceases for a version of AEM, then so does the support of the Core Components for that version of AEM.
For details about the support of component customizations, see the Customizing Core Components page.
Foundation Component Support
Since the foundation components have served as a basis of so much project development over many versions, they will continue to be supported into the foreseeable future.
However, Adobe’s development emphasis has shifted to the core components and new features will be added to them whereas only bug fixes will be made to the foundation components
Component Guidelines
The Core Components follow modern implementation patterns that are quite different from the foundation components.
This page explains these patterns, and when to use them to build your own authorable components. The first section “General Component Patterns” applies to any kind of component, while the second section “Reusable Component Patterns” applies to components that are intended to be reused across sites or projects, like the Core Components for instance.
General Component Patterns
The guidelines in this section are recommended for any kind of component, regardless whether the component is specific to a single project, or whether the component is meant to be widely reused across sites or projects.
Configurable Components
Components can have dialogs with a variety of options. This should be leveraged to make components flexible and configurable, and avoid implementing multiple components that are mostly variations of each other.
Typically, if a wireframe or design contains variations of similar elements, these variations should not be implemented as different components, but as the one component with options to choose between the variations.
To take this a step further, if components are reused across sites or projects, also look the Pre-Configurable Capabilities section.
Separation of Concerns
Keeping the logic (or model) of a component separate from the markup template (or view) is usually a good practice. There are several ways to achieve that, however the recommended one is to use Sling Models for the logic and the HTML Template Language (HTL) for the markup, like the Core Components also do.
Sling Models are a set of Java annotations to easily access needed variables from POJOs, and therefore offer a simple, powerful and performant way to implement Java logic for components.
HTL has been designed to be a secure and simple template language that is tailored for AEM. It can call many forms of logic, which makes it very flexible.
Reusable Component Patterns
The guidelines in this section can be used as well for any kind of component, but they make most sense for components that are intended to be reused across sites or projects, like the Core Components for instance. These guidelines can therefore be ignored for components that are only used on a single site or project.
Pre-Configurable Capabilities
In addition to the edit dialog that is used by page authors, components can also have a design dialog for template authors to pre-configure them. The Template Editor allows to setup all these pre-configurations, which are called “Policies”.
To make components as reusable as possible, they should be provided with meaningful options to pre-configure. This will allow to enable or to disable features of the components to match the specific needs of different sites.
Proxy Component Pattern
As each content resource has a sling:resourceType property that references the component to render it, it is usually good practice to have these properties pointing to site-specific components, instead of pointing to components that are shared by multiple sites. This will offer more flexibility and avoid content refactoring if one site needs a different behavior for a component, because this customization can then be achieved on the site-specific component and won’t affect the other sites.
However, for the project-specific components no not duplicate any code, they should each refer to the shared parent component with the sling:resourceSuperType property. These project-specific components that mostly just refer to parent components are called “proxy components”. Proxy components can be entirely empty if they fully inherit the functionality, or they can redefine some aspects of the component.
Component Versioning
Components should be kept fully compatible over time, yet sometimes changes that cannot be kept compatible are necessary. One solution to these opposing needs is to introduce component versionning by adding a number in their resource type path, and in the fully qualified Java class names of their implementations. This version number represents a major version as defined by semantic versioning guidelines, which is incremented only for changes that are not backward-compatible.
Component versioning creates a form of contract that is important for upgrades as it clarifies when something might need to be refactored. See also the section Upgrade Compatibility of Customizations, which details what form of customization detailed version policy for the Core Components.
To avoid painful content migrations, it is important to never directly point to versioned components from content resources. As rule of thumb, a sling:resourceType of the content must never have a version number in it, or upgrading components will require the content to be refactored too. The best way to avoid this is to follow the Proxy Component Pattern described above.
Model Interfaces
This pattern is about HTL’s data-sly-use instruction to point to a Java interface, while the Sling Model implementation is also registering itself to the resource type of the component.
When combined with the Proxy Component Pattern described above, this form of double-binding offers following nice extension points:
A site can redefine the implementation of a Sling Model by registering it to the resource type of the proxy component, without having to mind about the HTL file, which can still point to the interface.
A site can redefine the HTL markup of a component, without having to mind about which implementation logic it should point to. Putting it all together
Below is an overview of the entire resource type binding structure, taking the example of the Title Core Component. It illustrates how a site-specific proxy component allows to resolve component versioning, to avoid that the content resource contains any version number. It then shows how the component’s title.html HTL file uses to the model interface, while the implementation binds to the specific version of the component through Sling Model annotations.
The cq:allowedTemplates property tells which templates can be used for a site, and the cq:template tells for each page what the associated template is. Every template is made of following three parts:
structure contains the resources that will be forced on each page to be present, and that the page author won’t be able delete, like for instance the page header and footer components.
initial contains the initial content that will be duplicated to the page when it is created.
policies contains for each component the mapping to a policy, which is the component’s pre-configuration. This mapping allows policies to be reused across templates, and therefore to be centrally managed.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.