AEM: Are you Coding when you should be Configuring?

There are plenty of wrong ways to code for AEM (or any platform for that matter) but for the most part, the issue is tweaking tools and knowing where to put your code. “This system” likes it to be done in “this way”. With Adobe Experience Manager occasionally you will need to write some custom Java code. A given in any AEM implementation is that there will be some specific requirement that can’t be accomplished through the normal out of the box components, and you will need to create something completely new from scratch; just plan for it. Or, certainly there are going to be times where the business goal requires heavy coding — for example, we spent a month upgrading a client’s Classic UI component dialogs to 6.4’s Touch UI dialogs, which involved changing to Granite UI dialogs away from custom ExtJS code. But every developer should always practice proper coding standards. Those exist regardless of the system you are working with.

Or maybe said a more relevant way, “don’t reinvent the really complex tool that already exists inside AEM”. Once I worked with a developer who wanted to create his own system for tagging pages of content. I pointed out that it might be easier, and less time consuming, to just use AEM’s built-in Tag Manager system. After more discussion than I would have thought necessary, it was agreed that we would use the native AEM Tag Manager. Don’t overdevelop your solution.

“But I don’t like the tool AEM comes with.” That’s actually a valid concern. There may be some truly awful tools that you have to work with (ie: AEM’s vanity URL support). But is it worth building a completely new thing that no one other than you can support as new versions of AEM come out? And do you really think that you are going to build something better? Using the built-in tool is almost always better than just rewriting it.

If I was going to try and be catchy, I might try to give you the “top 5 things that your implementation partner should know how to configure in AEM”, but that wouldn’t be accurate (though if I were these would be at the top of my list: /etc/map rules, dispatcher configs, replication, workflows, and general systems maintenance tasks). No two AEM projects are done the same way. Instead, I would say that your AEM implementation partner, or your own internal team, should know about, and know how to make, all the necessary configurations. They should know how to configure the tools of AEM to accomplish your business requirements.

We do. We’re Hoodoo.