AEM Sites Implementation and Component Architecture
Component architecture is the heart of Sites work. Understand the split between HTL (Sightly) templates, Sling Models, and client libraries, and why business logic belongs in models or services rather than in HTL. Know the resource-type resolution chain, the role of sling:resourceSuperType for inheritance, and how the Component Console and proxy components enable core component extension. A candidate must be fluent in HTL expression rules (context-aware escaping, data-sly-use, data-sly-resource, data-sly-list) and in the design-time versus runtime distinction: dialogs and policies shape authoring, models and services shape rendering.
Sling Models deserve special attention: injection strategies, @Via for request-scoped data, adaptables (Resource versus SlingHttpServletRequest), default values, and the OSGi service annotation. Understand client library categories, embedding, and dependencies, and why the allowProxy property matters when components live under /apps but assets must be served from /etc.clientlibs.
Traps include questions that place business logic in HTL, assume a dialog field automatically appears in the model, or confuse the component's resource type with its path. Another common trap: assuming inheritance copies dialog fields rather than merging them. Also expect questions on the difference between a proxy component and a direct override, and on how cq:Component properties like isContainer and the layout container affect authoring.
Rule of thumb: dialogs and policies configure, models compute, HTL displays. Worked example: a teaser component needs a title, image, and link with fallbacks to inherited page properties. Implement a Sling Model with @ValueMapValue injections, expose computed getters for fallbacks, and keep HTL limited to markup and escaping.