Structural assets should be stored and managed within the client library’s resources folder by the code package, and not in AEM Digital Assets Manager (DAM) “as content”. The AEM DAM is a very flexible AEM product where it allows users & groups to freely manage (based on ACL permissions) assets to make available for the public. Sometimes developers may find the ease of storing structural assets in the DAM (with the help of content authors), so they can quickly make the structural asset publically available for consumption. But, in fact, this is the wrong pattern to follow.
The reason why structural assets should not be stored “as content” and managed as DAM assets because:
- It would be surfaced to AEM content authors (the customers) during image selection when they are editing an AEM page that requires an AEM DAM asset; they can be confused, and they can potentially select on the structural asset (because it’s available for selection).
- It would kickstart workflows; creating thumbnails, preview renditions, meta-data extractions, and other workflow processes… These are unnecessary asset processing… we do not want any thumbnails or renditions for the structural asset.
Click here to learn how to create a client library that only serves static assets.
Structural assets should be stored and managed within the client library’s resources folder by the code package. It allows developers to have full control of which structural asset gets added, updated, or removed. AEM authors have 0% chance of breaking accidentally removing one of these assets vs if structural content is stored “as content”, where assets can be managed and consumed in an unpredictable way.