DAM & assets
Purpose: Work with the Digital Asset Management system: renditions, metadata, processing and asset delivery in components.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Every component with an image touches the DAM |
Asset anatomy
/content/dam/phi/heroes/gold-hero.jpg (dam:Asset)
└── jcr:content
├── renditions/
│ ├── original
│ ├── cq5dam.thumbnail.319.319.png
│ └── cq5dam.web.1280.1280.jpeg
└── metadata (dc:title, dc:description, cq:tags, custom fields)Upload triggers the DAM asset workflows (via launcher): rendition generation, metadata extraction. Custom renditions/processing = extending that workflow.
Using assets in components
- Dialogs use path pickers / asset drop zones rooted at /content/dam.
- Never serve
originalon pages — pick or generate an appropriate web rendition. - The Core Components image component + adaptive image servlet handle responsive renditions (srcset) — extend it rather than hand-rolling image markup.
- Alt text comes from asset metadata or the author dialog — required either way (accessibility).
Metadata & findability
| Practice | Payoff |
|---|---|
| Mandatory metadata schema (title, alt, rights) on upload | Search works; compliance provable |
| Tags on assets from the shared taxonomy | Cross-channel discovery |
| Folder structure by domain, not by campaign date | Survives reorgs |
Delivery & caching
Asset URLs under /content/dam are cached by the dispatcher like pages. Asset updates re-publish and invalidate. Large-asset delivery (video) should go via appropriate renditions/streaming rather than original binaries through publish. Growth of /content/dam (and versions of assets) is an ops concern — see repository growth.