AD0-E121 practice question 10 of 10

A developer plans to use the Text component on its pages. However the out-of-the-box (OOTB) Tex! component does not allow authors to edit HTML source on the component. How should the developer support HTML source editing?

Full set: 50 questions
Answer options
A: Extend the COTB Text component and enable the sourceedit Rkh-Text Editor (RTE) plugm. Correct answer
B: Create a new clientlib to programmatically handle HTML source >n authoring.
C: Create a standalone custom Text component and handle HTML source in Sightly.
D: Edit the OOTB Text component directly to enable sourceedit Rich-Text Editor (RTE) plugin.
Correct Answer:
A. Extend the COTB Text component and enable the sourceedit Rkh-Text Editor (RTE) plugm.
Explanation

The correct and best-practice approach in AEM is to extend the out-of-the-box (OOTB) component rather than modifying it directly. By creating a proxy or copying the component to the project-specific path (/apps), developers can safely customize it. The functionality for HTML source editing is a built-in feature of the Rich-Text Editor (RTE), which is controlled by plugins. The developer must enable the sourceedit plugin within the RTE configuration nodes (rtePlugins) for the extended component's dialog. This method preserves the original OOTB component, ensuring that customizations are not lost during AEM upgrades.

Why Incorrect

B. Create a new clientlib to programmatically handle HTML source in authoring. This is incorrect because the functionality already exists within the RTE framework; it only needs to be enabled via JCR node configuration, not by writing custom JavaScript.
C. Create a standalone custom Text component and handle HTML source in Sightly. This is incorrect because Sightly (HTL) is a server-side templating language for rendering content, not for providing authoring user interfaces like a source editor.
D. Edit the OOTB Text component directly to enable sourceedit Rich-Text Editor (RTE) plugin. This is a critical violation of AEM best practices. Modifying anything under the /libs directory is unsafe, as changes will be overwritten by future AEM service packs or upgrades. ---

References

1. Adobe Experience Manager as a Cloud Service Documentation, AEM Components - The Basics: This document outlines the principle of overlays and extensions. It explicitly warns against direct modification of OOTB components: "Do not make changes in the /libs path. Any changes you do make may be lost, because this path is liable to changes whenever you... apply a hotfix... or upgrade your instance." This directly refutes option D and supports the "extend" part of option A.

Source: Adobe Experience Manager Documentation, "AEM Components - The Basics", Section: "Overlays".

2. Adobe Experience Manager as a Cloud Service Documentation, Configure the Rich Text Editor: This guide details the process of enabling RTE features through plugin configuration. It shows how to add features like sourceedit to the features property of a plugin's configuration node (e.g., under cq:dialog/.../rtePlugins/misctools). This supports the technical implementation described in option A.

Source: Adobe Experience Manager Documentation, "Configure the Rich Text Editor", Section: "Activate RTE Functionality by Configuring Plugins".

3. Adobe Experience Manager as a Cloud Service Documentation, Core Components and the Proxy Component Pattern: This document describes the modern best practice for customizing components, which involves creating a project-specific proxy component that inherits from the OOTB version. This is the recommended way to "extend" a component, aligning perfectly with the methodology in option A.

Source: Adobe Experience Manager Documentation, "Developing Core Components", Section: "Proxy Component Pattern".

Scroll to Top