Content Authoring, Dialogs, and Component Configuration
Dialogs define the authoring UI. Understand the difference between the edit dialog (component configuration, stored as cq:dialog) and the design dialog (cq:design_dialog, policy-backed in editable templates). Granite/Coral UI underlies dialog fields: textfield, pathfield, multifield, select, and the name/value binding to JCR properties. Know how sling:resourceType on dialog fields maps to Granite UI widgets, and how multifields store child nodes.
Understand authoring concepts: the page properties, the component console, the Assets console, and how content fragments differ from experience fragments. Know the difference between jcr:title and jcr:description, and how cq:tags support taxonomy.
Traps: putting design-time settings in the edit dialog; forgetting that multifield values are child resources, not simple properties; assuming dialog field changes apply to existing content (they change the schema, not stored values); confusing the classic (ExtJS) dialog with the touch UI (Granite) dialog. Another trap: name collisions causing overwritten properties.
Worked example: a multifield named items stores each entry as a child node under items with a jcr:primaryType; read them in a model via @ChildResource(name="items") returning a list.
Rule of thumb: if authors should configure it per-instance, it's an edit dialog; if it's a site-wide design decision, it's a policy/design dialog.