Copy
Copy
19. Frequently Forgotten Things
./ on every dialog field name. The single most common component bug.
composite="{Boolean}true" — without it a multifield saves only the first field per row.
The field node in a composite multifield must be a container.
Checkboxes need uncheckedValue, or unticking deletes the property.
{Boolean} and {Long} type hints — everything is a string without them.
The HTL file must match the folder name.
_cq_dialog on disk is cq:dialog in CRXDE.
Empty componentGroup hides the component — a feature, not a bug.
Two things must allow a component: its group, and the template policy.
Always proxy Core Components.
cq:template in a component is not a page template.
cq:editConfig affects the editor only.
A getter can be called many times from HTL — do the work in @PostConstruct.
OPTIONAL injection hides typos. A misspelled property name gives null, not an error.
adaptTo() can return null — including contentResource.adaptTo(CardModel.class) inside a loop.
Pagination via query parameter is not cacheable. Selector plus suffix.
Counter-based IDs collide when two instances of a component share a page.
20. Final Interview Summary
1. What a component is. A folder under /apps with everything to render one content type and let an author edit it. Content points at it via sling:resourceType.
2. The files. Definition, HTL named after the folder, dialog, edit config, defaults, clientlib.
3. The proxy pattern. Always. Selective override, version control, content decoupled from Adobe's paths.
4. The dialog. Granite UI containers and items. ./ on every name. Composite multifields make child nodes.
5. How saving works. The Sling Post Servlet writes form fields as properties. You never write a servlet for a dialog.
6. Where logic lives. Sling Model, not HTL. @PostConstruct for derived work. Never return null.
7. Inheritance and merging. sling:resourceSuperType for inheritance; the Resource Merger to add or hide individual dialog fields.
8. When not to build. Style System for appearance, policies for configuration, Core Components for anything they cover.
9. Production concerns. Bounded queries, cacheable pagination, accessibility, and the empty state authors will definitely create.
10. Your three stories. Simple, medium and complex, ready at 1, 2 and 3 minutes. This is the question that will actually be asked.
11. Mock Interview
How to use this: cover the answers, 25-minute timer, speak every answer out loud.
The interviewer asks:
What is a component in AEM, and how does content connect to it?
What files make up a component and what does each do?
Why must the HTL file be named after the component folder?
What is componentGroup, and why might a component not appear in the browser?
What is a proxy component and why do we use them?
How would you upgrade Core Components from v1 to v2?
How do you add a single field to an inherited dialog without copying it?
What does ./ mean in a dialog field name, and what happens without it?
What handles saving a dialog? Did you write that code?
Simple versus composite multifield — structure and how you read each.
Why do extra divs appear around my component, and how do I control them?
What is cq:editConfig used for? A real example of when you needed it.
Where should component logic live, and why not HTL?
Start simple — tell me about a straightforward component you built.
Now something harder — a component with repeating authored content.
Your component works on author but is blank on publish. Debug it.
How would you build a listing whose items come from the page tree?
How do you unit test a component, and what do you actually test?
How would you let authors change appearance without new components?
Tell me about the most complex component you have built.
Model answers
1. A folder under /apps holding everything needed to render one type of content and let an author edit it — HTL, dialog, usually a Sling Model. Content connects through sling:resourceType on the content node, pointing at the component's path. That property is the entire link between content and code.
2. .content.xml marks it a cq:Component with title, description and componentGroup. An HTL file named after the folder renders it. \_cq\_dialog is the author's form. \_cq\_editConfig controls editor behaviour. \_cq\_template supplies defaults when first dropped. Optionally a clientlibs folder. On disk they're _cq_ because a colon isn't a legal filename character; in CRXDE they're cq:.
3. Sling script resolution — one rule is a script named after the last segment of the resource type. For energy/components/cta that segment is cta, so Sling looks for cta.html. It's the general Sling rule applied here, not a special component rule.
4. It groups components in the browser. Empty or .hidden means it doesn't appear — which we use deliberately for helper components an author should never place directly. But there's a second reason: the template's policy must allow it too. Both have to say yes.
5. A component in our project whose entire content is essentially a sling:resourceSuperType pointing at a Core Component. Three reasons. Content stores our resource type, not Adobe's, so we're not coupled to their internal paths. We can override just the HTL or part of the dialog while inheriting everything else. And version upgrades become a one-line change instead of a content migration.
6. Change sling:resourceSuperType in the proxy from /v1/ to /v2/, then test, because v2 may have different markup or property names. No content changes, because content references the proxy. That's the whole reason the pattern exists — without it, that upgrade means rewriting the resource type on every affected node.
7. Create a dialog containing only the new field and let the Sling Resource Merger merge it with the inherited one. Position with sling:orderBefore, remove inherited fields with sling:hideResource, hide properties with sling:hideProperties. I never copy Adobe's dialog, because copying means I stop receiving their improvements.
8. ./ means the property is relative to the component's own node. Without it, the Sling Post Servlet writes it to the parent instead. The dialog appears to save with no error, but the model reads nothing. It's the most common component bug, and the fastest confirmation is opening the node in CRXDE and finding the property one level up.
9. The Sling Post Servlet — Sling's built-in handler for POST to a repository path. Its default behaviour writes the submitted fields as properties on the node at that path. So nobody writes that code and nothing generates it. A dialog is essentially an HTML form posting to the component's node path, which is exactly why ./ addressing matters.
10. Simple stores a multi-value string property — one value per row, read as a String\[]. Composite sets composite="\{Boolean}true" and wraps its fields in a container, so each row becomes a child node like faqs/item0 holding several properties, read with @ChildResource into a list of a nested model. The classic mistake is forgetting composite=true, in which case only the first field of each row saves.
11. The decoration tag — AEM wraps components so the editor can attach its toolbar and click handling. Three controls: decoration=false on an include, cq:noDecoration on the component, or decorationTagName to change the element. I usually reach for decorationTagName, because inside a
a wrapper is invalid HTML but an
- is correct. I avoid removing it entirely where I can, since the component becomes harder to select in the editor.
12. Editor behaviour — toolbar actions, DAM drop targets, in-place editing, listeners. The real example I've needed is afteredit="REFRESH\_PAGE". By default AEM refreshes only the edited component, which is fast, but if that edit changes something outside it the page looks wrong until the author reloads manually. It has no effect on publish at all.
13. In a Sling Model in the core bundle. HTL is deliberately restricted — it can't express arbitrary Java — and that's a feature, because it forces logic somewhere testable and stops business rules hiding in templates. The model gets unit tested; the HTL just displays what it exposes.
14. (The simple CTA story from 6.2 — roughly a minute. Four dialog fields, but call out the three real details: resourceResolver.map() for internal links, rel="noopener" with target="\_blank", and uncheckedValue on the checkbox.)
15. (The FAQ accordion story from 6.2 — roughly two minutes. Composite multifield and @ChildResource, the ARIA contract, path-derived IDs so two accordions on a page don't collide, and JSON-LD structured data built with a serialiser rather than string concatenation.)
16. error.log on publish first, because a model with OPTIONAL injection renders empty rather than throwing — the real error may only be in the log. Then whether everything it references was activated, which for a derived listing includes the child pages themselves. Then anonymous read permissions on every path it reads. Then the clientlib and allowProxy. Then whether the model depends on something author-only. I'd test against the publish URL directly in a private window, which separates a permissions problem from a caching one.
17. (The Q21 answer: traverse a known root versus query, index and limit if querying, build in @PostConstruct with a hard ceiling, server-render the first batch for SEO, serve later batches from a servlet using a selector and suffix so they stay cacheable, and add a flush rule so publishing a child invalidates the parent listing.)
18. AEM Mocks with JUnit 5 — load test content from JSON, register the models, adapt a resource, assert. But the important part is what I test: not that a getter returns its field, but the cases authors actually create — no multifield rows, a half-filled row, two instances on one page. Those are the paths that break in production. Any injected OSGi service gets registered as a mock in the context.
19. The Style System. Style classes are defined in the component's policy, the author picks one from a dropdown, and AEM adds the class to the wrapper. No code, no new resource type. Better than a dialog dropdown because it's controlled centrally per template rather than per instance, and better than variant components because there's nothing extra to maintain.
20. (The tabbed listing story from 6.3 — three minutes. Requirement, why cards can't be hand-authored, the three conflicting problems — query performance, cacheable Load More, stale invalidation — the hardest part being two rendering paths for one card, and the measurable outcome.)
Next topic
03-Editable-Templates-and-Policies — your syllabus point 3 in full: how editable templates are created, structure versus initial content, what a policy actually is and where it's stored, page policy versus content policy, how policies inherit, and how you allow or hide components on a page.