In this example, we use the ‘js-cookie’ library to handle cookies in a simplified manner. The Cookies.get(‘cq-authoring-mode’) function retrieves the value of the ‘cq-authoring-mode’ key from cookies. If the key exists, the JavaScript logic exits gracefully. Otherwise, you can proceed with implementing your custom functionality.

Benefits of Customized JavaScript in AEM Editor

1. Context-Aware Functionality: By checking for specific conditions, such as the presence of a key in cookies, developers can implement context-aware functionality tailored to the AEM authoring environment.
2. Enhanced Authoring Experience: Custom JavaScript allows for the augmentation of the authoring experience by introducing features that streamline workflows and improve usability for content authors.
3. Graceful Handling of Conditions: Checking for the existence of keys in cookies enables developers to gracefully handle conditions, ensuring that the JavaScript logic behaves appropriately in different scenarios.

Conclusion

Mastering the art of writing JavaScript for the AEM Author Environment empowers developers to create a tailored experience purely for the authoring environment. By incorporating checks for specific conditions, such as cookie existence, developers can introduce intelligent and context-aware functionalities that enhance the content creation process. The provided code snippet serves as a starting point for customizing JavaScript in the AEM Author Environment, offering a foundation for further innovation and optimization.

The post Execute JavaScript in the Author Environment for AEM Components AEM 6.5+ appeared first on Sourced Code.

Within our VueJS application, we have a utility named i18n.js, the file looks like this (code below). Throughout application, we will call this util i18n(function) to get values from our i18n AEM dictionary.

When we test out the micro-frontend, we noticed that sometimes the window.Granite, AEM global object, is intermittently working; sometimes the window object is valid/not, so dictionary values are loaded, and sometimes they are not. Why window.Granite is sometimes undefined? Well, this looks like a race condition issue.

How can we ensure window.Granite is loaded first before our application is loaded next? In the next section let’s look at the different ways to see how we can do this.

Solutions

1. Manually Invoking the i18n.js from /libs/clientlibs/granite/utils/source/I18n.js
2. Include the granite.utils as a dependency

1. Manually Invoking the i18n.js from /libs/clientlibs/granite/utils/source/I18n.js

From the page template that your micro-frontend is embedded, you can just call the Adobe core Granite utils > i18n.js before your custom code, like the code provided below. Viewing the source code of your HTML page should look something like this; where the i18n.js is loaded first, and then your application is loaded secondly. Using the proxy method for accessing client libraries, you can serve /libs/clientlibs/granite/utils/source/I18n.js with /etc.clientlibs/clientlibs/granite/utils.js.

2. Include the granite.utils as a dependency

.

Simply ensure that your client library has a dependency for the granite.utils.

In line:6, notice how the a dependency have been added.

While in this article, we have mentioned that we are using the aem-clientlib-generator for our micro-frontend, so to install it, it would be as simple as adding a new property in the clientlib.config.js, and would be something that looks like this: line:33

The post Race Conditions with window.Granite?.I18n 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.

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.

The tool is very bareboned. When you are on the tool page, you’ll find a Categories input field. Simply insert your to-be-tested clientlib category value here and press “submit”. Your results will show up at the bottom panel. This tool only allows you to test one clientlib category at once.

This tool is great because it will display the <link> and <script> blocks that will be injected into your AEM pages when the client library is being called.

Try it yourself! http://localhost:4502/libs/granite/ui/content/dumplibs.test.html.

The post AEM Client Library Debugger & Client Library Test Tool appeared first on Sourced Code.

The Revealing Module Pattern in JavaScript is a design pattern that helps us organize our JavaScript in modules. This pattern makes it possible for us not to pollute the global scope, and it also ensures that the JavaScript module is running its own code as it should.

In this example, I have incorporated the best practices, and used special naming conventions, so that the code is organized, and set for scalability.

Skip to the code Example: Revealing Module Pattern in JavaScript, Jquery

Explanation of what each line does

1. line:1 = this is a self invoking function, while passing a parameter of the window.jQuery object; all functions and variables here will be closed off from the outer scope.
2. line:82 = on window ready, the MyComponent.init(); public method of the MyComponent will be called.
3. “use strict” on line:3 = ‘use strict’; states that the JavaScript code should be executed in ‘strict mode’. This makes it easier to write good and secure JavaScript code.
4. line:11 = this will be the declaration of the Module.
5. line:13 = this is where the Constants will be used throughout the Module; here you can include the data-arribute names, HTML element classNames, modifier classnames, etc…
6. line:20 = this is where the Module level variables will be saved;
   • variables like $myComponent, with $ as prefix, means that these variables are holding Jquery objects.
   • variables like pingUrl, with no $, means that these variables are holding standard data.
7. line:30 = notice the init() function has no under_scores like the other function. No under_score in the function name means that this is a public function.
8. line:31 = DO NOTHING, do not run any code when the HTML element is NOT on the page.
9. line:32-34 = set Jquery objects and other types of data to the variables, declaration on line 20.
10. line:36 && line:37 = here we register the open and close button.
    • functions with the under_scores, means that this is a private function.
    • functions with the without under_scores, means that this is a public function, and public functions should be exposed in line:76, from the return statement.
11. line:45 = _registerOpenButton(), private function; this cannot be called outside of the Module.
12. line:57 = _registerCloseButton(), private function; this cannot be called outside of the Module.
13. line:69 = _makePingCall(), private function; this cannot be called outside of the Module.
14. line:76 = this return declaration is used to reveal public methods that can be called by the self invoking function. In this case, only the init() function is public.

Code Example: Revealing Module Pattern in JavaScript, Jquery

The post Revealing Module Pattern in JavaScript, Jquery, for AEM Client Libraries appeared first on Sourced Code.

HTML data attributes were designed apart of HTML5 where these attributes allow developers to store data, as a string, on HTML elements. With HTL, we can set a value within data attribute’s value, returned from the AEM backend via Sling Model or HTL Java Use-API or HTL JavaScript Use-API.

The data attribute’s value set will be data from the AEM backend using the HTL scripting engine and will be apart of the HTML server-side render output. Next, JavaScript will be used to access these values.

1. HTML Data Attribute Syntax

The data attribute is made up of two parts:

1. The attribute name should not contain any uppercase letters, and must be at least one character long after the prefix “data-“, example: data-year, data-tax-code, data-calendar-point.
2. The attribute value can be any string.

An example of an plain <section> HTML element storing multiple data attributes of values, for the use of your JavaScript logic:

A HTL implementation:

Sling Model implementation:

2. Accessing the Data Attributes with JavaScript

Retrieving the value(s) of the HTML data attribute(s) in JavaScript is straight forward. You could use getAttribute() with their full HTML name to read these values, but the standard defines a better: a DOMStringMap you can read out via a dataset property.

To retrieve the data attribute(s) through the dataset object, retrieve the property by the part of the attribute name after data- (note that dashes are converted to camelCase).

Example:

The post With HTL, Pass Data from AEM Backend to Javascript appeared first on Sourced Code.

1. Embed Custom Font using Google Fonts, CDN
2. Embed Custom Font using Adobe Fonts, CDN
3. Embed Font via AEM Client Library Static Asset

1. Embed Custom Font using Google Fonts, CDN

Embed a custom font is by using Google Fonts. Google Fonts can be quickly installed into your project by using the @import CSS rule. Utilizing the out-of-the-box setup, you are prescribed to Google Font’s CDN. The lifecycle management of the fonts embedded onto your AEM site will be dependent on Google Font’s CDN servers.

There are hundreds of free font’s offered by Google. Simply visit the Google Font’s website to request for which fonts you wish to use on your website. Next obtain the @import CSS configuration that is offered by the webpage.

Embedding font via @import URL:

2. Embed Custom Font using Adobe Fonts, CDN

Embed a custom font is by using the Adobe Fonts, where fonts can be quickly installed into your project by using the @import CSS rule. After logging into Adobe Font’s, you can create a new project where you can select different fonts from Adobe Font’s collection to be used in your website. Retrieve the “embed code” CDN path from your Adobe Font’s project, and you are well on your way.

Next obtain the @import CSS configuration that is offered by the webpage.

Embedding font via @import URL:

3. Embed Font via AEM Client Library Static Asset

The most common way to embed a custom font for an AEM project is to store web-safe font files directly into a client library. The fonts are then referenced by the CSS stylesheet, where the font file paths are the proxied client libraries URI. Using the CSS rule, @font-face, we are able to configure custom fonts for an AEM project.

Embedding font via @font-face URL:

The post 3 Different Ways to Embed Custom Fonts in AEM Sites appeared first on Sourced Code.

AEM website can include & run front-end JavaScript logic like all other websites. Note, There’s nothing special about an AEM web page, as an AEM page rendered output is nothing but a standard HTML document; there’s no magic or surprises.

In this article, we will explore the 4 techniques of how we can include JavaScript within a webpage.

1. HTML Event Attributes

HTML possesses the capability to let events trigger actions in a browser, for example, executing JavaScript logic when a user clicks, hovers, drags, or keypress an element on a page. These events include onclick, onmouseout, ondrag, oncopy, etc…

Use Case:
Quickly way to add interactions to a unique HTML element on the page, as a proof of concept. Then later implement the same functionality with a front-end JavaScript application with tests.

Examples:

2.Inline JavaScript

Inline JavaScript can be executed by using <script> tag inside the <head> or <body> of the HTML document object model (DOM). Instead of specifying the source(src=”…”) of the JavaScript file in the <script> tag, JavaScript code can be written within the Script tag.

Use Case:
Supporting Adobe Analytics’s Data Layer JSON schema configuration values, based on the context of the page.

Examples:

3. Internal Client Libraries JavaScript

This is the HTML document that references the internal JavaScript file (compiled from client libraries).

The most common way to declare CSS styles and JavaScript behaviour to an AEM website is the use of AEM client libraries. A Client library is very specific to AEM where it is simply configuration declaring which CSS, JS, Resource files to be bundled; a client library can also bundle other client library configurations, and it has the capability to minify and debug. It is by choice and the preferred way that all AEM sites utilise client libraries to define a website.

Use Case:

• Serving JS and CSS from source files in AEM.
• Serving organised JS and CSS from different client libraries in AEM.
• Stitching multiple client libraries to be served in a single CSS or JS file.

Example – HTL loading CSS & JS using a Helper Template:

Example – Result of Rendered Page:

Example – Including Client Library from Editable Template Page Policies:

Example – Result of Rendered Page from Editable Template Page Policies:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<!DOCTYPE html>   <html>       <head>           <title>Client Librbary JavaScript file</title>           <script src="/etc.clientlibs/my-site/clientlibs/clientlibs-site.css"></script>         <script src="/etc.clientlibs/my-site/clientlibs/clientlibs-utils.css"></script>     </head>       <body>           ...         ...         <script src="/etc.clientlibs/my-site/clientlibs/clientlibs-site.js"></script>         <script src="/etc.clientlibs/my-site/clientlibs/clientlibs-utils.js"></script>     </body>   </html>

4. External JavaScript

This is the HTML document that references the external JavaScript file.
Use Case:

• Referencing the Adobe Dynamic Tag Manager (DTM) library to support Adobe DTM features.
• Referencing to the Adobe Analytics library, to support Adobe Analytics features.
• Referencing third party libraries, to support libraries features.

Example:

The post How to include JavaScript for an AEM Website appeared first on Sourced Code.

Instructions

1. Create a cq:ClientLibraryFolder node

JCR Path: /apps/sourcedcode/clientlibs/cllienlib-site
Separate code from content and configuration to maximize project file oranization and separation of concerns, Adobe recommends to place client libraries under /apps and expose these client libraries via the path, /etc.clientlibs, by leveraging the allowProxy property.

When allowedProxy is enabled, we instead of accessing the client library from /apps/sourcedcode/clientlibs/cllienlib-site, we can access the cliebt library from the proxy servlet via /etc.clientlibs/sourcedcode/clientlibs/cllienlib-site.

2. Create a nt:folder node named “resources”

JCR Path: /apps/sourcedcode/clientlibs/cllienlib-site/resources
By convention, the client library “resource” folder is named as “resources”; which the naming is very important if structural static assets are planned be served from a client library. This setup allowes structural static assets to be accessed via the proxy.
Example: /etc.clientlibs/sourcedcode/clientlibs/cllienlib-site/resources/tick.svg

3. Place the assets under the “resources” folder

In this example, we will only insert one asset image, tick.svg.
JCR Path: /apps/sourcedcode/clientlibs/cllienlib-site/resources/tick.svg

4. Build and Upload into AEM

This default maven profile should be a part of the maven AEM Project Archetype.

Results: Review the JCR

A successful project build and deploy should make JCR node resources available in the AEM environment.

Results: Access the Asset(s)

The images can be resolvable via the proxy servlet, replacing /apps with /etc.clientlibs.
Visit: http://localhost:4502/etc.clientlibs/sourcedcode/clientlibs/cllienlib-site/resources/tick.svg

The post How to Serve Static Assets in AEM as Client Library Resources appeared first on Sourced Code.

Structural assets should be stored and managed within the client library’s resources folder by the code package, and not in AEM Digital Assets Manager (DAM) “as content”. The AEM DAM is a very flexible AEM product where it allows users & groups to freely manage (based on ACL permissions) assets to make available for the public. Sometimes developers may find the ease of storing structural assets in the DAM (with the help of content authors), so they can quickly make the structural asset publically available for consumption. But, in fact, this is the wrong pattern to follow.

The reason why structural assets should not be stored “as content” and managed as DAM assets because:

• It would be surfaced to AEM content authors (the customers) during image selection when they are editing an AEM page that requires an AEM DAM asset; they can be confused, and they can potentially select on the structural asset (because it’s available for selection).
• It opens opportunities for interruption of our CSS styles or JavaScript view logic; where authors can actually delete/update a structural asset, and the website may look like its broken.
• It would kickstart workflows; creating thumbnails, preview renditions, meta-data extractions, and other workflow processes… These are unnecessary asset processing… we do not want any thumbnails or renditions for the structural asset.
• Code like CSS styles or JavaScript logic referenced assets “as content” is not ideal, as DAM assets are maintained by authors, and can be unpredictability changed at any time.

The post Structural Static Assets in AEM as Client Library Resources appeared first on Sourced Code.