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.
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.
A user with the Template Administrator role (or a developer) could define a client library category that they would like to load for the template, as well as any page based on it. Therefore, the user can define a policy in the page design, give it a name, a title, and a description, and then set one client library or an array of them, and they will be loaded accordingly. Defining a policy for container components, such as the paragraph system is mandatory, because that’s the only way to tell the parsys what components are allowed within it.
One important point to keep in mind is that Content Policies are only available for projects authoring on TouchUI, which means that they're not available on ClassicUI.
An important feature of Content Policies, is that they can be shared across templates, so the user/developer doesn’t have to define them every time. They can define them once, and then reference them; they can be selected from the UI in a drop-down menu.
Another key benefit of Content Policies is that they can be referenced from across locations, making it easier to replicate pre-written instructions. That way, if a content author or developer wants all the definitions in a Content Policy to be replicated in a different template or component.
If, for example, a template author had a global policy in their global folder, they could go to the content page to find it. There, instead of defining all configuration aspects of the policy again, they could just map it to a pre-existing policy resource type for reutilization.
With Style System, developers and template administrators (or any author with the right privileges) can define custom classes in the style tab of a component settings page. As an example, we could customize a component style configuration by defining two specific styles, “style large” and “style red”, corresponding to a ‘teststyle__base--large’ and ‘teststyle__base--red’ class respectively. When adding the component to the parsys, the author would then see a brush icon in the editing tools menu. The above defined classes would then be available to use. It’s important to notice that the classes can be defined to be used individually or as multiple choice, allowing for a richer and more complex styling combination and output. Default classes can also be defined.
The selected classes are then added by the system to the cq_html_decorator tag, cascading down to the component.
Here are some ideas on how to include additional styles on demand:
Core versioned components were originally released in v1 for AEM 6.2, but are compatible from v2.0.6 for AEM 6.3 and above. These components provide increased flexibility since developers and architects had to wait until a new version of the Adobe Experience Manager CMS was released to get new components or component features. With Core Components, updates are available as a standalone package, to be independently installed. This essentially provides system designers with more power and flexibility to decide which version they want to use.
Some important aspects when deciding to give Core Components a try, is they
The end goal here is to increase fluidity between the roles and remits of back-enders and frontenders, particularly given that, in the complexity of the modern technological climate, so many tasks now seem to fall somewhere in the middle. The robust structures of AEM 6.3 and all its new configuration systems and versioned granular control for components, make these ‘in-between’ processes significantly more streamlined and intuitive. These features and structures help us progress towards confidently referring to ourselves as ‘middle-enders’, and dominating a broader region of the stack end.