Approaches to customize AEM

[Tethich]

I would like to raise a topic for which not even to this day I don’t have a clear straight forward concrete answer to give to someone that encounters the type of situations explained below.

The challenge is when one needs to customize something OOTB from AEM. Number of situations are enormous. Imagine just few that one may face:
- To customize how Content Fragment behaves in terms of auto-saving
- Customize renditions display or availability to download in left panel of an assets
- Tap in into the steps of copy-paste of a piece of content
- Alter functionality of a specific AEM page, like /security/permissions.html, or /projects.html, /assets.html
- Add a new custom column in the /sites.html/content
- Find an AEM endpoint implementation, conclude if it can be modified, change then its behaviour and control the response
- Enhance an RTE or a dialog

And the list can go on and on forever.

I am not interested in how to tackle exactly each of these few examples from above. I am interested in the general reasoning and approach in debunking a similar situation. So that when I do my research, me, as a developer, I will be sure I am on the right path to find the stuff inside AEM, understand and be confident that I landed in the right files, know how the entire internal execution flow works, what pages/endpoints/servlets are involved, what clientlibs and categories are used and so on.

I want to see different flavours of how each is used to approach such scenarios. I would like to find out if there is a common way/steps to dig into AEM. What are the basic rules that AEM is based on so that it can help anyone without indepth knowledge navigate through the solution and discover the unspoken or undocumented internal gears of AEM.

I believe few questions that usually I end up asking myself when needing to customize something in AEM, would be:

•  Is there a documentation on all the OOTB clientlibs, what they do, where are they used etc ? I know we have this /libs/granite/ui/content/dumplibs.html or this /libs/granite/ui/content/dumplibs.rebuild.html or this /libs/granite/ui/content/dumplibs.test.html. But I am looking for something more explanatory.
• Is there a documentation on all event listeners ? Like the cq-* ones (cq-close-toolbar), or dialog-* ones (dialog-beforeclose), or foundation-* one (foundation-contentloaded). We can’t just do guessings based on its name.
• Is there a documentation on all available tools, including those not visible or easy accessible via Touch UI ? Like /libs/cq/i18n/translator.html, or those regarding clientlibs mentioned above.

I know at some point few of these clientlibs, or event listeners, or internal tools, are mentioned, directly or tangential, in some Adobe documentation. But would be nice to have also a documentation centered around them (extracted maybe from existing Adobe documentations and centralized in one place, maybe using AI ... hmmmm ... maybe this can be submitted as an idea proposal ?)

So in conclusion, I am interested in an unified-generic-like way to handle such situations.

Teach me how to fish, don’t give me the fish !

[konstantyn_diachenko · Accepted solution]

Hi @Tethich ,

Actually, it's a very good question. I had to implement a lot of different customization of AEM UI for my clients. Sometimes it was easy to find entry-point, sometimes - not.

I noticed that not all UI consoles are easily extendible and require rude hacks like mutation observers. However, almost all UI elements are built on a Granite UI (Coral 3). You can find a documentation here: https://developer.adobe.com/experience-manager/reference-materials/6-5/granite-ui/api/jcr_root/libs/... .

The part that are you interested in is: Granite UI Foundation Client-side. It allows to extend functionality. Unfortunately there is a lack of examples there. In this case, I usually discover existing clientlibraries for real-world example. It helps to come up with solution with using Granite JS UI.

To sum up, I would say that I don't know any other official documentation for AEM UI customizations. Finding of AEM customization solution usually consists of:

• AEM client library discovery for existing examples or looking for an entry point to extend
• Searching for existing articles in web
• Implementing

Therefore, it would be nice to have such articles created by community or by Adobe. There is a room for any AEM influencers to create set of articles.

Best regards,

Kostiantyn Diachenko.

[arunpatidar]

I'd like to share my thoughts.

The approach varies depending on the specific use case.

• Some methods are officially recommended, such as overlaying or overriding components/resources.
• Others involve integrating solutions through clientlibs or filters to achieve the desired functionality.
• In certain cases, customization extends to the backend, requiring a tailored implementation for specific interfaces.
• etc

Each approach has its own advantages and considerations, so it's essential to choose the one that best fits the requirements while maintaining AEM best practices.

[daniel-strmecki]

My 3 cents on this topic: avoid heavy customizations whenever possible, as it usually bites you in the ass on the long run. For example, when Adobe does upgrades to AEM (hint: removed support for a specific interface), or decides to completely change the UI library (hint: Touch UI migration) or even the editor (hint: Universal Editor migration).

Discuss every customization requirement with the client first, and check if you can somehow solve it using OOTB functionality or with minimal customization. Our job as AEM consultants it not only do develop whatever the client wants, but warn them about potential future challenges and maintainability issues. Do heavy customization only if you really, really need it for the features that bring significant business value.

Hope this helps,

Daniel