In this next post on AEM Experience Fragments, we’ll discuss the overall architecture by looking at these three aspects:
- Content model
- Rendering HTML output
Experience Fragments are regular pages with specific resource types and templates. They should be stored in
The XF page consists of 2 parts: a parent page and one or more variation pages.
The XF parent page has no actual content and serves to logically combine its variations. Its resource type is cq/experience-fragments/components/experiencefragment . An XF variation page is a subpage of the parent page. Its resource type is cq/experience-fragments/components/xfpage or its subtypes.
The master variation is created automatically when XF is created. It cannot be deleted unless the whole XF is deleted. To distinguish the master variation among the other variations, this JCR property is used:
cq:xfMasterVariation = true
Here are some notable JCR properties for variations:
-cq:xfShowInEditor=true/falsecontrols whether the variation will be shown in the asset side panel
-cq:xfSocialVariation=true/falseis used to filter out “social” variations (Facebook, Pintrest) from the various admin UI elements
-cq:xfVariantType=web/facebook/pintrestis used to distinguish the variation’s intended use
-cq:xfMasterVariationis used to mark “master” variation
Templates are used to create variations just as with regular AEM page OOTB (out of the box) templates:
- Web templates are based on an HTML5 web templates to create web variations
- ”Social” variation templates exist for Facebook and Pintrest
For experience fragments, only editable templates can be used, static templates are not fully compatible. Editable templates, which in turn are defined by editable template types and an AEM page component implementation, define the allowed AEM components that can be used to compose an Experience Fragment. The experience fragment is an instance of an editable template that represents a logical experience. Experience fragment variations adhere to the editable template, but represent differences in experience (content and design).
To create an experience fragment template that is detected by the Create Experience Fragment wizard, you must follow one of these scenarios.
- The resource type of the template (the initial node) must inherit from
- And the name of the template must begin with “experience-fragments”.
This allows users to create experience fragments in
/content/experience-fragments as the cq:allowedTemplates property of this folder includes all the templates that have names beginning with “experience-fragment”. Customers can update this property to include their own naming scheme or template locations.
- Add the template details manually in cq:allowedTemplates on the
Creating our own template type and a rendering component will be described in our next article.
Rendering HTML Output
We can directly expose an experience fragment variation as “plain HTML.” Using the
.plain. selector in the URL, you can access the plain HTML rendition. This is available from the browser, but its primary purpose is to allow other applications like third-party web apps or custom mobile implementations to access the content of the experience fragment directly, using only the URL (for example,
The rendering is controlled by the Experience Fragments HTML rendering output processor service, which is configured just like any other OSGI service.
xf.rendering.html.whitelist.tag defines which tags are not stripped from the resulting HTML (common HTML tags are specified by default).
xf.rendering.html.whitelist.attribute defines which attributes are not stripped from the resulting HTML (defaults to
CSS classes whitelist
xf.rendering.html.whitelist.classes defines which classes are not stripped from the resulting HTML (no defaults).
Remove empty nodes
xf.rendering.html.removeempty, if true, instructs the processor to remove empty HTML nodes.
Stay tuned for our next post on XF where we dive into even more detail.
Author: Iryna Ason