If you’ve been in the developer community for a while, you probably know it all too well. The religiosity with which adepts of the different platforms advocate their beliefs. I too, am a little bit guilty of this. I’ve been involved with the Day CQ / Adobe AEM developer community since 2001. So you can kind of guess which gospels are on my desk.

This is how the debate would typically go:

Pro Java Guru: “Why not apply best practice solution patterns from experienced Java Gurus? Isn’t it how we’ve developed Java applications since forever, with plenty of library support and copy & paste of codes? And how many applications in production are running on Spring, for example?”

Pro AEM Native: “Well, sure, but on the other hand, since AEM already contains quite a lot of OpenSource (Sling, Felix, OSGI, …) and the two Adobe masterminds David Nüscheler and Roy Fielding are well connected in the OpenSource Community, shouldn’t we be consistent? Meaning that, if a helpful framework will come up, the Adobe team will integrate it on the long term? Thus we should assume that all useful, facilitating OpenSource tools are already inside AEM, right?”

Or take the prejudices that return over and over again. You’ve probably seen them as well.

Prejudice 1: securing requests.

The Java Guru: "But I can secure certain requests more easily using a Framework such as Spring!"

The AEM Native would reply: “If you use a huge Framework like Spring inside AEM, you should rethink your approach. In Sling, everything is about “content” - hence the content itself needs to be secured. Let’s assume, you want to protect a request to a specific function in /content/myfunctionality/securecontent. Then just put a rep:policy node to that path and apply the groups you want to allow access instead of trying to protect the Controller. It is much easier to implement proper components for post, get, delete and align them in the content. As a subsequent task you protect the nodes accordingly. When the request now reaches the content, in case this piece of content has an Access Control (AC) applied; the repository itself is handling the Authorization and will not even forward to the Controller.

Secondly, you should not use servlets handling requests executed by your browser; as such servlets cannot be easily protected by Sling. You’ll find this AC Handling within AEM quite handy when it comes to a bigger integration within an environment where you need to integrate authentication via SAML.”

Prejudice 2: MVC.

The Java Guru: "Model-View-Controller MVC is not possible with AEM!"

The AEM Native would reply: But if you have a look at the AEM Architecture, MVC is already in place!

• Model: The content is the Model
• View: Sightly/JSPs provides the rendering of the View.
• Controller: Sling provides the controller these are the SlingModels
• Hence when you are working with all the available functionality, you already build your AEM
• Components using the MVC pattern.
• Apropos: Using SlingModels, there are a lot of handy Annotations in place (see https://sling.apache.org/documentation/bundles/models.html#annotation-reference)

Furthermore, if SlingModels are used to create the Controllers, each of them is adaptable either from a Resource, Request or both via the popular adapter principle.

And then, the AEM Native brings in a final valid argument.

“If you bring in another framework which touches security or resource handling and manipulate the request flow in AEM before the usual Sling Request Resolution mechanism, it will cost a lot of effort to do so. Secondly, as soon as a new release of AEM will be available, the whole stack that has been implemented has to be retested and aligned to the new version. Why not just rely on AEM to find the proper implementation of a useful OpenSource extension in the standard product?”

Thus before getting a headache in implementing huge frameworks in AEM, I’d say we should just let David and Roy do the work.