Content Fragments Configuring Components for Rendering
There are several advanced services related to the rendering of content fragments. To use these services, the resource types of such components must make themselves known to the content fragments framework.
This is done by configuring the OSGi Service - Content Fragment Component Configuration .
This information is required when:
- You need to implement your own Content Fragment-based component,
- And need to make use of the advanced services.
It is recommended to use the Core Components.
- If you do not need the advanced services described below, you can ignore this configuration.
- When you are extending or using the out-of-the-box component(s) , it is not recommended to change the OSGi configuration.
- You can write a component from scratch that uses the Content Fragments API only, with no advanced services . However, in such a case, you will have to develop your component so that it handles the appropriate processing.
Therefore, it is recommended to use the Core Components.
Definition of Advanced Services that need Configuration
The services that require the registration of a component are:
- Determining dependencies correctly during publication (i.e. ensure that fragments & models can be automatically published with a page if they have changed since last publication).
- Support for content fragments in full text search.
- The management/handling of in-between content.
- The management/handling of mixed media assets.
- Dispatcher flush for referenced fragments (if a page containing a fragment is re-published).
- Using paragraph-based rendering.
If you need one or more of these features, then (typically) it is easier to use the out-of-the-box Advanced Services, instead of developing them from scratch.
OSGi Service - Content Fragment Component Configuration
The configuration needs to be bound to the OSGi service Content Fragment Component Configuration :
See OSGi Configuration for further details.
The OSGi configuration is:
|Resource type||dam.cfm.component.resourceType||The resource type to register; e.g.
|Reference property||dam.cfm.component.fileReferenceProp||The name of the property that contains the reference to the fragment; e.g. fragmentPath or fileReference|
|Element(s) property||dam.cfm.component.elementsProp||The name of the property that contains the name(s) of the element(s) to render; e.g. elementName|
|Variation property||dam.cfm.component.variationProp||The name of the property that contains the name of the variation to render; e.g. variationName|
For some functionality your component will have to adhere to predefined conventions. The following table details the properties that need to be defined, by your component, for each paragraph (i.e. jcr:paragraph for each component instance) so that the services can detect and process them correctly.
A string property that defines how paragraphs are to be output if in single element render mode .
A string property that defines the range of paragraphs to be output if in single element render mode .
|paragraphHeadings||A boolean property that defines if headings (for example, h1 , h2 , h3 ) are counted as paragraphs ( true ) or not ( false )|
As an example, see the following (on an out-of-the-box AEM instance):
dam.cfm.component.resourceType="core/wcm/components/contentfragment/v1/contentfragment" dam.cfm.component.fileReferenceProp="fragmentPath" dam.cfm.component.elementsProp="elementName" dam.cfm.component.variationProp="variationName"