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

Question

Options

• AExtend the COTB Text component and enable the sourceedit Rkh-Text Editor (RTE) plugm.
• BCreate a new clientlib to programmatically handle HTML source >n authoring.
• CCreate a standalone custom Text component and handle HTML source in Sightly.
• DEdit the OOTB Text component directly to enable sourceedit Rich-Text Editor (RTE) plugin.

• A
  11% (6)
• B
  2% (1)
• C
  5% (3)
• D
  82% (45)

Explanation

Note: There appears to be an error in the marked answer - based on AEM (Adobe Experience Manager) best practices, A is the correct answer, not D.

Extending the OOTB Text component via an overlay (creating a copy under /apps that mirrors the /libs structure) and enabling the sourceedit RTE plugin is the correct AEM approach, because it preserves the original component and survives upgrades. D is actually the wrong choice - directly editing OOTB components in /libs is an anti-pattern: those changes are overwritten whenever AEM is upgraded, making the customization fragile and unsupportable.

Why the distractors are wrong:

• B is wrong - a clientlib handles front-end assets (JS/CSS), not authoring dialog behavior or RTE configuration.
• C is wrong - building a standalone custom Text component from scratch is unnecessary duplication when the OOTB component already provides the RTE infrastructure; Sightly/HTL is a templating language, not a mechanism for configuring authoring tools.
• D is wrong - modifying /libs directly violates AEM's fundamental separation between Adobe-owned code (/libs) and project code (/apps).

Memory tip: In AEM, think "Never touch /libs, always overlay to /apps." Any customization of OOTB components goes through the overlay/extension pattern - find the component in /libs, mirror it in /apps, and modify only what you need.

No community discussion yet for this question.