The helpPath configuration property is often used in AEM components or templates to specify the location where users can access contextual help documentation related to the specific component or template. This can be helpful for content authors and administrators who need guidance on how to use certain features or elements within the AEM interface.

By setting the helpPath property, you provide a reference to the relevant documentation that users can access directly from the AEM interface, making it easier for them to understand and work with different components and features. Clicking on the help path will redirect the author to documentation which may be useful for them to understand how the component works as expected.

Keep in mind that the exact implementation and usage of helpPath can vary based on the specific version of AEM and the customizations made by the organization. Always refer to the official AEM documentation or any relevant resources specific to your version of AEM for the most accurate and up-to-date information.

Example Code

The post Granite UI, Touch UI helpPath appeared first on Sourced Code.

1. A Deeper Look at Sling Resource Merging

Sling Resource Merging is like a code-friendly puzzle solver—it lets you combine resources and properties from different locations without getting tangled up. This is especially handy when you’re looking to make specific changes without messing around in the core functionalities stored in `/libs`. Let’s dive into the properties that make this process smoother.

2. Demystifying Sling Resource Merging Properties

Here’s a rundown of the essential properties you’ll encounter:

2.1. sling:hideProperties (String or String[])

This property allows you to hide certain properties that you don’t want to see. Whether you specify a single property or an array of properties, they’ll vanish from sight. The wildcard `*` works like magic—it hides everything except what you choose; Specifies the property, or list of properties, to hide.The wildcard * hides all.

Example:

2.2. sling:hideResource (Boolean)

When set to `true`, this property hides a resource entirely, including its children. Think of it as a way to temporarily pull a curtain over a specific resource when you need it out of sight; Indicates whether the resources should be completely hidden, including its children.

Example: In this example, we are hiding linkAriaLabel from being rendered on the view.

2.3. sling:hideChildren (String or String[])

Unlike the previous property, this one selectively hides child nodes while preserving their properties. Whether you’re hiding one or using `*` to hide them all, the properties stay untouched; Contains the child node, or list of child nodes, to hide. The properties of the node will be maintained. The wildcard * hides all.

Example: In this example, all children Granite UI fields are hidden from the view.

2.4. sling:orderBefore (String)

This property will force the Granite UI to render before a specific element. In this example, we are forcing the linkAriaLabel to render before the “title” Granite UI; Contains the name of the sibling node that the current node should be positioned in front of.

Example:

3. Real-world Applications of These Properties

Let’s translate these properties into practical scenarios:

1. Tailored Component Styling: Say you have a core component in `/libs` with default styles. Use `sling:hideProperties` to conceal unnecessary styles and introduce your own in `/apps`. This way, you retain the core functionality while customizing the look.
2. Conditional Rendering: For situations where you need to show or hide an entire component, `sling:hideResource` is your ally. It’s like having a switch to control whether a component and its children should be displayed based on specific conditions.
3. Optimized Content Arrangement: Use `sling:orderBefore` to reposition components within a container. This property is particularly helpful for responsive designs, ensuring content displays flawlessly on various devices.

4. Wrapping Up

Sling Resource Merging isn’t a mysterious incantation—it’s a tool that simplifies your AEM development journey. By getting acquainted with properties like `sling:hideProperties`, `sling:hideResource`, `sling:hideChildren`, and `sling:orderBefore`, you’re equipped to wield customization powers without the fuss. So go ahead, explore, and let Sling Resource Merging elevate your AEM development game!

The post Sling Resource Merging Properties appeared first on Sourced Code.

1. Tracking Code

The term “tracking code” generally refers to a piece of code or configuration that is used to collect data about user interactions and behaviors on a website or web application. This data can include information such as page views, clicks, form submissions, and more. In the context of AEM, tracking code can refer to the code or configuration that integrates with analytics tools like Adobe Analytics (formerly known as SiteCatalyst) to capture user data and generate insights about how users are interacting with your AEM-powered websites and digital experiences.

AEM allows you to integrate tracking codes into your templates, components, and pages so that you can measure the effectiveness and performance of your content and features. This data can be used to make informed decisions about content optimization, user experience enhancements, and marketing strategies.

Tracking Feature

The term “tracking feature” in AEM typically refers to a mechanism that enables you to associate analytics tracking with specific components or features within your AEM implementation. This feature helps you monitor and gather data about how users interact with those components or features. The term “tracking feature” might be specific to certain versions of AEM or certain projects, as it may not be an official Adobe term.

For example, a “tracking feature” could allow you to measure how many times a particular video component is viewed, how often a specific form is submitted, or how users interact with a custom navigation menu. By adding a tracking feature to a component, you can gain insights into user engagement and behavior related to that component.

In the previous example XML you provided, the `trackingFeature` attribute is used to define a tracking feature for a custom component. This attribute value could be used to identify and track interactions specifically related to the “My Custom Component.”

Please note that while I can provide information based on my knowledge up until September 2021, specific terms and implementations might have evolved in newer versions of AEM. Always refer to the official AEM documentation and resources specific to your version for the most accurate and up-to-date information.

Implementation

If you’re looking to implement tracking for components in AEM, you generally need to integrate with a third-party analytics platform like Adobe Analytics, Google Analytics, or any other analytics tool of your choice. Here’s a general outline of how you might approach setting up tracking for components:

1. Choose an Analytics Tool:
   Select an analytics tool that fits your needs. Adobe Analytics (formerly SiteCatalyst) is commonly used with AEM, but other tools like Google Analytics are also popular.
2. Obtain Tracking Code:
   For the selected analytics tool, obtain the tracking code or configuration that needs to be added to your AEM pages.
3. Implement Tracking Code:
   Integrate the tracking code into your AEM templates or components. You might need to add JavaScript snippets, tags, or configuration data to enable tracking.
4. Identify Component Interactions:
   Determine what interactions you want to track for your components. This could include clicks on specific buttons, form submissions, video views, etc.
5. Custom Events or Tracking Calls:
   Implement custom JavaScript events or tracking calls within your components to trigger the analytics tracking when specific interactions occur.
6. Testing and Validation:
   Test the tracking implementation to ensure that data is being captured accurately. Use the analytics tool’s reporting interface to verify that the tracking data is being recorded as expected.

Please consult your organization’s guidelines or documentation to understand if the term `trackingFeature` has a specific meaning or if there are custom tracking mechanisms they have set up. Additionally, refer to the documentation of the analytics tool you’re using to learn how to integrate tracking with AEM components effectively.

As of my last update, there might have been developments or changes in AEM and related tools, so I recommend checking the official documentation for the latest information and best practices.

Example Code

The post Granite UI, Touch UI trackingFeature appeared first on Sourced Code.

In this blog article, I will be showing you how to enable AEM Style System for your component it’s frankly just a configuration from the
cq_design_dialog or as developers know it, _cq_design_dialog/.context.html.

1. Disabled Style System

Without the Style System enabled for a component, the component policies page would look like this:

2. Adding code configurations

The quickest explanation of why the style system is not visible in the component’s policies is that you have a missing configuration for the cq_design_dialog. In the instructions below, we will include some code configurations to enable your target component’s AEM Style System feature.

1. Create a “_cq_design_dialog” folder under /apps/sourcedcode/components/examplecomponent
2. Create a “.content.xml” file under /apps/sourcedcode/components/examplecomponent/_cq_design_dialog with the file contents below:
3. Line:15-18 is the code block you should include in the _cq_design_dialog/.content.xml.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

   <?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"     jcr:primaryType="nt:unstructured"     jcr:title="Example Component"     sling:resourceType="cq/gui/components/authoring/dialog">     <content         jcr:primaryType="nt:unstructured"         sling:resourceType="granite/ui/components/coral/foundation/container">         <items jcr:primaryType="nt:unstructured">             <tabs                 jcr:primaryType="nt:unstructured"                 sling:resourceType="granite/ui/components/coral/foundation/tabs"                 maximized="{Boolean}true">                 <items jcr:primaryType="nt:unstructured">                     <styletab                         jcr:primaryType="nt:unstructured"                         sling:resourceType="granite/ui/components/coral/foundation/include"                         path="/mnt/overlay/cq/gui/components/authoring/dialog/style/tab_design/styletab"/>                 </items>             </tabs>         </items>     </content> </jcr:root>

4. We are utilizing the out-of-the-box AEM utils “/mnt/overlay/cq/gui/components/authoring/dialog/style/tab_design/styletab”, which enables the AEM Style System feature for your target component.
5. As a result, you should see something like this now. Make sure you configure the input fields indicated in red, and then continue on with the next instructions of this list.
6. When editing the component, you should see a “paintbrush” indicating that the style system configuration is working as expected. Click on it, and you should see the style configurations that we have configured in step 5.
7. Done

Add AEM Style System in Touch UI (popup)

Though we have configured and enabled the AEM Style System in the cq_design_dialog, the “Styles” option will only be visible in the “inline” edit mode for the target component. From the Touch UI (popup), the “Styles” tab will not be visible for the popup experience (when authors have clicked on the configure button for a target component). In this next section, we will add a piece of code to make the “Styles” tab visible, so content authors can configure the AEM Style System for the Touch UI “popup” experience.

1. Edit your already existing cq_dialog, under _cq_dialog/.content.xml.
2. Add this line of code:

   1 2 3 4

   <styletab     jcr:primaryType="nt:unstructured"     sling:resourceType="granite/ui/components/coral/foundation/include"     path="/mnt/overlay/cq/gui/components/authoring/dialog/style/tab_edit/styletab"/>

3. We are utilizing the out-of-the-box AEM utils “/mnt/overlay/cq/gui/components/authoring/dialog/style/tab_edit/styletab”, which enables the AEM Style System feature for your target component.
4. Skip this part, it’s just extra details – I wanted to show you an example of the completed configuration file of the _cq_dialog/.content.xml, given in step 2, this line of code only works when your AEM touch UI follows is configured with tabs. line:42-45 is where you can find the exact code that has been mentioned in step 2.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

   <?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"     jcr:primaryType="nt:unstructured"     jcr:title="Example Component"     sling:resourceType="cq/gui/components/authoring/dialog">     <content         jcr:primaryType="nt:unstructured"         sling:resourceType="granite/ui/components/coral/foundation/container">         <items jcr:primaryType="nt:unstructured">             <tabs                 jcr:primaryType="nt:unstructured"                 sling:resourceType="granite/ui/components/coral/foundation/tabs">                 <items jcr:primaryType="nt:unstructured">                     <tab1                         jcr:primaryType="nt:unstructured"                         jcr:title="Tab 1"                         sling:resourceType="granite/ui/components/coral/foundation/container"                         margin="{Boolean}true">                         <items jcr:primaryType="nt:unstructured">                             <columns                                 jcr:primaryType="nt:unstructured"                                 sling:resourceType="granite/ui/components/coral/foundation/fixedcolumns"                                 margin="{Boolean}true">                                 <items jcr:primaryType="nt:unstructured">                                     <column                                         jcr:primaryType="nt:unstructured"                                         sling:resourceType="granite/ui/components/coral/foundation/container">                                         <items jcr:primaryType="nt:unstructured">                                             <graniteExample1                                                 jcr:primaryType="nt:unstructured"                                                 sling:resourceType="granite/ui/components/coral/foundation/form/textfield"                                                 fieldDescription="Just an example"                                                 fieldLabel="graniteExample1"                                                 name="./graniteExample1"                                                 required="{Boolean}false"/>                                         </items>                                     </column>                                 </items>                             </columns>                         </items>                     </tab1>                     <styletab                         jcr:primaryType="nt:unstructured"                         sling:resourceType="granite/ui/components/coral/foundation/include"                         path="/mnt/overlay/cq/gui/components/authoring/dialog/style/tab_edit/styletab"/>                 </items>             </tabs>         </items>     </content> </jcr:root>

5. The result:

Last Thoughts

Enabling the AEM Style System is actually quite simple, but however, sometimes as a developer, you would like to access the configured properties fro the backend code to compute and execute code conditionally on what is configured. To learn how to obtain the style system AEM component configuration In the backend code, take a look at this blog, AEM Style System Component Information with Code Sling Models.

The post How to Enable AEM Style System Configuration for Components appeared first on Sourced Code.

Jump to Code Snippet

Granite UI (Touch UI) Rendered as

This is a screenshot of how a very basic Touch UI would look like for author’s when the author double clicks on the component to make change’s to it.

Jump to Code Snippet

Code Snippet

The solution below includes an example with the “styletab” which is an out-of-the-box feature for the AEM Style System. You can copy and paste this snippet into your .content.xml, like _cq_dialog/.content.xml:

Extras

If you would like to enable your component for the AEM Style System, click here, How to Enable AEM Style System Configuration for Components.

The post AEM Touch UI (Granite UI) Tabs: Example Code appeared first on Sourced Code.

In this blog article, I have created a solution for this. I have created a custom fix to the issue of hiding or showing Touch UI tabs for a particular component based on which style system has been selected for a given component; so the selected style system controls the hide or show the Touch UI tabs.

How the solution works:
The AEM developer will add code configurations to the cq_dialog.xml which targets one or more tabs with some special properties and nodes like the “granite:class” and the “granite:data”. After configuring these properties and nodes within the cq_dialog.xml, all tabs will be hidden as the initial rendering phase (during configuration of the component), Upon selection of a Style System, the tabs will be visible based on the matched configuration that is set under the granite:data node properties, based on the StyleSystem CSS class that was set.

The Steps

In this section, I will share with you the steps I have used to make this work as expected. In this section you will be:

1. Pre Requirements.
2. Creating a new component named Example Component.
3. Creating Sling Model for the Example Component.
4. Creating the Touch UI custom JavaScript implementation.
5. Testing it out.
6. Configuration Explanation of the Touch UI Granite Tab Fields.

0. Pre Requirements

The creation of this solution to hide or show Touch UI tabs for a particular component based on which style system is selected is based on the best practices of creating AEM components, following the guidelines of the AEM Core Components. This means that when a component is created, it requires a sling model to extends the com.adobe.cq.wcm.core.components.util.AbstractComponentImpl class. In turn the extension of the com.adobe.cq.wcm.core.components.util.AbstractComponentImpl will provide helpers that will expose the appliedCssClassNames property when the component is called with model.json.

Next, the sling model must declare the org.apache.sling.models.annotations.Exporter annotation, so model.json can be called upon for the particular component.

Module B within the article will show you how to setup the sling model to export JSON as mentioned above.

A. Create a new component as Example Component

You will be creating a new component as Example Component where I will install a simple example of the sightly component content’s a simple Touch UI configuration, and also a simple _cq_design_dialog, so you can actually configure the style system for your given component.

Please note that all files created should be placed under: /ui.apps/src/main/content/jcr_root/apps/sourcedcode/components/examplecomponent

1. Create a new folder /apps/sourcedcode/components/examplecomponent
2. Create an “examplecomponent.html” file under /apps/sourcedcode/components/examplecomponent with the file contents of:

   1	Example Component

3. Create a “.content.xml” file under /apps/sourcedcode/components/examplecomponent with the file contents of

   1 2 3 4 5

   <?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"     jcr:primaryType="cq:Component"     jcr:title="Example Component"     componentGroup="SourcedCode - Content"/>

4. Create a “_cq_editConfig.xml” file under /apps/sourcedcode/components/examplecomponent with the file contents of

   1 2 3

   <?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"     jcr:primaryType="cq:EditConfig"/>

5. Create a “_cq_dialog” folder under /apps/sourcedcode/components/examplecomponent
6. Create a “.content.xml” file under /apps/sourcedcode/components/examplecomponent/_cq_dialog with the file contents below.

   We have included custom granite properties to this file in order for this feature to work. If you would like to understand exactly what as added, please click here to read it in the last section.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111

   <?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:granite="http://www.adobe.com/jcr/granite/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"     jcr:primaryType="nt:unstructured"     jcr:title="Example Component"     sling:resourceType="cq/gui/components/authoring/dialog">     <content         jcr:primaryType="nt:unstructured"         sling:resourceType="granite/ui/components/coral/foundation/container">         <items jcr:primaryType="nt:unstructured">             <tabs                 jcr:primaryType="nt:unstructured"                 sling:resourceType="granite/ui/components/coral/foundation/tabs">                 <items jcr:primaryType="nt:unstructured">                     <tab1                         jcr:primaryType="nt:unstructured"                         jcr:title="Tab 1"                         sling:resourceType="granite/ui/components/coral/foundation/container"                         margin="{Boolean}true">                         <items jcr:primaryType="nt:unstructured">                             <columns                                 jcr:primaryType="nt:unstructured"                                 sling:resourceType="granite/ui/components/coral/foundation/fixedcolumns"                                 margin="{Boolean}true">                                 <items jcr:primaryType="nt:unstructured">                                     <column                                         jcr:primaryType="nt:unstructured"                                         sling:resourceType="granite/ui/components/coral/foundation/container">                                         <items jcr:primaryType="nt:unstructured">                                             <graniteExample1                                                 jcr:primaryType="nt:unstructured"                                                 sling:resourceType="granite/ui/components/coral/foundation/form/textfield"                                                 fieldDescription="Just an example"                                                 fieldLabel="graniteExample1"                                                 name="./graniteExample1"                                                 required="{Boolean}false"/>                                         </items>                                     </column>                                 </items>                             </columns>                         </items>                     </tab1>                     <tab2                         granite:class="cq-dialog-stylesystem-tab-showhide"                         jcr:primaryType="nt:unstructured"                         jcr:title="Tab 2"                         sling:resourceType="granite/ui/components/coral/foundation/container"                         margin="{Boolean}true">                         <items jcr:primaryType="nt:unstructured">                             <columns                                 jcr:primaryType="nt:unstructured"                                 sling:resourceType="granite/ui/components/coral/foundation/fixedcolumns"                                 margin="{Boolean}true">                                 <items jcr:primaryType="nt:unstructured">                                     <column                                         jcr:primaryType="nt:unstructured"                                         sling:resourceType="granite/ui/components/coral/foundation/container">                                         <items jcr:primaryType="nt:unstructured">                                             <graniteExample2                                                 jcr:primaryType="nt:unstructured"                                                 sling:resourceType="granite/ui/components/coral/foundation/form/textfield"                                                 fieldDescription="Just an example"                                                 fieldLabel="graniteExample2"                                                 name="./graniteExample2"                                                 required="{Boolean}false"/>                                         </items>                                     </column>                                 </items>                             </columns>                         </items>                         <granite:data                             jcr:primaryType="nt:unstructured"                             showTabOnAppliedCssClass="show-tab-two-now"                             tabTitleName="Tab 2"/>                     </tab2>                     <tab3                         jcr:primaryType="nt:unstructured"                         jcr:title="Tab 3"                         sling:resourceType="granite/ui/components/coral/foundation/container"                         margin="{Boolean}true">                         <items jcr:primaryType="nt:unstructured">                             <columns                                 jcr:primaryType="nt:unstructured"                                 sling:resourceType="granite/ui/components/coral/foundation/fixedcolumns"                                 margin="{Boolean}true">                                 <items jcr:primaryType="nt:unstructured">                                     <column                                         jcr:primaryType="nt:unstructured"                                         sling:resourceType="granite/ui/components/coral/foundation/container">                                         <items jcr:primaryType="nt:unstructured">                                             <graniteExample3                                                 jcr:primaryType="nt:unstructured"                                                 sling:resourceType="granite/ui/components/coral/foundation/form/textfield"                                                 fieldDescription="Just an example"                                                 fieldLabel="graniteExample3"                                                 name="./graniteExample3"                                                 required="{Boolean}false"/>                                         </items>                                     </column>                                 </items>                             </columns>                         </items>                     </tab3>                     <styletab                         jcr:primaryType="nt:unstructured"                         sling:resourceType="granite/ui/components/coral/foundation/include"                         path="/mnt/overlay/cq/gui/components/authoring/dialog/style/tab_edit/styletab"/>                 </items>             </tabs>         </items>     </content> </jcr:root>

7. Create a “_cq_design_dialog” folder under /apps/sourcedcode/components/examplecomponent
8. Create a “.content.xml” file under /apps/sourcedcode/components/examplecomponent/_cq_design_dialog with the file contents below:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

   <?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:granite="http://www.adobe.com/jcr/granite/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"     jcr:primaryType="nt:unstructured"     jcr:title="Example Component"     sling:resourceType="cq/gui/components/authoring/dialog">     <content         jcr:primaryType="nt:unstructured"         sling:resourceType="granite/ui/components/coral/foundation/container">         <items jcr:primaryType="nt:unstructured">             <tabs                 jcr:primaryType="nt:unstructured"                 sling:resourceType="granite/ui/components/coral/foundation/tabs"                 maximized="{Boolean}true">                 <items jcr:primaryType="nt:unstructured">                     <styletab                         jcr:primaryType="nt:unstructured"                         sling:resourceType="granite/ui/components/coral/foundation/include"                         path="/mnt/overlay/cq/gui/components/authoring/dialog/style/tab_design/styletab"/>                 </items>             </tabs>         </items>     </content> </jcr:root>

9. You are now done with the creation of the example component.

B. Create Sling Model for the Example Component

This is a very simple implementation for a sling model for the Example Component. The reason why we need to setup the Sling Model backend for our component because we need to obtain the “appliedCssClassNames” property from the configured component, which is configured by the content authors. If you have not already, please take a look at the pre-requirements section of this website, where calling the model.json of this particular component should expose the “appliedCssClassNames” which is vital for this solution to work. Implementing com.adobe.cq.wcm.core.components.util.AbstractComponentImpl is a best practice of the WCM Core Components where it promotes new features like the data-layer, and should be apart of your development tool kit when developing more modern AEM components.

Next, the sling model must declare the org.apache.sling.models.annotations.Exporter annotation, so model.json can be called upon for the particular component; like http://localhost:4502/content/sourcedcode/test/_jcr_content/root/container/container/examplecomponent_536346544.model.json.

Being able to resolve .model.json is vital for the hide or show Touch UI tabs for a particular component based on which style system is selected to work.

C. Create the Touch UI custom JavaScript implementation

You will be creating a clientlib-author Client Library which will be executed inthe editor.html authoring page. The Javascript should be executed upon opening up a Touch UI dialog.

Please note that all files created should be placed under: /ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs/clientlib-author

1. Create the “clientlib-author” folder under /ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs
2. Create a “.content.xml” file under /ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs with the file contents of:
   To understand how to add a Custom Client Library for AEM Author Editor Touch UI, click here.

   1 2 3 4 5

   <?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"     jcr:primaryType="cq:ClientLibraryFolder"     categories="[cq.authoring.editor.sites.page.hook]"     dependencies="[cq.authoring.editor.sites.page]"/>

3. Create the “js” folder under /ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs/clientlib-author
4. Create a file named “stylesystem-tab-showhide.js” with the contents inside:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76

   /**     * Author: Brian Kasing Li @ https://www.linkedin.com/in/briankasingli     * Documentation: https://sourcedcode.com/blog/aem/aem-touch-ui-show-hide-tabs-by-style-system-configurgation      **/ (function (document, $) {     "use strict";     var CONST = {         TARGET_GRANITE_CLASS: '.cq-dialog-stylesystem-tab-showhide',         GRANITE_DATA_PROP_TAB_TITLE_NAME: 'tabtitlename',         GRANITE_DATA_PROP_SHOW_TAB_ON_APPLIED_CSS_CLASS: 'showtabonappliedcssclass',         APPLIED_CSS_CLASS_NAMES: 'appliedCssClassNames',     }     /**      * foundation-contentloaded      * adding event listener to the Touch UI popup, so when the Touch UI is envoked, the code in will be executed.      * - initially, any TouchUI tabs which includes granite:class="cq-dialog-stylesystem-tab-showhide" will be hidden.      * - upon response from the .model.json ajax request, we will showTabs based on what's configured for "tabtitlename" and "showTabOnAppliedCssClass".      *      * @returns void      */     $(document).on("foundation-contentloaded", function (e) {         if ($(e.target).prop('tagName') === 'CORAL-DIALOG') {             hideTabs($(e.target));             var url = $(e.target).find('.cq-dialog').attr('action') + ".model.json";             $.getJSON(url, function(data) {                 if (data[CONST.APPLIED_CSS_CLASS_NAMES]) {                     showTabs($(e.target), data[CONST.APPLIED_CSS_CLASS_NAMES]);                 }             });         }     });     /**      * this finds all Touch UI fields with the cssClass .cq-dialog-stylesystem-tab-showhide, which should be found as an attribute      * under sling:resourceType="granite/ui/components/coral/foundation/container", which "hides" all tab options from the authors.      * @returns void      */     function hideTabs($parentEle) {         $parentEle.find(CONST.TARGET_GRANITE_CLASS).each(function() {             var $this = $(this);             var tabtitlename = $this.data(CONST.GRANITE_DATA_PROP_TAB_TITLE_NAME);             $('._coral-Tabs-itemLabel').each(function(i) {                 if ($(this).html() === tabtitlename) {                    $(this).closest('coral-tab').hide();                 }             })         });     }     /**      * after a successful response of the .model.json ajax request,      * this finds all Touch UI fields with the cssClass .cq-dialog-stylesystem-tab-showhide, which should be found as an attribute      * under sling:resourceType="granite/ui/components/coral/foundation/container". Based on the set properties of      * granite:data values set for "tabtitlename" and "showTabOnAppliedCssClass", the matched tabs will be "visible" from the authors.      *      * @returns void      */     function showTabs($parentEle, appliedCssClassNames) {         $parentEle.find(CONST.TARGET_GRANITE_CLASS).each(function() {             var $this = $(this);             var tabtitlename = $this.data(CONST.GRANITE_DATA_PROP_TAB_TITLE_NAME);             var targetappliedcssclass = $this.data(CONST.GRANITE_DATA_PROP_SHOW_TAB_ON_APPLIED_CSS_CLASS) || 'INVALID_APPLIED_CSS_CLASS';             if (!appliedCssClassNames.split(' ').includes(targetappliedcssclass)) {                 $('._coral-Tabs-itemLabel').each(function(i) {                     if ($(this).html() === tabtitlename){                         $(this).closest('coral-tab').show();                     }                 })             }         });     } })(document, Granite.$);

5. Create a “js.txt” file under /ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs with the file contents of:

   1 2	#base=js stylesystem-tab-showhide.js

6. You are now finished creating the clientlib-author client library.

D. Finally, test it out.

1. Edit the component policies within the editable template, to include a style system class of “show-tab-two-now”
2. Edit a page of your choice, and drag the Example Component into the page
3. Configure the component to add style system “show-tab-two-now” for the given component
4. Note: if “show-tab-two-now” is not an option as a Style System for your current component, then you must add some policies for your component.
5. Now you should see Tab 2 visible.
6. Done

E. Configuration Explanation of the Touch UI Granite Tab Fields

After the installation of the client library custom code, you should be able to start adding properties to your Touch UI code, for this feature, like the screenshot below:

Indicating in the screenshot above, you have realized that we are introducing granite:class=”cq-dialog-stylesystem-tab-showhide”line:43 which will be placed at the root level of the tab XML structure; when this property is placed, when author initially call the TouchUI popup, all tabs with this granite:class will be hidden. Inside of the tab XML structure, we introduced a new node configuration, line:70,as granite:data, which introduced two new properties.

The granite:data has two properties that will determine which tab to show, and also which option of style system has been configured, so we can show the tab as expected.

Note:, since we are using the granite namespace, you need to ensure your XML declaration for the Touch UI includes: xmlns:granite=”http://www.adobe.com/jcr/granite/1.0″. You can see this example from the Touch UI code configuration that we have installed line:2 in our code examples.

properties:

• tabTitleName: the exact name of the tab (jcr:title). Taking a look at the screenshot above line:73 this property matches exactly what is under line:43, the jcr:title.
• showTabOnAppliedCssClass: this is the CSS class name that has been configured by the content authors via AEM’s style system; this field must match exactly to the style system CSS class that has been configured by the component policies. The CSS class set here is the target’s the Style System CSS class name that should make the table visible when matched.

Summary

Please understand that even if the tabs are hidden from the Touch UI, the existing properties that are already content authored without this feature will not be removed as expected, and Sightly may continue to render content on the page; this means that… if for example, I have the style system enable or disable the Touch UI checkbox to “open new tab”. if this field was already content authored… and this custom code hide’s the field… since the already configured component’s property is still persisted, your Sightly may be still opening the button in a new tab.

To ensure that if a style system is enabled, and you do not want Sightly to render some items on the page, you will need to make some changes to the code itself.

The post AEM Touch UI Show Hide Tabs by Style System Configuration appeared first on Sourced Code.

As you may recall, when you want to add custom functionality or styling to the Touch Dialogues (in edit author mode, editor.html), we must include cq.authoring.editor.sites.page as a dependency and cq.authoring.editor.sites.page.hook as a category to our client library’s configuration. The configuration would look something like this:

This configuration above will evoke the client library every time the Touch UI dialogue is triggered, for all components. Illustrated above, from the author (editor.html), clicking on any component throughout the entire AEM platform, will invoke the client library.

Benefits of using cq.authoring.editor.sites.page:

1. Client libraries created like this will be invoked for all components (when the Touch UI is open)

But however, what happens if you only want your custom functionality or styling to be only called by ONE component? Well, we use the extraClientlibs property from the component’s Touch UI dialogue.

Illustrated above, you will notice that adding String[] extraClientlibs to the cq:dialog (root node) of the component, the client library will only be invoked, only targeting the Touch UI dialogue that is associated to a specific component.

Benefits of using extraClientlibs:

1. Touch UI will only invoke the targeted client library that is configured.
2. Client libraries can be created to be specifically used for a particular component.

Example of usage of extraClientlibs in line:6

The post What are AEM ExtraClientlibs? appeared first on Sourced Code.

Apparently the Granite UI 1.0 documentation for the granite/ui/components/coral/foundation/form/numberfield, does not support default value configuration for the numberfield. Keep reading…

I mean, they do… you can set a default value for the granite/ui/components/coral/foundation/form/numberfield by setting the value property with a positive or negative integer; this works well when a new component is dragged into your editable page, but components that are already exist in the authored page will not be able to set this default value.

This is an example of the Touch UI XML configuration, set with the value of 100; this works well when a new component is dragged into your editable page, but components that are already exist in the authored page will not be able to set this default value. This is a problem for existing components because this configuration will set the value to BLANK, when the component is being saved.

Follow this blog below to solve this problem.
Here you can see line:9 it has a value set to 100.

Example of existing components not able to make visible, the value property (default value); however, for all new components that are dragged on the page, the default value is set accordingly.

Solving this problem with Custom Code

We can solve this problem by introducing a new client library to the author’s editor.html. The client library should have dependencies=”[cq.authoring.editor.sites.page] and categories=”[cq.authoring.editor.sites.page.hook].

What is actually happening in the code below is that it tries to find all coral3-NumberInput, input fields, from the Touch UI popup. And then, for each input field element, wether if the element is empty and has a non-empty data-default value (HTML data attribute). When this condition is met, the empty input field will set the defaultValue. If a value exists for the input field element, it will be left alone.

The code is very simple, take a look at the implementation below:
Custom JavaScript to the editor.html

XML Touch UI configuration
Please notice the granite:data field that has been added from line 9-11. The custom JavaScript will read the defaultValue property from this block of code, and will use it to configure the default integer for this field.

Example of existing components now able to set the default value accordingly.

Installing the Custom Code to the Editor.html

Step 1.
Create a new folder in your project like
path: /apps/sourcedcode/clientlibs/clientlib-authoring-numberfield-example

Step 2.
Create an .content.xml file right under the folder with contents like:
path: /apps/sourcedcode/clientlibs/clientlib-authoring-numberfield-example/.content.xml

Step 3.
Create an empty css.txt file right under the folder like:
path: /apps/sourcedcode/clientlibs/clientlib-authoring-numberfield-example/css.txt

Step 4.
Create a js.txt file right under the folder like below with the contents:
path: /apps/sourcedcode/clientlibs/clientlib-authoring-numberfield-example/js.txt

Step 5.
Create an empty js folder under that folder that just have been created like:
path: /apps/sourcedcode/clientlibs/clientlib-authoring-numberfield-example/js

Step 6.
Create a JavaScript file within the js folder with the contents:
path: /apps/sourcedcode/clientlibs/clientlib-authoring-numberfield-example/js/granite-ui-numberfield-default-value.js

Step 7.
Use your maven skills to push the code into AEM.

The post AEM Granite UI Coral 3 Number Field Default Value appeared first on Sourced Code.

We must register a client library specifically targeting the author, which is specific to customizing page authoring, which will inject JavaScript into the context of the page and execute the registry and scripts.

Follow the steps below to have this setup

Step 1

In your repository, create a new client library folder under your brand’s /apps/clientlib folder like:
path: ./sourcedcode/ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs/clientlib-author

Step 2

In the newly created folder, create an .content.xml file and include the text found below:
path: ./sourcedcode/ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs/clientlib-author/.content.xml

This method is specific to customizing page authoring in AEM, for more information about this topic, click here.

Step 3

In the newly created folder, create an js folder (leave this empty).
path: ./sourcedcode/ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs/clientlib-author/js

Step 4

In the newly created js folder, create a file named granite-ui-multifield-max-items.js and paste in the JavaScript found below:
path: ./sourcedcode/ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs/clientlib-author/js/granite-ui-multifield-max-items.js

Step 5

In your repository, create a css.txt and js.txt file
path: ./sourcedcode/ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs/clientlib-author/css.txt

path: ./sourcedcode/ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs/clientlib-author/js.txt

A valid client library must include these two files.

Step 6

Edit the js.txt file to include:

path: ./sourcedcode/ui.apps/src/main/content/jcr_root/apps/sourcedcode/clientlibs/clientlib-author/js.txt

Step 7

Edit your Granite UI Multifield component to include two new properties:
granite:class=”granite-ui-validation-multifield-max-items”
validation=”max-items-2″

Example: In this example, we have ensured that the maximum items that can be used in the multifield is 2 items.

Step 8

The Granite UI Multifield validation should be working as expected.

The post AEM Granite UI Multifield Maximum Items Validation appeared first on Sourced Code.

Click on this link for exactly how this can be set up, https://sourcedcode.com/blog/aem/adding-custom-client-library-for-aem-author-editor-touch-ui

Usecases for adding custom CSS or JavaScript to the editor.html would be:

1. Including custom styling from the UI for the Granite UI fields.
2. Including custom Granite UI JavaScript validations such as richtext maximum characters or multifield maximum items.
3. Including custom processes such as deleting component properties based on Granite UI configurations.
4. Including JavaScript injections into a page based on the window.location.pathname or searchParams.

All in all, the sky is the limit on customizations that you can add to the editor.html. Click on this link for exactly how this can be set up, https://sourcedcode.com/blog/aem/adding-custom-client-library-for-aem-author-editor-touch-ui

The post Add AEM Custom Frontend CSS JavaScript Editor.html appeared first on Sourced Code.

Going through this article, we will be setting up multifield Granite UI links (as if we are building a menu navigation). Each link will define it’s own path, label, and target. Take a look at both screenshots below. One screenshot indicates how a multifield Granite UI field will look like, and in the second screenshot displays how saved nodes would look like in the crx/de console.

Step 1. Touch UI Configuration

Putting together a very basic Touch UI configuration using tabs to organize our Granite UI fields. Here we will place the entire configuration under:
/apps/sourcedcode/components/content/multilistexample/_cq_dialog/.content.xml.

line: 34, declaring a multifield
line: 42, declaring multifield > label
line: 48, declaring multifield > path
line: 55, declaring multifield > target

Step 2. Sightly HTL Front-end

A very simple way to get a list of objects to iterate through will be to use Sling Model’s backend and Sling Specific Annotations. Together the mechanism combined will enable the Sightly HTL code to receive a List, which you can use this list to iterate through each item, to display nav link configurations that were set by the authors.

Using the Sightly data-sly-list API, we can traverse through each item from the List. Iterating through each item returns an Resource.class onbject, which it has a getValueMap() public getter method. With this getter method we can get the valueMap object and reveal the configurations that are set by the authors.

Step 3. Sling Model Java Backend

Sling Model’s backend and Sling Specific Annotations. Together the mechanism combined will enable the Sightly HTL code to receive a List.

Step 4. Results

Work your maven magic, and build the code. Once your backend bundle and Sightly HTL code are aligned, you should be able to see the links like here in the screenshot.

The post Granite UI Multifield Sightly Traverse | Iterate Simple Example appeared first on Sourced Code.

Specifically, when you want to add CSS or JavaScript to your AEM Author Editor, Touch UI Dialogs, you would want to create a new client library. Within your clientlib, it must have the required dependencies and categories.

The custom clientlib for AEM authoring must follow these rules:

1. depend on the authoring clientlib cq.authoring.editor.sites.page
2. be part of the appropriate cq.authoring.editor.sites.page.hook category

Example

An example of a custom client library created for AEM authoring would live in this path (below), and must have the .context.xml configured like so.
/apps/sourcedcode/clientlibs/clientlib-authoring

The post Adding Custom Client Library for AEM Author Editor Touch UI appeared first on Sourced Code.

Introducing the DRY way of using RichText Granite UI Component in AEM for Static Templates, which is an article for how developers can write better and reusable code for Touch UI (Granite UI) configuration.

The blog article specifically focuses on the Rich Text Granite UI Component, configuration once, and then reuse it over and over again. The same methodology can be applied to all other Granite UI Component configurations; checkbox, select, color picker, text, etc… This is great because if there is a requirement, for example, to add in a new styles option, you can make the change once, and all other Granite UI Component configurations will pick this change up.

Visit the DRY way of using RichText Granite UI Component in AEM for Static Templates

The post How to Write AEM Reusable Touch UI, Granite UI Configuration appeared first on Sourced Code.

While utilizing the ACS Commons multi-field extension, for everything I tried, I am not able to get the checkbox Granite UI component working as expected. Not an elegant way to solve the problem, but something that actually works and is sustainable.

I found a solution that is simple. Instead of using the checkbox Granite UI Component, use the select Granite UI Component, granite/ui/components/coral/foundation/form/select. This works; problem solved.

Not Working Checkbox

As you can see here, in line:24, the acs-commons-nested property is not picking up the Granite UI Component, checkbox.

Solved: Working Boolean

In line:24, replacing the checkbox with the select Granite UI Component, solves the issue.

The post ACS Commons multi-field extension, acs-commons-nested, checkbox is not working appeared first on Sourced Code.

In this article, we will step through my implementation for us to remove the p tag once and for all, from being rendered.

My solution to this problem will be dealt with in the backend, Sling Model. Some may argue that the solution can be done using Javascript, but that can be very troublesome. Let’s Keep it Simple Stupid (KISS). There’s one caveat to this approach; scroll to the bottom of the page to see what it is.

Follow my 3 steps below to remove the P tag wrapper from what is being produced by the cq/gui/components/authoring/dialog/richtext.

Step 1. Add Custom Option In the Paraformat Options

Under the _cq_dialog.xml, cq/gui/components/authoring/dialog/richtext, add a new format option under the paraformat list of options.

The selected paraformat option will be a custom HTML element that wraps onto the highlighted or selected text from the author. In this case, when the author have selected text, and then click on the new paraformat option, the Html will look something like this <notextformat>sometext</notextformat>.

Step 2. Create the Backend, Sling Model, to Text Transform

The backend Sling Model will read the ./text property that has been set by the user’s input. Using the String.ReplaceAll(), we can replace all </?notextformat>, regex pattern, with nothing (meaning that this element will be removed).

For example <notextformat>sometext</notextformat>. -> sometext.

We next save the formatted text into a variable of , which can be used by sightly to display HTML on the page.

Step 3. Render Text Transform from Sightly

Now finally we just need to utilise sightly to print the text transformed, richText, to the screen.

The post AEM RichText Remove P Tag, removeSingleParagraphContainer, for Touch UI appeared first on Sourced Code.

As AEM developers we are summoned to enable and deliver this requirement. In this article, I will provide a code example on how we can enable the code editor for the rich text editor. Technically, we call this feature the source edit when referring to this feature from the rtePlugins.

The source edit feature is actually a feature from the misctools rtePlugin. Simply add the rtePlugins > misctools with the feature set as sourceedit. Next add the toolbar configuration value of misctools#sourceedit, for the inline && dialogFullScreen node. See the code example below.

For sightly, make sure you use the context attribute, ${properties.text @ context=’html’}

The post AEM RichText TouchUI, Enabling Code Editor, Source Edit appeared first on Sourced Code.

Enabling only the “links*” and “format*” richtext features, we catch ourselves repeating lines of code by copying and pasting the entire block of code for all of our Touch UI dialogues that require the richtext requirement. This works, but this is Write Everything Twice, “WET” code, and it’s not good implementation; this can be improved. What happens if there is a new requirement where the authors would like a new capability to the richtext field? Will we have to edit multiple dialogues? (like editing 20 component’s dialogues) The short answer is Yes. With this “WET” implementation, you must edit every single component’s dialogue configuration.

How can we do this better? How keep our code Don’t Repeat Yourself (DRY)?

Utilising the Granite UI component, granite/ui/components/coral/foundation/include, we are able to refer to common Granite UI component configurations in the JCR (that we are going to set up). Now changing the richtext configuration in one place will provide TouchUI dialogue changes to all 20+ components; see diagram below.

Advantages of using common richtext configurations

• Ease to read and maintain
• Reusability of the code
• Reduces uneseccary lines of code in the repo
• common Granite UI configs are easily accessible to manipulate

With the improvement, with the diagram above, you will notice multiple AEM components’ Touch UI dialogue utilises the common Granite UI component configuration in the JCR, for the richtext Granite UI component configurations.

The Implementation

In this section, code will be shared on how this configuration can be applied to your own AEM implementation. The example produced will be a summary of the diagram from above.

1. Register the common dialog namespace

We typically place the common Granite UI component configurations for “content TouchUI” in the JCR under a namespaced project, for example: /apps/sourcedcodeaem/components/dialogs/content/common.

You will notice that there are already 3 folders that I have created.

1. fields – fields that are commonly used by Touch UI dialogue configs (for this article we will only be focusing on these configs)
2. fieldsets – fieldsets that are commonly used by Touch UI dialogue configs; these consist of more than 1 Granite UI component which is wrapped around a granite/ui/components/foundation/container.
3. tabs – tabs that are commonly used by Touch UI dialogue configs; these consist of more than 1 Granite UI component which is wrapped around a granite/ui/components/foundation/container.

2. Create and configure the common Granite UI component configurations, under the “fields” structure

/apps/sourcedcodeaem/components/dialogs/content/common/fields/_cq_dialog/.content.xml

3. From the targeted component, include the common Granite UI config

/apps/sourcedcodeaem/components/content/announcement

4. Done

Now we have successfully referenced an AEM component to the common Touch UI dialogue field.

The post DRY way of using RichText Granite UI Component in AEM for Static Templates appeared first on Sourced Code.

In this article, we will be putting together a centralized configuration for color options that can be used by any Touch UI configuration throughout our AEM project utilizing the ACS Common’s Generic Lists. This tutorial will assume that you have your IDE opened, so you can copy and paste code to test.

What is ACS Commons Generic Lists?

Content authors can amend and manage the list at any time, as long as they have permissions to /etc/acs-commons/lists/* they can make changes immediately.

When saving a selected value from the ACS Common’s Generic List datasource, the value will is copied and set in the components property. So you can imagine, the set value is not a reference but the value itself.

Implementation

In this part of the article, we will be going to step by step, creating a new generic list to hold our shared color options. Then we will set up our Touch UI component, and finally, show you how to amend the list in the author view.

1. Create the ACS Commons Generic List

Create a folder structure of /etc/acs-commons/lists/customcolors/.content.xml. Use the configuration as indicated below. Here you can see that we are creating a new page (ACS Common’s standards) with a parsys which is used to hold a collection of generic list items.
File: /etc/acs-commons/lists/customcolors/.content.xml

2. Insert the Granite UI snippet in the Touch UI Dialogue

Once when ACS Commons Generic List is created, we use this code snippet to dynamically display all the options that will be available in the drop-down. In particular take a look at the <datasource>, as this is where all the magic happens. We are setting the path to the list that we have just created, while the sling:resourceType is acs-commons/components/utilities/genericlist/datasource.
Snippet Example:

Touch UI Completed Example: