AEM Core Components follow modern implementation patterns. There are two groups of them: general component patterns and reusable component patterns.
1. General component patterns
These patterns are recommended for every kind of component, whether it is specific to one project or reused across several sites or projects.
a. Configurable components
When a requirement calls for components with variations of similar elements, build one configurable component whose dialog offers the options, instead of creating several components.
b. Separation of concerns
Keep logic separate from markup:
- use HTL for the markup, which is more secure;
- use Sling Models for the logic.
2. Reusable component patterns
These apply to any component but suit best the components meant to be reused across multiple sites or projects, such as the Core Components.
a. Pre-configurable capabilities
Make components and templates as flexible as possible: an edit dialog for page authors, a design dialog for template authors, and all of these options available as policies in editable templates.
b. Proxy component pattern
Component inheritance is used as a proxy: create project-level components that point to a Core Component through the sling:resourceSuperType property. This gives more flexibility and avoids content refactoring when one site needs a component to behave differently.
c. Component versioning
Version components by adding a number to their resource type path and to the fully qualified Java class names of their implementations. This keeps components compatible over time and helps when upgrading.
d. Model interfaces
Point HTL's data-sly-use to a Java interface, while the Sling Model implementation registers itself against the component's resource type. Because the two are loosely coupled, redefining a component's Sling Model implementation or its HTL markup stays simple.