Abstract
In this blog series on Sling models I’ll cover some of the best practices and conveniences I’ve gathered and discovered over the years, for you to apply when developing AEM components.
I’ve had the luck of working on a variety of projects: projects that have been developed for numerous years, completely new projects, projects that were made by a single vendor, by different agencies, etc. These experiences have unveiled all kinds of approaches when it comes to developing Sling models. I will be sharing my opinion on how I believe a Sling model should be developed. These guidelines are by no means official standards or recommendations. As I encounter more insights on my journey, I will be updating and adding to these series.
Part 1: Creating an interface for a model
Developing a component for AEM these days means that you will write some HTL (https://docs.adobe.com/content/help/en/experience-manager-htl/using/getting-started/getting-started.html) for the presentation layer of your component. If we want to inject values from a backend into this layer, we have to make use of a Sling model. Sling models can be written in JavaScript, but the preferred and by far most use approach is to use Java for this.
When we look at general best practices for Java development, especially with a platform that allows dependency-injection and loose coupling, we often find ourselves creating interfaces and an implementation class for that interface that we annotate and use to code our business logic. This is done because an interface is generic and can be reused in multiple scenarios. We can use the same strategy for our Sling models and in this article, you will find out why this is helpful when it comes to re-usability.
Read Full Blog
Q&A
Please use this thread to ask the related questions.
Kautuk Sahni