AEM est une plateforme robuste fondée sur des technologies éprouvées, évolutives et flexibles. Ce document donne une vue d’ensemble détaillée des différentes parties qui constituent AEM et est conçu comme une annexe technique pour un développeur AEM plein pile. Il ne s’agit pas d’un guide de prise en main. Si vous découvrez AEM développement, reportez-vous à la section Prise en main du développement d’AEM Sites - Tutoriel WKND comme première étape.
Avant d’étudier les technologies de base d’AEM, Adobe recommande d’accéder à la Prise en main du développement d’AEM Sites – Tutoriel WKND
En tant que système moderne de gestion de contenu, AEM s’appuie sur des technologies web standard :
Les couches de logique commerciale et de référentiel de contenu sous-jacentes sont créées à partir des technologies Java™ :
La norme Java™ Content Repository (JCR), JSR 283, spécifie un moyen, indépendant du fournisseur et de l’implémentation, d’accéder au contenu d’un référentiel de contenu à un niveau granulaire et de manière bidirectionnelle. La spécification est gérée par Adobe Research (Suisse) AG.
Le package JCR API 2.0, javax.jcr.*
, est utilisé pour l’accès direct et la manipulation du contenu du référentiel.
AEM est basé sur un JCR.
Apache Jackrabbit Oak est une implémentation d’un référentiel de contenu hiérarchisé, évolutif et hautement performant, utilisé comme base pour des sites Web modernes de classe mondiale et d’autres applications de contenu exigeantes, conforme à la norme JCR.
Jackrabbit Oak (également appelé simplement Oak) est l’implémentation de la norme JCR sur laquelle AEM est construit.
AEM repose sur Sling, un framework d’application web basé sur des principes REST. Il facilite le développement d’applications orientées contenu. Sling utilise un référentiel JCR, comme Apache Jackrabbit Oak, servant de magasin de données. The Apache Software Foundation a contribué au développement de Sling. Plus d’informations sont disponibles sur Apache.
Avec Sling, le type de contenu à diffuser n’est pas la première considération en matière de traitement. Au lieu de cela, la principale considération est de savoir si l’URL correspond à un objet de contenu pour lequel un script peut ensuite être trouvé afin d’effectuer le rendu. Ce processus fournit une excellente prise en charge aux auteurs de contenu web pour créer des pages facilement personnalisées selon leurs besoins.
Les avantages liés à cette flexibilité sont évidents dans les applications comportant un vaste éventail d’éléments de contenu différents ou dans les cas où des pages facilement personnalisables sont nécessaires. C’est en particulier le cas pour la mise en œuvre d’un système de gestion de contenu web comme AEM.
Voir Découvrir Sling en 15 minutes pour connaître les premières étapes de développement avec Sling.
Le diagramme suivant explique la résolution du script Sling. Il indique comment passer de la requête HTTP au noeud de contenu, du noeud de contenu au type de ressource, du type de ressource au script et quelles variables de script sont disponibles.
Le diagramme suivant explique les paramètres de requête masqués, mais puissants, que vous pouvez utiliser avec SlingPostServlet
, gestionnaire par défaut pour toutes les requêtes de POST. Le gestionnaire vous offre des options infinies pour créer, modifier, supprimer, copier et déplacer des noeuds dans le référentiel.
Sling est centré sur le contenu. Cela signifie que le traitement est axé sur le contenu, car chaque requête (HTTP) est mappée sur le contenu sous la forme d’une ressource JCR (un noeud de référentiel) :
En raison de son approche centrée sur le contenu, Sling implémente un serveur orienté REST et propose ainsi un nouveau concept dans les frameworks d’applications web. Les avantages sont les suivants :
Dans Sling, le traitement est piloté par l’URL de la requête de l’utilisateur. Il définit le contenu à afficher par les scripts appropriés et les informations sont extraites de l’URL.
Analyser l’URL suivante :
https://myhost/tools/spy.printable.a4.html/a/b?x=12
Vous pouvez le diviser en plusieurs parties composites :
protocol | host | content path | selectors | Extension | Suffixe | params | |||
---|---|---|---|---|---|---|---|---|---|
https:// |
myhost |
/ |
tools/spy |
.printable.a4. |
html |
/ |
a/b |
? |
x=12 |
tools/spy.html
Selon les principes de la décomposition des URL :
La figure suivante illustre le mécanisme utilisé, qui est décrit plus en détail dans les sections suivantes.
Avec Sling, vous spécifiez le script à appliquer pour le rendu d’une entité donnée (en définissant la propriété sling:resourceType
dans le nœud JCR). Ce mécanisme offre plus de liberté que celui selon lequel le script accède aux entités de données (comme le ferait une instruction SQL dans un script PHP) puisqu’une ressource peut avoir plusieurs rendus.
La requête est décomposée et les informations nécessaires sont extraites. Recherche du référentiel pour la ressource demandée (nœud de contenu) :
../content/corporate/jobs/developer.html
../content/corporate/jobs/developer
Sling permet également à d’autres éléments que les noeuds JCR d’être des ressources, mais cette fonctionnalité est une fonctionnalité avancée.
Lorsque la ressource appropriée (nœud de contenu) est localisée, le type de ressource sling est extrait. Ce chemin localise le script à utiliser pour le rendu du contenu.
Le chemin spécifié par le sling:resourceType
peut être :
Les chemins relatifs sont recommandés par Adobe car ils contribuent à la portabilité.
Tous les scripts Sling sont stockés dans des sous-dossiers de /apps
(modifiable, scripts utilisateur) ou /libs
(inaltérable, scripts système), qui fait l’objet de recherches dans cet ordre.
Un certain nombre d’autres points sont à noter :
jobs.POST.esp
La liste des moteurs de script pris en charge par l’instance donnée d’AEM figure dans la Felix Management Console (http://<host>:<port>/system/console/slingscripting
).
En reprenant l’exemple ci-dessus, si le sling:resourceType
est hr/jobs
alors pour :
.html
(types de requête par défaut, format par défaut)
/apps/hr/jobs/jobs.esp
; la dernière section de la variable sling:resourceType
forme le nom du fichier./apps/hr/jobs/jobs.POST.esp
..html
../content/corporate/jobs/developer.pdf
./apps/hr/jobs/jobs.pdf.esp
; le suffixe est ajouté au nom du script.print
; as in ../content/corporate/jobs/developer.print.html
/apps/hr/jobs/jobs.print.esp
; le sélecteur est ajouté au nom du script.sling:resourceType
est défini, puis :
ResourceTypeProvider
est principal).../content/corporate/jobs/developer.html
génère une recherche dans /apps/content/corporate/jobs/
;.txt
), HTML (.html
), et JSON (.json
), qui répertorie toutes les propriétés du noeud (correctement formatées). Le rendu par défaut pour l’extension .res
, ou les requêtes sans extension de requête, consiste à spouler la ressource (si possible)./apps/sling/servlet/errorhandler
pour les scripts personnalisés ;/libs/sling/servlet/errorhandler/404.jsp
.Si plusieurs scripts s’appliquent pour une requête donnée, celui avec la meilleure correspondance est sélectionné. Plus une correspondance est précise, mieux c’est. En d’autres termes, plus il y a de correspondances avec les sélecteurs, mieux c’est, indépendamment de toute correspondance entre l’extension de la requête ou le nom de la méthode.
Par exemple, envisagez une demande d’accès à la ressource
/content/corporate/jobs/developer.print.a4.html
De type
sling:resourceType="hr/jobs"
En supposant que la liste de scripts à l’emplacement correct soit la suivante :
GET.esp
jobs.esp
html.esp
print.esp
print.html.esp
print/a4.esp
print/a4/html.esp
print/a4.html.esp
L’ordre de préférence serait (8) – (7) – (6) – (5) – (4) – (3) – (2) – (1).
Outre les types de ressources (principalement définis par la variable sling:resourceType
), il existe également le super type de ressource. Ce type est indiqué par la variable sling:resourceSuperType
. Ces super types sont aussi pris en compte lors de la recherche d’un script. Les super types de ressources présentent l’avantage de former une hiérarchie de ressources où le type de ressource par défaut sling/servlet/default
(utilisé par les servlets par défaut) est effectivement la racine.
Le super type de ressource d’une ressource peut être défini de deux manières :
sling:resourceSuperType
de la ressource ;sling:resourceSuperType
du nœud vers lequel pointe sling:resourceType
.Par exemple :
/
a
b
sling:resourceSuperType = a
c
sling:resourceSuperType = b
x
sling:resourceType = c
y
sling:resourceType = c
sling:resourceSuperType = a
La hiérarchie de type de :
/x
[ c, b, a, <default>]
/y
[ c, a, <default>]
La raison en est la suivante : /y
contient la variable sling:resourceSuperType
, alors que /x
ne le fait pas et son supertype est donc extrait de son type de ressource.
Dans Sling, les scripts ne peuvent pas être appelés directement, car ils violeraient le concept strict d’un serveur REST ; vous mélangeriez des ressources et des représentations.
Si vous appelez la représentation (le script) directement, vous masquez la ressource dans le script, donc le framework (Sling) ne peut plus la détecter. Vous perdez ainsi certaines fonctionnalités :
POST.jsp
dans votre emplacement sling:resourceType
Utilise le package d’API Sling, org.apache.sling.*
et les bibliothèques de balises.
En dernier lieu, il faut considérer la nécessité de référencer les éléments existants dans les scripts.
Des scripts plus complexes (agrégation de scripts) accèdent à plusieurs ressources (par exemple, navigation, barre latérale, pied de page, éléments d’une liste), en incluant la variable resource.
Dans ce cas, vous pouvez utiliser la variable sling:include("/<path>/<resource>")
. Elle inclut effectivement la définition de la ressource référencée.
OSGi désigne une architecture permettant de développer et de déployer des applications et des bibliothèques modulaires (également connu sous le nom de Dynamic Module System for Java™). Les conteneurs OSGi vous permettent de décomposer votre application en modules distincts (des fichiers jar contenant des méta-informations supplémentaires appelés « bundles » dans le jargon OSGi) et de gérer les interdépendances qui existent entre eux avec :
Ces services et contrats fournissent une architecture qui permet à des éléments particuliers de se découvrir dynamiquement les uns les autres à des fins de collaboration.
Une structure OSGi vous offre ensuite un chargement/déchargement dynamique, une configuration et un contrôle de ces lots, sans nécessiter de redémarrage.
Vous trouverez des informations complètes sur la technologie OSGi sur le site web d’OSGi.
En particulier, la page Basic Education (formation de base) contient un ensemble de présentations et de tutoriels.
Cette architecture vous permet d’étendre Sling avec des modules spécifiques à l’application. Sling, et donc AEM, utilise l’implémentation Apache Felix d’OSGi. Les deux sont des groupes de lots OSGi qui s’exécutent dans un framework OSGi.
Cette fonctionnalité vous permet d’effectuer les actions suivantes sur l’un des packages de votre installation :
Voir Configuration d’OSGi pour AEM as a Cloud Service pour plus d’informations.
La liste suivante propose une vue d’ensemble de la structure que vous verrez dans le référentiel.
/apps
– Application connexe qui inclut des définitions de composants spécifiques à votre site web. Les composants que vous développez peuvent être basés sur les composants prêts à l’emploi disponibles dans /libs/core/wcm/components
./content
– Contenu créé pour votre site web./etc
/home
– Informations sur les utilisateurs et les groupes./libs
– Bibliothèques et définitions appartenant au noyau d’AEM. Les sous-dossiers dans /libs
représentent les AEM d’usine. Le contenu de /libs
ne peut pas être modifié. Les fonctionnalités spécifiques à votre site web doivent être définies sous /apps
./tmp
– Espace de travail temporaire./var
– Fichiers qui évoluent et sont mis à jour par le système, tels que les journaux d’audit, les statistiques, la gestion des événements.Les modifications apportées à cette structure, ou aux fichiers qu’elle contient, doivent l’être prudemment. Assurez-vous de bien comprendre les implications de tout changement apporté.
Ne modifiez rien dans le chemin d’accès /libs
. Pour la configuration et d’autres modifications, copiez l’élément depuis /libs
to /apps
et apportez toute modification dans /apps
.