Content Fragments Templates

Today, I will focus on Content Fragment templates. This post is in continuation of the previous post, where I talked about new Content Fragment feature introduced in AEM 6.2. In order to understand Content Fragment templates, it is important you understand the basic structure and capabilities of Content Fragment. Please refer my previous blog post for the same: https://experiencelabs.wordpress.com/2016/10/29/content-fragments-an-introduction/

AEM 6.2 ships with a standard Content Fragment template. However, for you to use Content Fragments for your project, you will need to create a Content Fragment template. Before we go deeper into defining our own template, we will first look at the template that ships with AEM 6.2. The template name is “Simple Fragment” and it is defined in libs under this path: /libs/settings/dam/cfm/templates

Let’s browse this location in CRXDE. You will see the following structure:

+ <template-name>

– jcr:primaryType

– jcr:title

– jcr:description

– initialAssociatedContent

– precreateElements

– version

+ elements

– jcr:primaryType

+ <element-name>

– jcr:primaryType

– jcr:title

– defaultContent

– initialContentType

– name

… + other element definitions

+ variations

– jcr:primaryType

+ <variation-name>

– jcr:primaryType

– jcr:title

– jcr:description

– name

… + other variation definitions

The key elements of the template are:

  • Elements
    A list of elements that would define the structure of the the fragment. This field is mandatory and needs to have at least one child node for the “Main” element. For each element, we can define the bootstrap content (the default text) as well as a the content type. AEM 6.2 allows three content types out of the box (html, plain text and markdown)
  • Variations(optional)
    It defines the default variations for each Content Fragment. Please note, variations are defined at the Content Fragment level and this apply to all elements.
  • initialAssociatedContent (optional)
    A array of paths to LightBox collections, that would be associated by default with each Content Fragment.

Now, we will go ahead and create a template of our own. As you know, /libs is reserved for items that ship with the product. Hence, you should never write anything in /libs. All custom Content Fragments should be either defined in /apps or /config. Let’s look at these two options more carefully.

Apps: here is the complete path /apps/settings/dam/cfm/templates, it doesn’t exist, you will need to create it. Create Content Fragment templates here for overlaying out-of-the-box template (Simple Fragment) and creating general purpose templates.

Config: here is the complete path /conf/global/settings/dam/cfm/templates, it doesn’t exist and you will need to create this as well. Create Content Fragment templates here for instance-wide customer-specific templates that may be configured to be unavailable. Use this location for defining folder specific templates.

For the purposes of this blogpost, we will create a template under /apps.

Step by Step Instructions:

  1. Prepare basic structure under /apps
  • Open up CRXDE lite, and browse to /apps/settings
  • Create node of type cq:Page and name it dam
  • Select the newly created dam node and create another node of type cq:Page and name it cfm
  • Select newly created cfm node and create another node of type cq:Page and name it templates
  • Select the newly created templates node and once more create node of type cq:PageContent and name it jcr:content.
  • Now we need to specify that the templates in this location should be merged with those from /libs/settings/dam/cfm/templates. To do this, create a new boolean property under jcr:content named mergeList and set it’s value to true.
  • Select “Save All” to save the changes we have made so far. Here is a snapshot of the CRXDE lite, after you complete these steps.

Blog51.png

  1. Create a shell Content Fragment Template
  • Browse to /libs/settings/dam/cfm/templates and expand the node.
  • Select “simple” node and Copy it.
  • Browse again to /apps/settings/dam/cfm/templates.
  • Select templates and Paste to create a copy of the “simple” node structure from /libs.
  • Select “Save All” to save all the changes. Here is a snapshot of the CRXDE lite, after you complete these steps.

Blog52.png

  1. Now we will modify the copied structure based on our needs. We will create three elements – Header, Main and Footer, and define three Variations – Desktop, Tablet and Mobile Phone.
  • First, select “simple” node and rename it to “simple-topic”
  • Next, select “jcr:content” under “simple”. Change the value of “jcr:description” to “A fragment, containing three elements and three variations” and “jcr:title” to “Simple Topic Fragment”
  • Now, select elements and create two new elements – header and footer. To do so, create a new node and name it header. Add new properties “jcr:title” as “Header”, and “name” as “header”. Follow the same process to create “Footer” element.
  • Lastly, select node “jcr:content” under node “simple” and create a new node of type nt:unstructured and name it variations.
  • Now define all three variations – desktop, tablet and mobile, by creating a new node for each one of them of type nt:unstructured. Also set at least two properties, jcr:title and name.
  • Select “Save All” to save all the changes. Here is a snapshot of the CRXDE lite, after you complete these steps.

Blog53.png

We have now successfully defined a new template called “Simple Topic Template”. Let’s test and use it in creating a new Content Fragment.

To create a new content fragment using the newly created template,

  • Browse to AEM Assets (DAM): http://localhost:4502/assets.html/content/dam
  • Click on “Create” and select “Content Fragment” to create a new Content Fragment
  • In the “New Content Fragment” wizard, you shall see two templates. Select the newly created “Simple Topic Fragment” and click next. Provide a name for the new template say first topic and click “Create”. Next choose “Open”.

Blog54.png

  • We can now check and see that the newly created first topic template has three elements called – main, header and footer. We can select each one of these options to author these three sections separately.

Blog55.png

  • Next, click on Variations and see that all the three default variations (desktop, tablet and mobile) that we defined in the template are also available.

Blog56.png

We have successfully created and used a content fragment template.

Do share your thoughts/comments/feedback for the post.

XLIFF support in AEM 6.2

AEM 6.2 release was a major milestone from translation perspective. In this release, AEM took a huge step forward and added support for XLIFF generation, making AEM truly vendor agnostic. In this post, we will see try to evaluate what is available in AEM 6.2 and how can you take advantage of the same.

First and foremost, there is a NEW simple interface to support XLIFF. It has two simple APIs – one for generating XLIFF from AEM XML (export workflows) and the second one is for ingesting XLIFF back into AEM by converting that to AEM XML. For folks who like to see the parameters, here are the exact APIs:

public interface TranslationXLIFFService {

/**

* Converts an XML document, corresponding to a translation object, to an equivalent XLIFF string

* @param xmlDocument XML document containing the content to be translated

* @param id Unique id corresponding to the translation object from which the xmlDocument was created

* @param sourceLanguage Source language of the translatable content inside xmlDocument

* @param xliffVersion Version of the output XLIFF

* @return String containing the complete XLIFF

* @throws TranslationXLIFFServiceException

*/

String convertXMLDocumentToXLIFFString(Document xmlDocument, String id, String sourceLanguage, String xliffVersion)

throws TranslationXLIFFServiceException;

/**

* Converts an XLIFF InputStream to an equivalent XML

* @param xliffInputStream Input XLIFF stream

* @param sourceLanguage Source language

* @param destinationLanguage Target language

* @return XML Document

* @throws TranslationXLIFFServiceException

*/

Document convertXLIFFStreamToXMLDocument(InputStream xliffInputStream, String sourceLanguage, String destinationLanguage)

throws TranslationXLIFFServiceException;

}

This interface can either be implemented by an AEM user, or there is an implementation available on PackageShare. For the purposes, of this blog post, we are going to install the package from Package Share.

Download package from here: https://www.adobeaemcloud.com/content/marketplace/marketplaceProxy.html?packagePath=/content/companies/public/adobe/packages/com.adobe.granite.translation.xliff/okapi-xliff-service-pkg

Once you have the package, install it on AEM using Package Manager (http://localhost:4502/crx/packageshare/index.html). This package supports both XLIFF 1.2 and XLIFF 2.0

Now the Translation Connectors can request XLIFF using the Translation Service. However, in case you do not use a connector and want to use Import/Export workflow from Translation Projects / Jobs, you will need to additionally set another option in the Felix Console. Follow these steps to enable XLIFF for Import/Export workflows:

Search for “Translation Platform Configuration” and click open itPicture1.png

  • Select the right XLIFF format here.

Once this property is set, if you Export a Translation Job, it will export the content in that specific XLIFF version.

Please note, this setting applies across the AEM instance.

Footnote:

In case you have an OKAPI service that you run for your company, you can easily write a connector to the OKAPI service. We have a connector of our own, which is built on top of OKAPI. We have open sourced it. Please see this blog post for more details.

XLIFF Connector: now Open Sourced

This has been long pending. We always wanted to to open source the XLIFF connector for Adobe Experience Manager 6.1, but have been really busy. The connector was built for Adobe Experience Manager 6.1 and is listed on the Adobe Marketing Exchange here. The connector was always free and anyone could download the connector from Adobe Marketing Exchange. The connector was also featured in Multilingual Magazine. Today, we are open sourcing the source code. You can look at the source code here: https://github.com/ExperienceLabs/xliff-export-connector

For core XLIFF conversion, connector relies on the OKAPI framework. It supports both XLIFF 1.2 and XLIFF 2.0 conversion. In case, you have forked OKAPI and have a modified version, you can just replace the OKAPI libs and repackage the connector.

In Adobe Experience Manager 6.2, Adobe has improved XLIFF support. Interestingly enough, they did not go ahead and implement XLIFF conversion. Rather they defined an interface and rely upon customers to implement the interface (basically write an XLIFF conversion). The XLIFF interface is modeled on Translation API. You can repurpose the XLIFF connector to build a connector for AEM 6.2 by implementing the interfaces as exposed in AEM 6.2. I want to do the same, but will park that as weekend project for later. I will share with you more once I get around implementing it myself.
Happy forking!!