There are some tasks that are somewhere between the frontend and the backend. AEM 6.3 can help streamline these tasks.
Imagine the scene: you’re looking at an AEM design page in which all site configurations are defined. In this page, there are around 2,000 lines of code. The lines include data validation, data formatting, layouts and templating, as well as component configuration. You see configuration switches, coming from page properties and components, client library definitions, and the declaration of allowed components and their children as well as the default configuration for those components. Each of these lines is dedicated to accomplishing a very different goal, and they all exist in just one file.
A key question arises: who is responsible for this design page?
A frontend developer might assume that this code is more the responsibility of a backend developer. But what happens when the back-end developer believes the same thing? “This isn’t my responsibility - this is for the frontend folks to look after. It’s on them.”
Apart from the maintenance issues (and the "who’s accountable for what" dilemma), the overuse of component configuration can generate higher costs for businesses. This is because not only will they require the complexities to be documented, but the business’ authors also need to be trained, and documentation needs to be created, all of which will increase total spend.
Introducing: the middle-ender
What this hypothetical (yet common) scenario shows us is that, increasingly, we need developers to meet in the middle. Developers need to see themselves not just as frontender or a backender - but also as part of a new category of developer: the middle-ender. Indeed, at the Netcentric summit in Seville in 2016, Gabriel Waltz from Adobe suggested that there needs to be a more dynamic and fluid relationship between frontend and Java developers. Fortunately, the Adobe Experience Manager (from version 6.2 and onwards), provides developers with several tools to better organize the complexities within the code, (and to collaborate) and feel accountable for what lies between the backend and the frontend.
These features are enabling the rise of the middle-ender, so let’s take a look at them:
Available from version 6.2, Content Policies are an example of these tools. Content Policies are reusable design configurations that can be defined for both templates and components. To leverage content policies, developers must recreate a similar content structure than the one provided by Adobe in its we.retail recommendation.