Behavior, Content, Money – 3 Things you should never give away for free!!!

BCmoney MobileTV

AEM 6.5+ modernized Components

Posted by bcmoney on May 12, 2022 in Uncategorized with No Comments


No Gravatar

When I first started to work with AEM back in the AEM 6.1 days, I have to admit I was a little disillusioned with the few paltry OOTB components that came with very basic ExtJS-based “Foundation Components” that worked primarily in “ClassicUI”. AEM 6.2 was the first version that started really pushing a transition to the new “TouchUI”, even though it was already there in beta since CQ 5.6 and considered mature by Adobe (though not well-documented until much later leading to some hesitation in adoption) since AEM 6.1. As a result, we ended up with quite a mess in our codebase which we are constantly struggling and toiling to cleanup as best we can, but we’ve ended up in the following situation where way too many frameworks were mixed and matched based on different Devs/teams that worked on specific features (i.e. the high Technical Debt output situation with all the hallmarks of a “Feature factory”):

It was AEM 6.2 and beyond where TouchUI became the preferred Authoring experience and companies scrambled to build their Components to work well within both ClassicUI and (more importantly) TouchUI. Then, since AEM 6.3+ the platform introduced the concept of “CoreComponents”, which are basically a collection of open source general-purpose, highly authorable, reusable and extensible AEM Components available OOTB that will replace the legacy “Foundation Components” implemented using ExtJS which are now being phased out.

Having been elbow-deep in trying to migrate as many parts of our legacy AEM 6.1 codebase as possible to the latest and greatest AEM 6.5 platform capabilities, I’ve had plenty of “in the trenches” experiences trying to get things modernized. Recently, I was tasked with writing some backend and (optionally) frontend code to show how I would build a “fully modernized” AEM custom Component, the tempting if not perplexing “green field” conundrum for developers:

An example modernized component that can lookup Users from a specific 3rd party API could look something like the following hierarchy:

  • Jackson databind POJOs (JSON/XML-to-Object mapping)
  • UserLookupService (interface)
  • UserLookupServiceImpl (with OSGi R7 Declarative Service annotations)
  • UserLookupServlet (WebService that implements via @Reference)
  • UserLookupModel – Sling Model (backend Component, rather than WCMUsePojo that implements via @OSGiService)
  • User Lookup custom component (in “<APP_NAME>/src/main/content/jcr_content/apps/<APP_NAME>/custom/user-lookup” path)
  • user-lookup.html (HTL/Sightly component structure)
  • /js/user-lookup.js (client-side code could be vanilla JavaScript, framework-specific JS, SPA/PWA, Typescript and/or ES X syntax)
  • /css/user-lookup.less (styling could be LESS, SASS or vanilla CSS 3+)

Aside from creating these backend elements:

  • OSGI Service that can be used in multiple contexts
  • Servlet to proxy API calls through

It is also useful to experiment with:

  • Stick to plain HTML/JS/CSS rather than library or framework usage
  • BEM notation for all CSS
  • StyleSystem examples
  • Ability to set a “Background color” via Authoring Dialog
  • Ability to set a “Background image” via Authoring Dialog
  • Creating an AJAX-based testing utility (in Author/preview mode only) where you can call your backend API passing through any values typed into a form

Lastly, it would also be useful to be able to set the parameters passed into the external API via:

  • AJAX field
  • URL params
  • TouchUI Dialog settings

Preparing something similar would be a great activity for any developer to learn the ins & outs of AEM first-hand, particularly if you wanted to become a “full-stack” AEM Developer.

Here’s a preview of what I put together for this challenge:

You can see a potential code example below (ask for permission to see, as its access is private):

Integrating these into Editable Templates, the code becomes significantly cleaner than most teams ended up with using prior approaches, particular on older versions that date back to AEM 6.1 and earlier.