API DE AEM

Las API de AEM proporcionan abstracciones y funcionalidades específicas para casos de uso producidos.

Por ejemplo, las API PageManager y Page de AEM proporcionan abstracciones para cq:Page nodos en AEM que representan páginas web.

Aunque estos nodos están disponibles a través de las API Sling como recursos y las API JCR como nodos, las API de AEM proporcionan abstracciones para casos de uso comunes. El uso de las API de AEM garantiza un comportamiento coherente entre AEM y el producto, así como las personalizaciones y extensiones de AEM.

com.adobe.* frente a com.day.API de *

Las API de AEM tienen una preferencia dentro del paquete, identificada por los siguientes paquetes Java™, en orden de preferencia:

  1. com.adobe.cq
  2. com.adobe.granite
  3. com.day.cq

El paquete com.adobe.cq admite casos de uso de productos, mientras que com.adobe.granite admite casos de uso de plataformas entre productos, como flujos de trabajo o tareas (que se utilizan en distintos productos: AEM Assets, sitios, etc.).

El paquete com.day.cq contiene las API "originales". Estas API tratan las abstracciones y funcionalidades básicas que existían antes o alrededor de la adquisición de Day CQ por Adobe. Estas API son compatibles y deben evitarse, a menos que los paquetes com.adobe.cq o com.adobe.granite NO proporcionen una alternativa (más reciente).

Las nuevas abstracciones como Content Fragments y Experience Fragments se crean en el espacio com.adobe.cq en lugar de com.day.cq, como se describe a continuación.

API de consulta

AEM admite varios idiomas de consulta. Los tres idiomas principales son JCR-SQL2, XPath y AEM Query Builder.

La preocupación más importante es mantener un lenguaje de consulta coherente en toda la base de código para reducir la complejidad y el coste de comprensión.

Todos los lenguajes de consulta tienen efectivamente los mismos perfiles de rendimiento, ya que Apache Oak los transpila en JCR-SQL2 para la ejecución final de la consulta, y el tiempo de conversión a JCR-SQL2 es insignificante en comparación con el propio tiempo de consulta.

La API preferida es AEM Query Builder, que es la abstracción de nivel más alto y proporciona una API sólida para construir, ejecutar y recuperar resultados para consultas, además de lo siguiente:

CAUTION
La API de AEM QueryBuilder filtra un objeto ResourceResolver. Para mitigar esta fuga, siga este ejemplo de código.

API de Sling

Apache Sling es el marco web RESTful en el que se basa AEM. Sling proporciona enrutamiento de solicitud HTTP, modela nodos JCR como recursos, proporciona contexto de seguridad y mucho más.

Las API de Sling tienen la ventaja añadida de crearse para la extensión, lo que significa que a menudo es más fácil y seguro aumentar el comportamiento de las aplicaciones creadas con las API de Sling que las API de JCR menos ampliables.

Usos comunes de las API Sling

API de JCR

Las API JCR (repositorio de contenido Java™) 2.0 forman parte de una especificación para implementaciones JCR (en el caso de AEM, Apache Jackrabbit Oak). Toda implementación de JCR debe cumplir e implementar estas API y, por lo tanto, es la API de nivel más bajo para interactuar con el contenido de AEM.

El JCR es un almacén de datos NoSQL basado en árbol/jerárquico que AEM utiliza como repositorio de contenido. El JCR tiene una amplia gama de API compatibles, que van desde el CRUD de contenido a la consulta de contenido. A pesar de esta API sólida, es poco frecuente que se prefieran a las abstracciones de nivel superior de AEM y Sling.

Prefiera siempre las API de JCR sobre las API de Apache Jackrabbit Oak. Las API de JCR son para interactuar con un repositorio JCR, mientras que las API de Oak son para implementar un repositorio JCR.