< Return to Feed
Sean McKaharay - 02.28.2017

Lessons from the AEM School of Hard Knocks

Adobe Experience Manager

In the time since I built my first project in Adobe Experience Manager (AEM), I’ve learned that there are a lot of AEM configurators, but not many true AEM developers. In my experience, ask an AEM configurator what a thumbnail servlet is and how it works, odds are that they will probably not know what a servlet is or how it works. On the other hand, an AEM developer will know what a thumbnail servlet is and how it is used, and will likely know how to override its functionality. So if you are planning on building out a site in AEM, there are some lessons I’ve learned that you may want to take into consideration. 

Data Is Key

CMS means many different things to many different people. If you’re reading this article, it’s reasonable to assume you’re thinking about doing a build in AEM, so here’s your first takeaway: Data is key. Think about this: we often think of components as a piece of code that shows or does something. Take a moment to ask yourself: where is this data coming from? Many times, when you ask a developer for a component that will show an image with some text and link to an inner page, they’ll build exactly what you’re asking for. But let’s say you have an event for the 4th of July and you want to let visitors to your home page know about the event. You can use the component that was built for you, but what happens if you change the title of the event? Or what if the time of the event is changed? Now you have to slog through your entire site to ensure the title or date is updated anywhere an author has called out this July 4th event. Maybe you’ll find them all, but you’ll still have that nagging feeling that one instance may have been missed and probably has been. 

The bottom line: if the data itself had been considered initially, the developer could have been instructed to build a component that uses and displays data on the event page. That way, when the author changes the title of the event, all components that use that data will automatically update. 

AEM 6.0 is Sightly Better

There is a big difference between AEM 6.0+ and any versions that predate it. That difference is called Slightly. Before 2014, AEM required an understanding of jsps and some coding was required. Since AEM’s introduction of Sightly in AEM 6.0, the CSM’s new HTML templating engine became the dominate tool, making jsps almost a thing of the past. AEM’s goal with Sightly was to produce more readable, maintainable and secure code while distinctly separating the logic and markup. 

In addition to Sightly, AEM has introduced a new mobile-friendly Touch UI (5.6), also known as Graphite UI. This UI was meant to address the growing desire by authors to be able to create and edit content on their tablets and mobile devices on the go. Touch UI is thoughtfully designed with the author in mind, allowing easy updates using a touch device while still supporting navigation with a mouse for laptop and desktop users. Touch UI has its share of issues, but you can make do almost anything you want with a little Javascript and some CSS knowledge. 

There are many examples of components built in a “classic” way, but not as many in the Touch UI way. You can always build out components the old way, but there may be times when the user must go from the classic to Touch and Touch to classic.

Consistency Avoids Maintenance Nightmares

In the long run, AEM is a Java application and you build OSGI packages and Java classes. Like any software, there are many ways to accomplish the same end, and AEM is no different. So here’s a tip: be consistent in your build. In AEM and Sightly you can access data for your component either using the scripting language or you can build a class.  In my experience, neither way is wrong, but I’ve found its best to pick a single way to develop components and stick to it, because creating 10 different controls 10 different ways will be a maintenance nightmare. 

So What’s My Point?

AEM is never as easy as you might think, but it doesn’t have to be as hard as some developers make it. Save yourself some trouble and take the time to think through possible outcomes on the front side. For example, if I need a component that requires a title and a description, I might assume this is as easy as putting two fields on the page and a couple of properties in a dialog box…but what if we want to control the style? Or what if we want to control the size instead of the style? Or what happens if the client now wants to share content on all pages? These are good questions to ask yourself as a developer, and more importantly, to ask your client before building in AEM. 

I once worked for a manager who, when he asked why a project had gone upside down, took exception to my answer that there just wasn’t enough time to do the project right. “Why is there never enough time to do it right,” he asked, “but there always seems to be time to do it over?” I have never found a good answer to that question, but have found I won’t have to answer it if I think my project through. So instead of having things that are fast, cheap or good, take your time, think it through, and do it right the first time.