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.

However, the POST HTTP method does not work. You are likely to see a 403 Forbidden error; unable to send data to local AEM (proxy server). A simple solution to fix this is to add append another configuration property to your dev server key named setup(). This will take the original POST URL and redirect with the same URL, making it a GET request; it’s a bit hacky, but it works well.

This article should answer your questions for:

• Webpack Dev Server, unable to make a POST to the proxied server?
• Webpack Dev Server, proxy configurations does not allow me to POST?
• Webpack Dev Server, I am getting a 403 Forbidden error whenever I try to make a POST via proxy configurations?
• Webpack Dev Server, Why can’t I make a POST request to my proxy backend server?
• Webpack Dev Server, Why can’t I send data to to my proxied server?
• Webpack Dev Server, 301 forbidden POST request, not able to send data to my server?
• How do I get Webpack Dev Server to accept POST requests

The post Webpack Dev Server ^3.9.0 unable to POST (send data to server) 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.

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.

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 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.

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.