AEM 6.5+ modernized Components
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:
Read the rest of this entry »BC$ = Behavior, Content, Money
The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:
1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.
2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.
3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.