AEM est une plateforme robuste fondée sur des technologies éprouvées, évolutives et flexibles. Ce document contient une présentation détaillée des différentes parties constituant AEM. Il est conçu comme une annexe technique pour un développeur AEM pleine pile (c.-à-d. capable d’intervenir sur l’ensemble des composants du logiciel). Il ne s’agit pas d’un guide de prise en main. Si vous êtes novice en matière de développement AEM, consultez d’abord la Prise en main du développement d’AEM Sites – Tutoriel WKND.
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 référentiel de contenu et de logique métier 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. Il s’agit plutôt de savoir si l’URL se résout en un objet de contenu pour lequel un script peut ensuite être identifié afin d’effectuer le rendu. Les auteurs de contenu web bénéficient ainsi d’un excellent support pour créer des pages facilement personnalisables 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 schéma suivant explique la résolution du script sling : il montre comment passer de la requête HTTP au nœud de contenu, du nœud de contenu au type de ressource, du type de ressource au script, ainsi que les variables de script disponibles.
Le schéma suivant décrit tous les paramètres de requête invisibles, mais puissants, que vous pouvez utiliser avec SlingPostServlet
, le gestionnaire par défaut pour toutes les requêtes POST. Ce dernier offre des options infinies pour créer, modifier, supprimer, copier et déplacer des nœuds dans le référentiel.
Sling est centré sur le contenu. Cela signifie que le traitement est axé sur le contenu au moment où chaque requête (HTTP) est mappée avec le contenu sous la forme d’une ressource JCR (un nœud 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. C’est l’URL qui définit le contenu à afficher par les scripts appropriés. Pour ce faire, les informations sont extraites de l’URL.
Si nous analysons l’URL suivante :
https://myhost/tools/spy.printable.a4.html/a/b?x=12
Nous pouvons la décomposer comme suit :
protocol | host | content path | selector(s) | extension | suffix | param(s) | |||
---|---|---|---|---|---|---|---|---|---|
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 ci-dessous illustre le mécanisme (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. Une recherche de la ressource demandée (nœud de contenu) est effectuée dans le référentiel :
../content/corporate/jobs/developer.html
../content/corporate/jobs/developer
Sling permet également à des éléments autres que des nœuds JCR d’être des ressources, mais il s’agit là d’une fonctionnalité avancée.
Lorsque la ressource appropriée (nœud de contenu) est localisée, le type de ressource sling est extrait. C’est un chemin qui 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 /apps
(modifiables, scripts utilisateur) ou /libs
(non modifiables, scripts système), qui seront recherchés 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 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
; comme dans ../content/corporate/jobs/developer.print.html
/apps/hr/jobs/jobs.print.esp
; le sélecteur est ajouté au nom du script.sling:resourceType
n’a été défini, alors :
ResourceTypeProvider
basé sur un chemin est actif) ;../content/corporate/jobs/developer.html
génère une recherche dans /apps/content/corporate/jobs/
;.txt
), HTML (.html
) et JSON (.json
) en répertoriant toutes les propriétés du nœud (correctement mises en forme). 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 spécifique, mieux c’est. En d’autres termes, plus le sélecteur correspond meilleur est le résultat, quelle que soit l’extension de requête ou la correspondance de nom de 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 les scripts suivants sont présents dans l’emplacement correct :
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).
En plus des types de ressources (principalement définis par la propriété sling:resourceType
), il existe également le super type de ressource. Il est généralement indiqué par la propriété 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>]
Ceci est dû au fait que /y
possède la propriété sling:resourceSuperType
contrairement à /x
, et donc son super type est issu de son type de ressource.
Dans Sling, les scripts ne peuvent pas être appelés directement car cela est contraire au strict concept d’un serveur REST. Sinon, vous mélangeriez les ressources et les 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. Ainsi, vous perdez certaines fonctionnalités :
POST.jsp
dans votre emplacement sling:resourceType
Il s’agit du package d’API Sling, org.apache.sling.*
, et des 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) peuvent demander un accès à plusieurs ressources (par exemple, navigation, barre latérale, pied de page, éléments d’une liste) en ajoutant resource.
Pour ce faire, vous pouvez utiliser la commande sling:include("/<path>/<resource>")
. Vous inclurez ainsi 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 forment une architecture permettant à des éléments distincts de se détecter dynamiquement pour la collaboration.
Le framework OSGi offre ensuite le chargement/déchargement dynamique, la configuration et le contrôle de ces bundles, 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 en lui ajoutant des modules spécifiques aux applications. Sling, et donc AEM, utilise l’implémentation Apache Felix d’OSGi. Ce sont deux ensembles de bundles OSGi exécutés dans un framework OSGi.
Cette extension permet d’appliquer les actions suivantes à l’un des modules dans votre installation :
Voir Configuration d’OSGi pour AEM as a Cloud Service pour plus d’informations.
La liste suivante donne un aperçu 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 de /libs
représentent les fonctionnalités AEM prêtes à l’emploi. 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é.
Vous ne devez rien modifier dans le chemin /libs
. Pour la configuration et d’autres modifications, copiez l’élément de /libs
dans /apps
et apportez des modifications dans /apps
.