AEM Sites Developer Professional cheat sheet
AEM Sites Developer Professional · Keep the key ideas within reach.
AEM Sites architecture and administration
Author instances create and replicate content; publish instances serve public traffic and normally sit behind a Dispatcher.
Oak is the JCR implementation; TarMK is the default segment store, while MongoMK supports shared persistence across clustered AEM nodes.
Standard repository layout: /content for content, /apps for project code, /libs for product code, /conf for context-aware configuration, and /etc for legacy configuration.
Replication agents on author push content to publish over HTTP(S); flush agents on publish invalidate Dispatcher caches.
ACLs are stored in the repository and evaluated by path; users inherit permissions through group membership, and deny entries take precedence.
OSGi configurations can be supplied through the web console, crx-quickstart/install, or config nodes under /apps or /conf; runmode folders use config..
AEM as a Cloud Service deploys code and configuration through Cloud Manager pipelines; production changes are not made with the package manager.
Workflow models and launchers define automated content processes; launchers specify node type, path, and conditions that trigger a workflow.
Dispatcher is an Apache or IIS module that caches responses and enforces filter rules before requests reach publish.
Templates and component development
HTL is the server-side template language; data-sly-use binds logic, data-sly-resource includes a resource, and data-sly-list iterates collections.
Editable templates are content stored under /conf//settings/wcm/templates; each template references policies stored under the matching policies path.
A static template is a component under /apps with sling:resourceType and is not editable in the page editor.
A proxy component sets sling:resourceSuperType to inherit another component's script and dialog; Core Components are commonly extended this way.
Touch UI dialogs use cq:dialog with Granite UI fields; the field name maps to the JCR property written on the component node.
Sling Models are annotated with @Model and adapt from Resource or SlingHttpServletRequest; @Inject, @ValueMapValue, and @OSGiService supply dependencies.
Client libraries declare categories, dependencies, and embed entries; js.txt and css.txt list source files.
Component policies control allowed components and design dialog properties per template; they are referenced by template structure.
Content Fragment Models are defined under /conf and drive structured content; fragments are stored as assets and accessed through the Assets API.
Sling, OSGi, and JCR
Sling resolves a request by path to a resource, then uses sling:resourceType plus selectors and extension to select a script or servlet.
A ResourceResolver is obtained from a SlingRepository or request; it must be closed, and resolver.adaptTo(Session.class) exposes the JCR session.
OSGi DS components use @Component and @Reference; configuration is bound with @Designate and an @ObjectClassDefinition interface.
OSGi component states include active, resolved, and unsatisfied; an unsatisfied component usually has a missing mandatory reference or configuration.
JCR nodes have primary and mixin node types; nt:unstructured holds arbitrary properties, while cq:Page and dam:Asset are AEM types.
ValueMap provides read access to properties; ModifiableValueMap allows writes that persist when the resolver commits.
ResourceChangeListener and JCR Observation notify code of repository changes; listeners should filter paths and run asynchronously.
QueryBuilder and JCR-SQL2 are query APIs; Oak indexes determine performance, and large result sets should be paged.
Sling Model Exporter uses ModelFactory and exporter options to serialize models to JSON for consumption by external clients.
Client-side development and asset handling
Client library categories are included in HTL with data-sly-call or the clientlib tag; on publish they are served from /etc.clientlibs when allowProxy is true.
A client library's js.txt and css.txt list files relative to the library folder; embed merges dependencies into one output, while dependency loads separately.
The AEM project archetype includes a ui.frontend module; npm and webpack build assets and aem-clientlib-generator copies them into a client library.
DAM renditions are stored under the asset's metadata/renditions node; the original is retained and renditions are generated by workflows or processing profiles.
Dynamic Media delivers images and video through a separate delivery tier and supports smart imaging and responsive viewer presets.
The Core Image Component generates responsive image URLs with width and crop parameters, using Dynamic Media or local renditions depending on configuration.
Asset metadata schemas define editable metadata fields; values are stored on the asset node and may be mapped to XMP.
Client-side libraries should be loaded with category-based includes rather than hard-coded script tags so dependencies and proxy paths are handled.
Caching, Dispatcher, and deployment
Dispatcher configuration is split into /cache, /rules, /filter, and /farm files; filter rules allow requests by path and HTTP method.
Only GET and HEAD responses are cached by default; POST and requests with authorization headers are passed through.
Cache invalidation is triggered by flush agents on publish that send invalidation requests to Dispatcher; content activation triggers the flush.
ignoreUrlParams controls which query parameters are ignored for cache-key calculation, preventing cache fragmentation from marketing parameters.
Dispatcher TTL and cache headers determine freshness; /statistics enable cache hit and miss monitoring.
AEM as a Cloud Service uses a CDN and a managed Dispatcher; cache purges can be requested through APIs, and web-tier configuration is deployed from the code repository.
Cloud Manager pipelines build, test, and deploy code packages and web-tier configuration; full-stack and web-tier pipelines serve different change types.
Author instances require sticky sessions because their repository state is local; publish instances are stateless and can be load balanced.