1. Element and Attribute Visibility

When using the data-sly-attribute directive, it’s important to understand how it affects the visibility of elements and their attributes:

Element Visibility: The HTML element to which the data-sly-attribute directive is applied will always be rendered in the DOM. This means that the element itself will always be visible, regardless of the attributes set or not set by the directive.

Even if dynamicClass is empty or undefined, the paragraph will still appear in the DOM.

Element Content: The content inside the HTML element will also always be displayed. The data-sly-attribute directive only affects the attributes of the element, not its content. This ensures that the inner content remains intact and visible to the users.

Even if dynamicId is empty or undefined, the text “Content remains visible” will still be displayed within the span element.

2. Attribute Value Options

The attribute value in data-sly-attribute is optional and can be of different types:

String: Used to set the content of the attribute.

Example:

Boolean: Used for setting boolean attributes.

Example:

Object: Used for setting multiple attributes simultaneously.

Example:

If the attribute value is omitted, the attribute will be removed.

3. Attribute Identifier

The attribute identifier, which is the name of the attribute, is also optional. It must be omitted only if the attribute value is an Object.

Detailed Explanation:

When using the data-sly-attribute directive, you can specify the name of the attribute you want to set. This is called the attribute identifier. However, when you are using an Object to set multiple attributes at once, you do not need to specify individual attribute names.

Code Examples:

Specifying Attribute Identifier:

When setting a single attribute, you provide the attribute name directly.

Omitting Attribute Identifier (Using an Object):

When setting multiple attributes simultaneously, you use an Object and omit the attribute name.

In this case, the keys of the Object (id and class) are used as attribute names, and their corresponding values (dynamicDiv and dynamicClass) are assigned to those attributes.

4. Using `data-sly-attribute`

You can define attributes either directly through an expression or by using a data-sly-attribute.* attribute. This approach allows designers to annotate HTML without modifying the mock content.

Example: Overwriting an Attribute

Example: Creating a New Attribute

5. Injecting Multiple Attributes

The data-sly-attribute block element, when used without specifying an attribute name, allows the injection of multiple attributes that have been prepared in a map object containing key-value pairs.

Example: Injecting Multiple Attributes

6. More Examples

Example: Setting Multiple Attributes on a Button

Example: Conditional Attribute Setting

Conclusion

The data-sly-attribute directive in HTL provides a versatile way to manage HTML attributes dynamically. Whether you’re setting a single attribute or multiple attributes at once, this feature can help you create more dynamic and flexible web components. By leveraging data-sly-attribute, you can ensure that your HTML remains clean and maintainable, while still being able to handle complex attribute logic.

Feel free to explore and use these examples to enhance your AEM projects, making your components more dynamic and interactive.

The post Understanding `data-sly-attribute` in AEM Sightly (HTL) appeared first on Sourced Code.

As per this article is written, Sightly is versioned as 1.4. If you wish to find out what version sightly your AEM environment is using, you can refer to this article here, which it will explain you how to find out the Sightly Version.

If you want to dive straight into the official documentation, you can access it on GitHub:
AEM Sightly Documentation

The post AEM Sightly Official Documentation: Everything You Need to Know 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 on Sightly appeared first on Sourced Code.

In the Adobe Core Component’s Library, you will be able to find this particular file “core/wcm/components/commons/v1/templates.html“. This file is a template that renders an HTML element on the page with the “cq-placeholder” cssClass that makes the rendered element on the page look something like this.

When we inspect the Adobe code, you will see the sightly HTL code as like this:

We understand that we are using Sightly HTL Version: 1.4; where this version enables the feature “template & calls”, and templates. From the code above, you can see that “core/wcm/components/commons/v1/templates.html” is a Sightly template, and its main purpose is to be called via “data-sly-use”. Line-1: This template accepts 3 parameters: isEmpty, classAppend, emptyTextAppend. Line-2: This template is declaring a new div, and only rendered when (edit or preview mode) and isEmpty = true. Line-3: This appends the cq-placeholder cssClass for this <div>, and include custom ${classAppend} if exists. Finally Line-4: renders the resource’s component.properties.jcr:title (component who calls this script) on the screen, and also appends ${emptyTextAppend} to the cq-placeholder’s text if present.

Examples:

1. Basic call example to “core/wcm/components/commons/v1/templates.html”

In this example, you can see us calling the Sling Model backend “com.sourcedcode.core.components.models.Teaser”, and capturing the Sling Model in a “model” variable. Line-3, we understand that the templates.html is accepting the “isEmpty” parameter. The “isEmpty” parameter is evaluated with “!model.titleText” (this means if the model.titleText is empty or null it will return true). When “isEmpty” is true, then the cq-placeholder will be rendered, and if false. It will never be rendered.

2. Second example to “core/wcm/components/commons/v1/templates.html”

In this example, Line-3, you will notice that model.titleText && model.descriptionText are being evaluated, and must not be null or empty. If the evaluation of isEmpty is true, cq-placeholder will be visible.

3. Third example to “core/wcm/components/commons/v1/templates.html”

In this example, Line-3, notice that we are using other parameters to construct the cq-placeholder; classAppend, where we are passing in cmp-teaser as a customCSSClass. Line-4, we are utilizing the parameter, emptyTextAppend, where we can add custom description to the cq-placeholder. The expected behavior here is, when the evaluation of isEmpty is true, we expect to see the rendered cq-placeholder with some description test. See the screenshot below for an example.

The post AEM Sightly Component(s) Empty CQ PlaceHolder appeared first on Sourced Code.

With the leverage of the org.apache.sling.jcr.api v2.4.0 bundle provided by AEM 6.5.4+ or AEM as a Cloud Service, we are able to utilize the Repository Initialization (repoinit) feature. At the start of this article, we will quickly provide a review of what a system user is, next we will explain what actually is the Repository Initialization (repoinit) feature and it’s dependencies, and finally, we will be providing some code examples on how to setup this feature on your own AEM instance with a code follow through.

AEM System Users are also referred as Service Users.

1. AEM System User Quick Review

Before we begin, let’s reiterate what a System User in AEM is. A system user is a JCR user with no password set and a minimal set of privileges that are necessary to perform a specific task. Having no password set means that it will not be possible to login with a system user. A system user is typically utilized by the AEM backend code which have privileges to create, read, update, and delete nodes in the JCR; the backend code will authenticate as a system user as a session when needed, and is required to session logout right when the task or tasks have been completed. Not logging out of a system user from the AEM backend will cause issues. If you do not logout of a session that you have opened, your AEM will be flooded by opened sessions, your AEM will start complaining with *INFO* [Apache Sling Resource Resolver Finalizer Thread] org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl Unclosed ResourceResolver, and eventually your AEM environment will run out of memory and crash; to learn more about this topic, take a look at this blog article, ResourceResolvers and Sessions — “you open it, you close it”, by Jörg Hoh. The rule of thumb for creating System Users is to keep the privileges very specific; ensure you have a plan for this system user.

2. What Is Repository Initialization (repoinit)?

Sling RepoInit is a mechanism that allows configuration code to run before the SlingRepository service is registered. Configuration code is registered under the org.apache.sling.jcr.repoinit.RepositoryInitializer factory PID, and written in a mini-language.

The org.apache.sling.repoinit.parser implements a mini-language meant to create paths, system users and manage access control in a content repository, as well as registering JCR namespaces, node types and privileges. Defining access control content consists of setting and deleting policies of type access control lists (ACL) for which individual access control entries (ACE) can be added and removed.

Full documentation found here.

3. AEM Dependencies for the Repository Initialization Feature(Sling RepoInit)

To be able to use this feature, you must have AEM 6.5.4+ or AEM as a Cloud Service.

From out of the box AEM 6.5, it already includes a version of Sling RepoInit, but this is likely an older version without the service pack. If you are not able to replicate the code follow through mentioned on this article, consider upgrading your AEM service pack to the supported version AEM 6.5.4+. Take a look at my bundle versions found in /system/console/bundles (as these installed versions are working as expected on my machine):

• org.apache.sling.jcr.api @ 2.4.0
• org.apache.sling.jcr.repoinit @ 1.1.28
• org.apache.sling.repoinit.parser @ 1.6.2

4. Code Follow Through

In the code follow through, you will create a system user with code configurations. Next, with the system user, you will write code for a simple AEM Servlet which will be a GET request, which will write a new property into an existing node in AEM.

A. Configure org.apache.sling.jcr.repoinit.RepositoryInitializer PID

With the org.apache.sling.jcr.repoinit.RepositoryInitializer factory PID, we will be creating a new configuration file.

With this configuration, we are creating a system user named sourcedCodeSystemUser, and will be placed into the folder structure of /home/users/system/sourcedCode. The system user, sourcedCodeSystemUser, will have ACL (Access Control List) privileges configured to:

• allow read,write,replicate for all JCR resources which exists under /content/sourcedcode
• allow read,write,replicate for all JCR resources which exists under /conf/sourcedcode
• allow ALL-CRUD-ACTIONS for all JCR resources which exists under /content/we-retail

filename: /apps/sourcedcode/config/org.apache.sling.jcr.repoinit.RepositoryInitializer~sourcedcodeSystemUser.config

filename: /apps/sourcedcode/config/org.apache.sling.jcr.repoinit.RepositoryInitializer~sourcedcodeSystemUser.cfg.json

Such configurations have two optional fields:
A multi-value references field with each value providing the URL (as a String) of raw repoinit statements.
A multi-value scripts field with each value providing repoinit statements as plain text in a String.

B. Configure org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended PID

To add a mapping from your service to the corresponding System Users you need to create a factory configuration for the [ServiceUserMapper](https://sling.apache.org/apidocs/sling7/org/apache/sling/serviceusermapping/ServiceUserMapper.html) service. To keep this modular such configurations can be provided using the Sling amend mechanism.

Below, you will see us mapping the sourcedcode.core backend to the sourcedCodeSystemUser.

filename: org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-sourcedcodeSystemUser.config

C. Register Basic Servlet (GET Request)

line:38, we are creating the Map authInfo class with ResourceResolverFactory.SUBSERVICE set to the system user that we have just created, “sourcedCodeSystemUser”.

line:41, we will utilize the Java 7 API, “try-wth-resource”, best practice, to ensure that when we open a new session, we are never forgetting to close the session after the use of it; Since Sling9 (roughly 2016) the ResourceResolver interface implements the AutoCloseable marker interface, so the try-with-resource idiom can be used. Here we are obtaining the resolver via ResourceResolverFactory.getServiceResourceResolver() method.

line:42, we are adapting the resolver into a javax.jcr.Session.class.

line:44-50, we are getting the AEM JCR node, writing new properties to /content/sourcedcode/jcr:content, and replicating the node. And on succeess, we will return the message of “Test is saved and replicated”.

filename: sourcedcode/core/src/main/java/com/sourcedcode/core/servlets/SimpleGetServlet.java

D. Test and Validate the Servlet Response

Now use your maven skills to build the project!

Next, after a successful build, you would want to make a call to your AEM servlet, via http://localhost:4502/bin/simple-get. With the service system successfully configured in your environment, you should be able to see a successful message.

Test is saved and replicated.

Revealing the changes in the JCR content, http://localhost:4502/crx/de/index.jsp#/content/sourcedcode/jcr%3Acontent, you should be able to see the changes.

E. ServiceUser in UserAdmin

If you like, take a look at http://localhost:4502/useradmin. Search for the sourcedcodeSystemUser and review the permissions for this system user. You should be able to see permissions reflected for this system user:

• allow read,write,replicate for all JCR resources which exists under /content/sourcedcode
• allow read,write,replicate for all JCR resources which exists under /conf/sourcedcode
• allow ALL-CRUD-ACTIONS for all JCR resources which exists under /content/we-retail

This article covers questions like

• How to create AEM System User Programmatically
• How to create AEM System User Automatically
• How to create AEM System User on AEMaaCS
• How to create AEM System User with Code
• How to create AEM System User that is not manual
• How to create AEM System User the preferred way
• How to create AEM Service User Programmatically
• How to create AEM Service User Automatically
• How to create AEM Service User on AEMaaCS
• How to create AEM Service User with Code
• How to create AEM Service User that is not manual
• How to create AEM Service User the preferred way

Path not found by AEMaaCS

Sometimes you may find errors in the AEMaaCS pipelines due to the reason that when reference to path that you are allowing system user permissions to, path does not exist. And so, the node must declare creation of these path’s in the repo-init script. Although the path’s are already installed inside of AEM, it wouldn’t do anything anyways… this is to fix the repo-init system user pipeline errors.

Here’s an example of us creating a repo-init system user which allows permissions for the system user, and includes the creation of paths:

• allow jcr:all on /content/sourcedcode
• allow jcr:all on /conf/sourcedcode
• allow jcr:all on /content/dam/sourcedcode
• allow jcr:all on /content/cq:tags/sourcedcode

repoinit cfg json example for creating system user

filename: /apps/sourcedcode/config/org.apache.sling.jcr.repoinit.RepositoryInitializer~sourcedcodeSystemUser.cfg.json

The post Create System | Service Users in AEM 6.5 with Code Configurations appeared first on Sourced Code.

1. HTL comments are not evaluated and returned back as an empty string in the server-side rendered results.

This is best practice when developers are including some comments for other developers in their organization.

Sightly HTL comments combine HTML and JavaScript multi-line comments: <!–/* */–>

2. Standard HTML comments, the comments are evaluated and are server-side rendered with the expected results.

Available for HTML Template Language Specification 1.4
Release Date: 18 June 2018
Reference: https://github.com/adobe/htl-spec/blob/master/SPECIFICATION.md

The post AEM Sightly Comments with Examples 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.

A simple POJO can be used as a Java Use-API object, which is instantiated by a specific implementation using the POJO’s default constructor.

In this article, you will find an example of how the Java Use-API can be bind with a component in AEM. In detail, we will be associating the Java Use-API with the header component.

Java Use-API Example Code

Step 1

We will place a small little snippet from lines:2-4 which will bind into the simple POJO; inside of the given component,
/apps/sourcedcode/components/structure/header/header.html

Step 2

We will create a simple Java POJO under,
/apps/sourcedcode/components/structure/header/HeaderJavaUseExample.java

Taking a look closer, line:1 has the package that is the same path as the targeted component.

Step 3

The Java Pojo extends the WCMUsePojo which makes available all the Global Objects in this naming convention:

The post HTL Java Use-API Code Example appeared first on Sourced Code.

When considering ID, you might consider directly using the global HTL objects and getters, such as ${currentNode.name}. If the component is used in other containers on the same page, this will not, however, fix the issue. Despite the fact that the JCR node level API produces a distinct id for the current node, the id also includes the node path and forward slashes, exposing the internal content structure and making it challenging to utilize in CSS and JS without escaping.

The id element is made simple to use by CSS and JS by the hash code, which also encapsulates and hides internal path information from the end-user. The developer passes in the ID prefix to make the ID property easier for humans to read. Example code of a Java Sling Model class is provided below.

Sightly

Java Sling Model

Last Thoughts

You can improve this setup by adding an “advanced” tab in the component’s Touch UI dialog to have authors insert their own custom component ID. If the author’s configuration is empty, this mechanism will be kicked in to use the ComponentId Sling Model to generate the Ids.

The post How to Generate Unique AEM Component ID with Confidence appeared first on Sourced Code.