Cookies & Privacy

We are using cookies on your computer to help improving this website. If you agree to our use of cookies, please clos this message and continue to use this site. More information on how we use cookies can be found in our privacy statement

more details

Essential

These tags are required for the basic functions of the website.

Marketing

Marketing/target cookies are usually used to show you advertisements that meet your interests. When you visit another website, your browser's cookie is recognized and selected ads are displayed to you based on the information stored in this cookie (art. 6 par. 1 p. 1 a) GDPR).

Imprint | privacy statement

Force Selection for Tags Field

Exposing hidden features of the CFM editor in AEM - Part 2

Adaptive Forms Core Compnents

What are the differences between the forms core and foundation components
All Blog Entries

Date Range Validation Extension for Content Fragments

Exposing hidden features of the CFM editor in AEM - Part 1

With the tag field inside the AEM Content Fragment Models (CFMs) you can add tags as content to Content Fragments (CFs). This is a very helpful component to reuse the powerful AEM tags functionality also inside content.

But the field has one big disadvantage: the author can input their own tags that will be stored at a default namespace and not in your probably well thought out tags structure.

How to add a force selection functionality

So now we need to think about a solution on how to force the user to select only the already created tags to prevent chaos in our tags. And here a little bit of AEM reverse engineering can help big time.

Let's have a look at the component AEM is using for this tag field. You can find the CFM components under this path: 

 

  • /libs/settings/dam/cfm/models/formbuilderconfig/datatypes/items
Tag field properties in CRX

And here we see now that the tag field is of resourceType 

  • /libs/cq/gui/components/coral/common/form/tagfield

 

Now we can look inside the implementation and look at the render.jsp of this field:

render jsp of tag field

Isn't that exactly what we are searching for? 🥳 

Great - but how can we use it now in our Content Fragment Model? For this we need to do some more reverse engineering.

Let's have a look again at the CFM tag field and see how it's built together. For that we can have a look at the fieldProperties at

  • /libs/settings/dam/cfm/models/formbuilderconfig/datatypes/items/tagfield/tagsfields.jsp (see the picture above)
tagsfield hidden properties

In the tagsfields.jsp we can see that "forceSelection" property is already set to false permanently. So we need to overlay this file in order to expose the property to the CFM author.

To do that you can create a file "tagsfields.jsp" at the exact same path but under /apps

  • /apps/settings/dam/cfm/models/formbuilderconfig/datatypes/items/tagfield/tagsfields.jsp

 

And inside this file we will copy the content from the /libs file and modify it accordingly:

custom tagsfields.jsp

For copy pasting:

<%@ page import="org.apache.sling.api.resource.ValueMap" %><%
%><%@include file="/libs/granite/ui/global.jsp" %><%
%><%@ page session="false" contentType="text/html" pageEncoding="utf-8"
import="com.adobe.granite.ui.components.formbuilder.FormResourceManager,
org.apache.sling.api.resource.Resource,
org.apache.sling.api.resource.ValueMap,
java.util.HashMap"%><%

ValueMap fieldProperties = resource.adaptTo(ValueMap.class);
String key = resource.getName();
String xssKey = xssAPI.encodeForHTMLAttr(key);
%>

<input type="hidden" name="./content/items/<%= xssKey %>/multiple" value="false">
<input type="hidden" name="./content/items/<%= xssKey %>/cq:showOnCreate" value="true">
<input type="hidden" name="./content/items/<%= xssKey %>/autocreateTag" value="true">
<!-- BEGIN ORIGINAL FIELD -->
<!--<input type="hidden" name="./content/items/<%= xssKey %>/forceSelection" value="false">-->
<!-- END ORIGINAL FIELD -->

<!-- BEGIN CUSTOM CODE -->
<%
HashMap<String, Object> values = new HashMap<String, Object>();
values.put("granite:class", "checkbox-label forceSelection");
values.put("text", i18n.get("Force Selection"));
values.put("value", true);
values.put("uncheckedValue", false);
values.put("checked", Boolean.valueOf(fieldProperties.get("forceSelection", String.class)));
values.put("name", "./content/items/" + xssKey + "/forceSelection");

FormResourceManager formResourceManager = sling.getService(FormResourceManager.class);
Resource placeholderFieldResource = formResourceManager.getDefaultPropertyFieldResource(resource, values);

%><sling:include resource="<%= placeholderFieldResource %>" resourceType="granite/ui/components/coral/foundation/form/checkbox"/>
<!-- END CUSTOM CODE -->

With that custom code we now have the forceSelection property as checkbox inside the CFM editor and the user can only select the tags but not create new ones.

Force Selection inside Content Fragment Model Editor

 

Disclaimer

By extending AEM out-of-the-box functionality we always need to question ourselves if it's worth the risk to overlay. Because a new AEM release can contain changes at our changed files and could lead to unforeseen problems as there is no way to know what changed if you are not looking into the jsp/html/.. files in folder /libs directly.

In this case the risk is fairly low because we are changing only a single small jsp file. But also for this jsp we need to see what changes have been made with every AEM upgrade we do.

Tested with AEM 6.5.17

 

More on extending the Content Fragment functionality can be found here:

Part 1