AEM Sites Developer Professional study materials
AEM Sites Developer Professional study resources

AEM Sites Developer Professional cheat sheet

AEM Sites Developer Professional · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.