Modern AEM Component Implementation Patterns

AEM Core Components follow modern implementation patterns. There are two types of component patterns in AEM, General Component Pattern & Reusable Component Pattern


1. General Component Patterns
This set of patterns is recommended for any type of the component (regardless of whether the component is specific to a single project, or reused across multiple sites or projects).

a. Configurable Components
There are cases where we have a requirement of components which are having variations of similar elements. In such cases, it is recommended to have configurable components having dialogs with various options instead of creating multiple components.

b. Separation of Concerns
This pattern recommends the usage of separation of logic from markup.
- HTL can be used for markup which is more secure.
- SlingModels are the recommended option for Logic implementation

2. Reusable Component Patterns
These patterns are used for any kind of component, which is most suitable for components that are intended to be reused across multiple sites or projects(For eg. Core Components)

a. Pre-Configurable Capabilities
It is recommended to define the components/templates as flexible as possible. Some examples could be using edit dialog (For Page authors), Design Dialog (For Template authors) and all these options are available under 'Policies' as part of editable templates.

b. Proxy Component Pattern
Here component inheritance is used as a proxy. Create second level components by referring to the resourceSuperType property from core components.
This offers more flexibility and avoids content refactoring if one site needs a different behavior for a component.

c. Component Versioning
Always introduce component versioning by adding a number in their resource type path, and in the fully qualified Java class names of their implementations, which will help to keep the components compatible over time. Useful when the upgrade happens.

d. Model Interfaces
This pattern recommends the usage of 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 there is a requirement to redefine the implementation of a Sling Model or HTL markup of a component, this avoids complexity. Because they are loosely coupled.