Prácticas recomendadas de API de Java™
Adobe Experience Manager AEM () se basa en una pila de software de código abierto enriquecida que expone muchas API de Java™ para utilizarlas durante el desarrollo. Este artículo explora las principales API y cuándo y por qué deben utilizarse.
AEM Se basa en cuatro conjuntos principales de API de Java™.
-
Adobe Experience Manager AEM ()
- Abstracciones de productos como páginas, recursos, flujos de trabajo, etc.
-
Marco web de Apache Sling
- REST y abstracciones basadas en recursos como recursos, mapas de valores y solicitudes HTTP.
-
JCR (Apache Jackrabbit Oak)
- Resumen de datos y contenido, como nodos, propiedades y sesiones.
-
OSGi (Apache Felix)
- Abstracciones del contenedor de aplicaciones OSGi, como servicios y componentes (OSGi).
Preferencia de la API de Java™ "regla general"
La regla general es preferir las API/abstracciones en el siguiente orden:
- AEM
- Sling
- JCR
- OSGi
AEM Si el usuario proporciona una API, la prefiere en lugar de Sling, JCR y OSGi. AEM Si no proporciona una API, prefiera Sling sobre JCR y OSGi.
Este orden es una regla general, lo que significa que existen excepciones. Los motivos aceptables para romper esta regla son:
-
Excepciones conocidas, como se describe a continuación.
-
La funcionalidad requerida no está disponible en una API de nivel superior.
-
AEM Operar en el contexto de un código existente (código de producto personalizado o) que utiliza una API menos preferida y el coste de pasar a la nueva API es injustificable.
- Es mejor utilizar de forma consistente la API de nivel inferior que crear una mezcla.
API DE AEM
AEM Las API de proporcionan abstracciones y funcionalidades específicas para casos de uso producidos.
AEM AEM Por ejemplo, la API de PageManager y Page que se utilizan para la creación de páginas web proporciona abstracciones para nodos de cq:Page
en las páginas web que representan páginas web.
AEM Aunque estos nodos están disponibles a través de las API Sling como recursos y las API JCR como nodos, las API de proporcionan abstracciones para casos de uso comunes. AEM AEM AEM El uso de las API de garantiza un comportamiento coherente entre el producto, las personalizaciones y las extensiones de los productos y las extensiones de los que se puede obtener un.
com.adobe.* frente a com.day.API de *
AEM Las API de tienen una preferencia dentro del paquete, identificada por los siguientes paquetes Java™, en orden de preferencia:
com.adobe.cq
com.adobe.granite
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, Sites, 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 parte de 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. AEM Los tres idiomas principales son JCR-SQL2, XPath y Generador de consultas.
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.
AEM La API preferida es Generador de consultas, 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, proporciona lo siguiente:
-
Construcción de consultas sencilla y parametrizada (parámetros de consulta modelados como un mapa)
-
AEM predicados de que admiten requisitos de consulta comunes
-
API extensible, que permite el desarrollo de predicados de consulta personalizados
-
JCR-SQL2 y XPath se pueden ejecutar directamente a través de Sling y API de JCR, lo que devuelve los resultados de Sling Resources o JCR Nodes, respectivamente.
API de Sling
AEM Apache Sling es el marco web RESTful en el que se basa el código de tiempo de ejecución de los recursos de la red de. 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
-
Acceder a nodos JCR como Sling Resources y acceder a sus datos a través de ValueMaps.
-
Proporcionando contexto de seguridad mediante ResourceResolver.
-
Creando y eliminando recursos mediante los métodos create/move/copy/delete de ResourceResolver.
-
Actualizando propiedades mediante ModillableValueMap.
-
Bloques de creación del procesamiento de solicitudes
-
Bloques de creación de procesamiento de trabajo asincrónico
API de JCR
AEM Las API JCR (Java™ Content Repository) 2.0 forman parte de una especificación para implementaciones JCR (en el caso de Apache Jackrabbit Oak, que se encuentra en el repositorio de JCR . AEM Toda implementación de JCR debe ajustarse a estas API e implementarlas; por lo tanto, es la API de nivel más bajo para interactuar con contenido de la.
AEM El propio JCR es un almacén de datos NoSQL basado en árbol/jerárquico que utiliza como repositorio de contenido el. El JCR tiene una amplia gama de API compatibles, que van desde el CRUD de contenido a la consulta de contenido. AEM A pesar de esta API robusta, es poco frecuente que se prefieran a las abstracciones de nivel superior y de Sling de nivel superior.
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.
Conceptos erróneos comunes sobre las API de JCR
AEM Aunque el JCR es el repositorio de contenido que está utilizando, sus API NO son el método preferido para interactuar con el contenido. AEM En su lugar, prefiera las API de recursos de Sling (Página, Assets, Etiqueta, etc.) o las API de recursos de Sling, ya que proporcionan mejores abstracciones.
Usos comunes de las API de JCR
-
Observación de JCR (escucha de eventos JCR)
-
Creación de estructuras de nodos profundos
API de OSGi
AEM AEM Hay poca superposición entre las API de OSGi y las API de nivel superior (, Sling y JCR), y la necesidad de utilizar las API de OSGi es poco frecuente y requiere un alto nivel de experiencia en desarrollo de la.
API de OSGi y Apache Felix
OSGi define una especificación que todos los contenedores OSGi deben implementar y cumplir. AEM la implementación de OSGi, Apache Felix, también proporciona varias API propias.
- Prefiera las API OSGi (
org.osgi
) sobre las API Apache Felix (org.apache.felix
).
Usos comunes de las API de OSGi
-
Anotaciones OSGi para declarar servicios y componentes OSGi.
- Prefiera OSGi Declarative Services (DS) 1.2 Annotations sobre Felix SCR Annotations para declarar servicios y componentes OSGi
-
API OSGi para anular el registro de servicios o componentes OSGi de forma dinámica en el código.
- Prefiera el uso de anotaciones OSGi DS 1.2 cuando no sea necesario administrar el servicio o el componente OSGi condicional (como suele ser el caso).
Excepciones a la regla
Las siguientes son excepciones comunes a las reglas definidas anteriormente.
API de OSGi
Cuando se tratan abstracciones OSGi de bajo nivel, como definir o leer en propiedades de componentes OSGi, las abstracciones más nuevas proporcionadas por org.osgi
se prefieren a las abstracciones de Sling de alto nivel. Las abstracciones de Sling que compiten no se han marcado como @Deprecated
y sugieren la alternativa org.osgi
.
Tenga en cuenta también que la definición del nodo de configuración OSGi prefiere cfg.json
sobre el formato sling:OsgiConfig
.
AEM API de recursos de
-
Preferir
com.day.cq.dam.api
sobrecom.adobe.granite.asset.api
.- Mientras que las API de Assets AEM
com.day.cq
proporcionan herramientas más gratuitas para la administración de recursos en los casos de uso de la administración de recursos en la que se puede hacer un uso más. - Las API de Granite Assets admiten casos de uso de administración de recursos de bajo nivel (versión, relaciones).
- Mientras que las API de Assets AEM
API de consulta
- AEM QueryBuilder no admite determinadas funciones de consulta, como sugerencias, revisión ortográfica y sugerencias de índice, entre otras funciones menos comunes. Para consultar con estas funciones, se prefiere JCR-SQL2.
Registro de servlet Sling sling-servlet-registration
- Registro de servlet Sling, prefiere anotaciones OSGi DS 1.2 con @SlingServletResourceTypes sobre
@SlingServlet
Registro de filtro Sling sling-filter-registration
- Registro de filtro Sling, prefiere anotaciones OSGi DS 1.2 con @SlingServletFilter sobre
@SlingFilter
Fragmentos de código útiles
Los siguientes son fragmentos de código Java™ útiles que ilustran las prácticas recomendadas para casos de uso comunes mediante las API analizadas. Estos fragmentos también ilustran cómo pasar de API menos preferidas a API más preferidas.
Sesión JCR a ResourceResolver Sling
Cierre automático de ResourceResolver de Sling
AEM Desde la versión 6.2, el ResourceResolver de Sling es AutoClosable
en una instrucción try-with-resources. Con esta sintaxis, no es necesaria una llamada explícita a resourceResolver .close()
.
@Reference
ResourceResolverFactory rrf;
...
Map<String, Object> authInfo = new HashMap<String, Object>();
authInfo.put(JcrResourceConstants.AUTHENTICATION_INFO_SESSION, jcrSession);
try (ResourceResolver resourceResolver = rrf.getResourceResolver(authInfo)) {
// Do work with the resourceResolver
} catch (LoginException e) { .. }
Sling ResourceResolver cerrado manualmente
ResourceResolvers se puede cerrar manualmente en un bloque finally
si no se puede utilizar la técnica de cierre automático que se muestra arriba.
@Reference
ResourceResolverFactory rrf;
...
Map<String, Object> authInfo = new HashMap<String, Object>();
authInfo.put(JcrResourceConstants.AUTHENTICATION_INFO_SESSION, jcrSession);
ResourceResolver resourceResolver = null;
try {
resourceResolver = rrf.getResourceResolver(authInfo);
// Do work with the resourceResolver
} catch (LoginException e) {
...
} finally {
if (resourceResolver != null) { resourceResolver.close(); }
}
Ruta JCR a Sling Resource
Resource resource = ResourceResolver.getResource("/path/to/the/resource");
Nodo JCR a Sling Resource
Resource resource = resourceResolver.getResource(node.getPath());
AEM Sling Resource a recurso de la
Enfoque recomendado
La función DamUtil.resolveToAsset(..)
resuelve cualquier recurso bajo dam:Asset
en el objeto Asset subiendo por el árbol según sea necesario.
Asset asset = DamUtil.resolveToAsset(resource);
Enfoque alternativo
La adaptación de un recurso a un recurso requiere que el recurso en sí sea el nodo dam:Asset
.
Asset asset = resource.adaptTo(Asset.class);
AEM Sling recurso a página de la
Enfoque recomendado
pageManager.getContainingPage(..)
resuelve cualquier recurso bajo cq:Page
en el objeto Página subiendo por el árbol según sea necesario.
PageManager pageManager = resourceResolver.adaptTo(PageManager.class);
Page page = pageManager.getContainingPage(resource);
Page page2 = pageManager.getContainingPage("/content/path/to/page/jcr:content/or/component");
Enfoque alternativo alternative-approach-1
Para adaptar un recurso a una página, el propio recurso debe ser el nodo cq:Page
.
Page page = resource.adaptTo(Page.class);
AEM Leer propiedades de página
Utilice los captadores del objeto Page para obtener propiedades conocidas (getTitle()
, getDescription()
, etc.) y page.getProperties()
para obtener el ValueMap [cq:Page]/jcr:content
para recuperar otras propiedades.
Page page = resource.adaptTo(Page.class);
String title = page.getTitle();
Calendar value = page.getProperties().get("cq:lastModified", Calendar.getInstance());
AEM Leer propiedades de metadatos de recursos
La API de recursos proporciona métodos prácticos para leer propiedades del nodo [dam:Asset]/jcr:content/metadata
. No es un ValueMap; no se admite el segundo parámetro (valor predeterminado y conversión de tipo automático).
Asset asset = resource.adaptTo(Asset.class);
String title = asset.getMetadataValue("dc:title");
Calendar lastModified = (Calendar) asset.getMetadata("cq:lastModified");
Leer propiedades de Sling Resource read-sling-resource-properties
AEM Cuando las propiedades se almacenan en ubicaciones (propiedades o recursos relativos) a las que las API de (Página, Recurso) no pueden acceder directamente, se pueden utilizar los recursos Sling y ValueMaps para obtener los datos.
ValueMap properties = resource.getValueMap();
String value = properties.get("jcr:title", "Default title");
String relativeResourceValue = properties.get("relative/propertyName", "Default value");
AEM En este caso, es posible que el objeto de tenga que convertirse en un Sling Resource para localizar de forma eficaz la propiedad o el subrecurso deseado.
AEM Página a Sling Resource
Resource resource = page.adaptTo(Resource.class);
AEM Recurso de a Sling Resource
Resource resource = asset.adaptTo(Resource.class);
Escribir propiedades utilizando ModillableValueMap de Sling
Use ModillableValueMap de Sling para escribir propiedades en nodos. Esto solo puede escribir en el nodo inmediato (no se admiten las rutas de propiedad relativas).
Tenga en cuenta que la llamada a .adaptTo(ModifiableValueMap.class)
requiere permisos de escritura en el recurso; de lo contrario, devuelve un valor nulo.
ModifiableValueMap properties = resource.adaptTo(ModifiableValueMap.class);
properties.put("newPropertyName", "new value");
properties.put("propertyNameToUpdate", "updated value");
properties.remove("propertyToRemove");
resource.getResourceResolver().commit();
AEM Creación de una página de
AEM Utilice siempre PageManager para crear páginas a medida que se necesita una plantilla de página; es necesario para definir e inicializar correctamente las páginas en los recursos de la plantilla de página de.
String templatePath = "/conf/my-app/settings/wcm/templates/content-page";
boolean autoSave = true;
PageManager pageManager = resourceResolver.adaptTo(PageManager.class);
pageManager.create("/content/parent/path", "my-new-page", templatePath, "My New Page Title", autoSave);
if (!autoSave) { resourceResolver.commit(); }
Crear un recurso de Sling
ResourceResolver admite operaciones básicas para crear recursos. AEM Al crear abstracciones de nivel superior (Páginas de, Assets, Etiquetas, etc.), utilice los métodos proporcionados por sus respectivos responsables.
resourceResolver.create(parentResource, "my-node-name", new ImmutableMap.Builder<String, Object>()
.put("jcr:primaryType", "nt:unstructured")
.put("jcr:title", "Hello world")
.put("propertyName", "Other initial properties")
.build());
resourceResolver.commit();
Eliminar un recurso de Sling
ResourceResolver admite la eliminación de un recurso. AEM Al crear abstracciones de nivel superior (Páginas de, Assets, Etiquetas, etc.), utilice los métodos proporcionados por sus respectivos responsables.
resourceResolver.delete(resource);
resourceResolver.commit();