Content Fragments & models
Purpose: Define CF models, author fragments, and consume them in components and JSON — structured content done right.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | The structured-content workhorse |
Model → fragments → consumption
- Model (/conf/phi-academy/settings/dam/cfm/models): the schema. Fields for the PHI plan:
planName (text), tier (enum: gold/silver/bronze), monthlyPremium (number), excess (number), benefits (multi-line or referenced sub-fragments), disclaimer (long text).
- Fragments live in the DAM (/content/dam/phi/fragments/…), created from a model, authored in the CF editor.
Support variations (e.g. a "summary" variation of the disclaimer).
- Consumption:
| Channel | How |
|---|---|
| AEM page | Core "Content Fragment" component, or your component's model reads it |
| Custom component | Adapt: resource.adaptTo(ContentFragment.class), read elements by name |
| Headless JSON | .model.json via exporter-backed components, or Assets HTTP API |
| GraphQL (6.5 headless add-on / newer stacks) | Query by model — where available |
ContentFragment cf = fragmentResource.adaptTo(ContentFragment.class);
String premium = cf.getElement("monthlyPremium").getContent();Model design rules
- Model the domain, not a page section: "hospital plan", not "plan page left rail".
- Enumerations for controlled values (tier) — free text becomes unqueryable chaos.
- Reference fields for relationships (plan → shared disclaimer fragment) instead of duplication.
- Changing a model after thousands of fragments exist is migration work — review models like APIs.
Governance
CF models live in /conf and ship like templates: authored in an environment, promoted via packages, reviewed. Fragment content is authored in production like any content.