Why we extends WCMUsepojo abstract class in our program while working with AEM?
What is the advantage of using this class?
2 Answers
7
votes
Because in AEM’s component development mechanism, you likely need a way to provide back-end logic to components.
That's because Sightly (when used as a rendering script language instead of the JSP pages) is on purpose a limited template language that allows to do only small basic operations, and the heavy lifting logic should be done inside a Java class or a server-side JS (that you refer using the data-sly-use element inside the Sightly script).
This provide better decoupling of the business logic and so your code will be more easily maintainable and also easier to debug.
In order to abstract component Java class with page context or binding objects, previously Adobe’s WCMUse was used, or a custom implementation of Use class. If your working with AEM 6.1 or 6.2 WCMUsePojo class is used (or even Sling Models). With the release of AEM 6.3 and AEM Core WCM Components, we see that using Sling Models have been advocated by Adobe as the best practice.
2
votes
While the previous answer gives a pretty good explanation, I will write my own - brief one:
- You can use simple Pojo (do not extend any Adobe's class) with java-use-api. But in this case, you will not be able to easily access resources/services.
- You can extend WCMUsePojo to get the ability to use resources/services.
- Also, you can go with Sling Models way which will give you more flexibility.
