Developing Core Components
The Core Components provide robust and extensible base components, and their highlights are:
- Feature-rich capabilities
- Continuous delivery
- 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
- Lean markup
- Capability to serialize as JSON the content model for headless CMS use cases
- Compliant with the WCAG 2.0 AA standard
Core Components require AEM 6.3 or later and Java 8 and and require the use of editable templates
Core Components do not work with the Classic UI nor with static templates.
Gems Session Overview
For an introduction to the Core Components, the features they offer, and how they are leveraged in AEM, check out the AEM Gems Session AEM Core Components.
Gems on Adobe Experience Manager is a series of technical deep dives delivered by Adobe experts. This series complements the product documentation and of all the other technical channels, allowing developers to get in touch and go deep on a specific topic.
WKND Developer Tutorial
Get started developing AEM Sites with Core Components by following this step-by-step tutorial.
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
- 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.
To keep up-to-date on the latest changes to the core components, you can watch the Core Components repository on GitHub.
Check out the Component Library , which showcases the current release of the Core Components and gives examples of their usage.
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.
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.
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 .
Java POJOs with Sling Models annotations
HTML Template Language (HTL) syntax
Automated by HTL
CSS classes naming
Standardized naming convention based on Block Element Modifier (BEM) notation (as of release 2.0.0)
Coral 2 + Classic UI
Default Sling servlet
Unit Tests + Integration Tests
Via pull request
Fully compliant with the WCAG 2.0 AA standard
Only partially compliant with the WCAG 2.0 AA standard
The following table lists the available Core Components, linking to their API, and indicates which foundation components they replace.
Replaced Foundation Component(s)
Responsive page working with template editor
Page hierarchy navigation
/libs/foundation/components/text /libs/foundation/components/table /libs/wcm/foundation/components/text
Smart and lazy loading of optimal rendition size
/libs/foundation/components/image /libs/foundation/components/adaptiveimage /libs/foundation/components/logo /libs/foundation/components/mobileimage /libs/foundation/components/mobilelogo /libs/wcm/foundation/components/image
List of pages
/libs/foundation/components/list /libs/foundation/components/mobilelist /libs/wcm/foundation/components/list
Facebook and Pinterest sharing widget
Responsive form paragraph system
Text input field
Multiple options input field
/libs/foundation/components/form/checkbox /libs/foundation/components/form/radio /libs/foundation/components/form/dropdown
Hidden input field
Submit or custom button
A site navigation component that lists the nested page hierarchy
A language and country switcher that lists the global language structure
A search component that displays the results as in-place suggestions in a drop-down menu
Allows the content author to easily create a teaser to further content using an image, title, or rich text and linking to further content or other actions
Allows the content author to organize page content within multiple tabs
Allows the content author to organize content in a rotating carousel of slides
Allows for the display of a content fragment
Allows for the display a list of content fragments
Separates content on a page
Organize content panels in a collapsible accordion
Organize components within a container
Create a button on a page
Add a downloadable asset to a page
Add an experience fragment to a page
For an overview of the upcoming Core Componente roadmap see the project wiki on GitHub .
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, 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 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 the component architecture set forth in core components. Except where not otherwise possible, avoid using the foundation components .
- Existing Custom Components If your components work as expected, then keep them as they are. If not, refer to "New Custom Components" above.
Migrating to the Core Components
Any new project should be implemented with Core Components. However existing projects will usually have extensive implementations of the Foundation Components.
A larger effort on an existing project (for example a rebranding or overall refactoring) often offers a chance to migrate to the Core Components. To facilitate this migration, Adobe has provided a number of migration tools to encourage the adoption of the Core Components and the latest AEM technology.
The AEM Modernization Tools allow for the easy conversion of:
- Static templates to editable templates
- Design configurations to policies
- Foundation Components to Core Components
- Classic UI to Touch-Enabled UI
For further information about the usage of these tools, see their documentation .
The AEM Modernize Tools are a community effort and are not supported or warrantied by Adobe.
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 AEM product features, the general rule is: Components are first 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 AEM 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 nearly all Foundation Components have been deprecated with AEM 6.5 and only bug fixes will be made to the Foundation Components going forward.