AEM Component Interview Questions and Answers

1. What is an AEM component? Explain its purpose.

• Answer: An AEM component is a modular, reusable building block used to render specific content on an AEM page. It encapsulates logic, markup (HTML/HTL), and styling (CSS/JS) to display content like text, images, carousels, navigation menus, etc. Its purpose is to enable content authors to easily create and manage page content without needing technical knowledge, promoting consistency, reusability, and efficient content management.

2. Differentiate between a component and a template in AEM.

• Answer:

  • Component: Represents a specific type of content or functionality that can be placed within a page. It's focused on rendering a particular piece of information (e.g., a text component, an image component). Multiple instances of the same component can exist on a single page or across different pages.

  • Template: Defines the structure and layout of a page. It dictates which components can be added to specific areas of the page. A template acts as a blueprint for creating new pages, ensuring consistency in page structure across a website (e.g., a "Product Page" template, a "Blog Post" template).

3. Explain the different parts/files that make up an AEM component.

• Answer: An AEM component typically consists of the following key files/parts:

  • .content.xml: The component definition file. It contains metadata about the component, such as its title, description, component group, allowed parents, and initial properties.

  • _cq_editConfig.xml (Optional but common): Defines the component's editing behavior in the AEM authoring interface, including listeners for events (e.g., aftercopy, afterdelete, afteredit, afterinsert), drop targets, and inplace editing configurations.

  • dialog/ (or _cq_dialog/ for Touch UI): Contains the component's dialog definition. This is an XML file (or a folder structure for complex dialogs) that defines the fields authors use to configure the component's content and properties.

    • Touch UI Dialog: Typically found under _cq_dialog/.content.xml and uses Granite UI components.

    • Classic UI Dialog: Found under dialog/.content.xml and uses ExtJS widgets.

  • render script (e.g., .html, .jsp): This is the core logic that renders the component's content.

    • HTL (Sightly): The recommended templating language for AEM components (.html files). It's secure, performant, and easy to learn.

    • JSP: Older templating language (.jsp files), still found in legacy projects but generally not recommended for new development.

  • clientlibs (Optional but highly recommended): Client-side libraries containing CSS and JavaScript files specific to the component. These are typically organized in a folder structure like clientlibs/css and clientlibs/js, and registered in .content.xml with categories.

4. What is a dialog in AEM? Why is it important?

• Answer: A dialog in AEM is the user interface that content authors use to configure and edit the content and properties of a component. It's essentially a form with various fields (text fields, image uploads, dropdowns, rich text editors, etc.) that map to JCR properties of the component's node.

• Importance:

  • Authoring Experience: Provides an intuitive way for non-technical users to manage content.

  • Data Input: Collects the data that the component will display.

  • Content Separation: Separates content from presentation logic, allowing authors to focus on content while developers handle the rendering.

  • Validation: Can include validation rules to ensure data integrity.

5. Explain the difference between Classic UI and Touch UI dialogs.

• Answer:

  • Classic UI Dialogs:

    • Based on ExtJS framework.

    • Defined using dialog/.content.xml.

    • Have a distinct, older look and feel.

    • Accessed via the "pencil" icon in Classic UI.

  • Touch UI Dialogs:

    • Based on Granite UI framework (built on Coral UI3).

    • Defined using _cq_dialog/.content.xml.

    • Are responsive, modern, and provide a better user experience on various devices (desktop, tablet, mobile).

    • The standard authoring interface in modern AEM versions.

    • Accessed via the "wrench" icon or double-clicking the component in Touch UI.

6. What is HTL (Sightly)? What are its advantages over JSP?

• Answer: HTL (HTML Template Language), formerly known as Sightly, is the preferred templating language for AEM components. It's designed to be secure, efficient, and easy to develop.

• Advantages over JSP:

  • Security: By default, HTL automatically escapes all output to prevent cross-site scripting (XSS) vulnerabilities. This significantly reduces the risk of security flaws.

  • Simplicity and Readability: HTL focuses on HTML, making templates cleaner and easier to read and maintain for front-end developers.

  • Performance: HTL compiles into Java servlets, offering good performance.

  • Separation of Concerns: Encourages a clear separation between logic (Java/JavaScript Use-API) and markup (HTL), promoting better code organization.

  • No Scriptlets: Eliminates the use of scriptlets (<% %>) which often lead to unmaintainable code in JSPs.

  • Client-Side Includes: Supports client-side includes, which can improve initial page load times.

7. How do you pass data from a Java backend (or JavaScript Use-API) to an HTL component?

• Answer: You use the Use-API (Use-object) concept in HTL.

  • Java Use-API:

    1. Create a Java class (e.g., MyComponentUse.java) that extends WCMUsePojo or implements WCMUse.

    2. In this class, you can retrieve Sling models, inject OSGi services, access JCR properties, and perform business logic.

    3. In your HTL file, instantiate the Use-object using data-sly-use.variableName="com.example.MyComponentUse".

    4. Access methods or properties from your Use-object using @{variableName.methodName} or ${variableName.property}.

  • JavaScript Use-API (less common for new development, but still an option):

    1. Create a JavaScript file (e.g., logic.js) alongside your HTL file.

    2. Define functions and properties within this JS file.

    3. In your HTL file, use data-sly-use.variableName="logic.js" to load the JavaScript file.

    4. Access properties or call functions using @{variableName.property} or @{variableName.function()}.

8. What is a Sling Model? How is it related to AEM components?

• Answer: A Sling Model is an annotation-driven way to adapt Sling objects (like Resource, Request, Page, User) into POJOs (Plain Old Java Objects). It simplifies data retrieval and manipulation in AEM by automatically injecting properties from the JCR, OSGi services, and other Sling objects.

• Relationship to AEM Components:

  • Preferred Use-API: Sling Models are the recommended way to implement the backend logic (Use-API) for HTL components. Instead of WCMUsePojo, you can directly adapt a Resource or Request to your Sling Model.

  • Cleaner Code: They reduce boilerplate code compared to traditional WCMUsePojo implementations.

  • Testability: Sling Models are easier to unit test.

  • Dependency Injection: Support various injection strategies (e.g., @Inject, @ValueMapValue, @OSGiService, @Self).

  • Data Abstraction: Provide a clean abstraction layer for the component's data, separating the data retrieval logic from the presentation.

9. How do you make an AEM component editable in the authoring interface?

• Answer:

  1. Component Group: Define componentGroup property in the component's .content.xml (e.g., componentGroup="My Project - Content"). This makes it appear in the Components browser.

  2. Allowed Parents/Children: Ensure the component is allowed to be placed within the desired parent component or template using cq:allowedParents or cq:allowedChildren properties on the parent component or template.

  3. Design Dialog (for parsys restrictions): If you're using a parsys (paragraph system) component, you might need to configure its design_dialog to allow specific components.

  4. Edit Config: While not strictly required for basic editing, _cq_editConfig.xml is crucial for advanced editing features like drag-and-drop, inplace editing, and defining listeners.

  5. Dialog: A well-defined dialog (_cq_dialog/.content.xml) is essential for authors to configure the component's content.

10. Explain the purpose of _cq_editConfig.xml in a component.

• Answer: _cq_editConfig.xml (Edit Configuration) defines how a component behaves in the AEM authoring environment, specifically its interaction with the drag-and-drop mechanism, listeners, and inplace editing.

• Key functionalities:

  • cq:listeners: Defines JavaScript functions to be executed when specific events occur on the component (e.g., aftercopy, afterdelete, afteredit, afterinsert, aftermove). This is useful for refreshing the component, updating related data, or performing custom actions.

  • cq:dropTargets: Configures areas within the component where assets (images, videos) can be dropped directly from the Content Finder.

  • cq:inplaceEditing: Enables "inplace editing" for certain properties, allowing authors to directly edit content (like text) on the page without opening a dialog.

  • cq:actions: (Classic UI) Configures the actions that appear in the component's edit bar.

  • emptyText: Defines placeholder text when the component is empty.

11. How do you include CSS and JavaScript in an AEM component?

• Answer: You typically use Client Libraries (ClientLibs).

  1. Create a clientlibs folder (e.g., clientlibs) inside your component's structure.

  2. Inside clientlibs, create subfolders for css and js (e.g., clientlibs/css, clientlibs/js).

  3. Place your CSS files (e.g., style.css) and JavaScript files (e.g., script.js) in their respective folders.

  4. Create a .content.xml file within the clientlibs folder.

  5. In this clientlibs/.content.xml file, define properties:

     • jcr:primaryType="cq:ClientLibraryFolder"

     • categories="[myproject.components.mycomponent]" (Define a unique category for your component's clientlib).

     • css="[css/style.css]"

     • js="[js/script.js]"

  6. In your component's HTL file (or template), include the client library using the data-sly-use.clientlib and data-sly-call attributes:

     HTML

      <sly data-sly-use.clientlib="/libs/granite/sightly/templates/clientlib.html"/>
      <sly data-sly-call="${clientlib.css @ categories='myproject.components.mycomponent'}"/>
      <sly data-sly-call="${clientlib.js @ categories='myproject.components.mycomponent'}"/>
     

• Embedding ClientLibs: You can embed multiple client library categories within a parent client library using the embed property in its .content.xml to manage dependencies.

12. What is the role of sling:resourceType in a component?

• Answer: The sling:resourceType property is crucial for mapping a JCR node to the rendering script (component) that will process and display its content.

  • When AEM renders a page, it traverses the JCR content tree.

  • When it encounters a node with a sling:resourceType property, it looks for a component definition (a node with the same path as the sling:resourceType value, typically under /apps/) and executes its rendering script (HTL/JSP).

  • This property allows for dynamic rendering and enables the concept of resource type resolution in Sling.

13. Explain component inheritance and how it's achieved in AEM.

• Answer: Component inheritance allows you to reuse and extend existing components, promoting code reusability and reducing development effort.

• How it's achieved:

  • sling:resourceSuperType: This property in a component's .content.xml specifies the path to another component that it extends. The inheriting component can then override or add to the inherited properties, dialogs, and rendering scripts.

  • Overriding: When AEM processes a component with sling:resourceSuperType, it first looks for resources (dialogs, scripts, etc.) within the current component. If a resource is not found, it then looks in the sling:resourceSuperType component's path. This allows you to selectively override parts of the inherited component.

• Benefits: Reduces redundancy, simplifies maintenance, and ensures consistency across similar components.

14. What are component properties and how are they stored?

• Answer: Component properties are the data and configuration values associated with a specific instance of a component on a page. These properties are typically configured by authors through the component's dialog.

• Storage: Component properties are stored as JCR properties on the component's node within the JCR content repository.

  • For example, if you have a "Text" component, its text content would be stored as a text property on the /content/my-site/en/jcr:content/root/container/mytextcomponent node.

  • These properties are accessible within your HTL scripts or Sling Models to render the component's content.

15. How do you troubleshoot a component that is not rendering or behaving as expected?

• Answer: A systematic approach is key:

  1. Check error.log: This is your first stop. Look for exceptions, warnings, or error messages related to your component, Sling Models, or JCR access.

  2. Verify sling:resourceType: Ensure the sling:resourceType on the content node points to the correct component path under /apps (or /libs).

  3. Check Component Path: Confirm the component's physical path under /apps (e.g., /apps/myproject/components/content/mycomponent).

  4. Dialog Configuration: If the issue is with properties not saving or appearing, check the name attributes in your dialog fields – they must correspond to the JCR property names you expect.

  5. HTL/JSP Syntax: Look for syntax errors in your rendering script. Use a good IDE with HTL/Sightly support.

  6. Sling Model/Use-API Debugging:

     • Add log.debug() statements in your Java Use-API or Sling Model to trace execution and variable values.

     • Use AEM's CRXDE Lite to inspect the JCR node properties to see if the data is being saved correctly.

     • If using Sling Models, check the Sling Model Injector logs (org.apache.sling.models.impl.injectors in status.json).

  7. ClientLibs Issues: If styling or JavaScript isn't working, check:

     • Are the clientlib categories correctly defined in .content.xml?

     • Are the clientlibs included correctly in your page template or component?

     • Browser's Developer Tools (Console for JS errors, Network tab for CSS/JS loading, Elements tab for applied styles).

     • Clear browser cache.

  8. Permissions: Ensure the user account has necessary read permissions on the component path, content path, and any related assets.

  9. Cache Issues: Clear AEM dispatcher cache, browser cache, and AEM internal caches if necessary (e.g., via http://localhost:4502/system/console/configMgr for OSGi bundles).