为什么在使用AEM时扩展了WCMUsePojo类？ [英] Why we extends WCMUsePojo class while working with AEM?

问题描述

为什么在使用AEM时在程序中扩展WCMUsepojo抽象类？

Why we extends WCMUsepojo abstract class in our program while working with AEM?

使用此类的好处是什么？

What is the advantage of using this class?

推荐答案

由于AEM的组件开发机制，您可能需要一种为组件提供后端逻辑的方法。

Because in AEM’s component development mechanism, you likely need a way to provide back-end logic to components.

这是因为漂亮的（当用作呈现脚本语言而不是 JSP 页面）是一种有限的模板语言，仅允许执行少量基本操作，繁重的逻辑应在 Java 类或服务器端JS （您使用Sightly脚本中的 data-sly-use 元素引用）。

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.

为了使用页面上下文或绑定对象抽象组件Java类，以前使用了Adobe的 WCMUse 或Use类的自定义实现。如果您使用的是AEM 6.1或6.2，请使用 WCMUsePojo 类（甚至是Sling模型）。随着AEM 6.3和AEM Core WCM组件的发布，我们看到Adobe提倡使用 Sling模型作为最佳实践。

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.

这篇关于为什么在使用AEM时扩展了WCMUsePojo类？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！