API d’AEM

Les API d’AEM fournissent des abstractions et des fonctionnalités spécifiques aux cas d’utilisation productifs.

Par exemple, les API AEM PageManager et Page fournissent des abstractions pour les nœuds cq:Page dans AEM représentant les pages web.

Alors que ces nœuds sont disponibles via les API Sling en tant que ressources et via les API JCR en tant que nœuds, les API AEM fournissent des abstractions pour les cas d’utilisation courants. L’utilisation des API d’AEM permet d’assurer un comportement cohérent entre AEM, le produit, ainsi que les personnalisations et les extensions d’AEM.

com.adobe.* et com.day.* API

Les API d’AEM ont une préférence intra-package, identifiée par les packages Java™ suivants, par ordre de préférence :

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

Le package com.adobe.cq prend en charge les cas d’utilisation de produits, alors que com.adobe.granite prend en charge les cas d’utilisation de plateformes inter-produits, tels que les workflows et les tâches (qui sont utilisés dans plusieurs produits : AEM Assets, Sites, etc.).

Le package com.day.cq contient des API « originales ». Ces API traitent des abstractions et fonctionnalités de base qui existaient avant et/ou autour de l’acquisition par Adobe de Day CQ. Ces API sont prises en charge et doivent être évitées, sauf si les packages com.adobe.cq ou com.adobe.granite ne fournissent PAS d’alternative (plus récente).

De nouvelles abstractions telles que Content Fragments et Experience Fragments sont conçues dans l’espace com.adobe.cq plutôt que celui com.day.cq décrit ci-dessous.

API de requête

AEM prend en charge plusieurs langages de requête. Les trois langages principaux sont : JCR-SQL2, XPath et AEM Query Builder.

La préoccupation la plus importante est de conserver un langage de requête cohérent dans l’ensemble de la base de code, afin de réduire la complexité et les coûts de compréhension.

Tous les langages de requête possèdent effectivement les mêmes profils de performance, comme Apache Oak les transpile vers JCR-SQL2 pour l’exécution de la requête finale, et le temps de conversion vers JCR-SQL2 est négligeable par rapport au temps de requête lui-même.

L’API préférée est AEM Query Builder, qui constitue le niveau d’abstraction le plus élevé et fournit une API robuste pour la création, l’exécution et la récupération des résultats des requêtes, et fournit les éléments suivants :

CAUTION
L’API QueryBuilder AEM produit une fuite d’un objet ResourceResolver. Pour atténuer cette fuite, suivez cet exemple de code.