Vous consultez actuellement l'aide de la version:

Remarque :

Avant d’étudier les concepts de base d’AEM, Adobe vous recommande de suivre le tutoriel WKND dans le document Prise en main du développement de sites AEM pour un aperçu du processus de développement AEM et une introduction aux concepts clés.

Pré-requis pour développer sur AEM

Vous aurez besoin des compétences suivantes pour développer sur AEM :

  • Une connaissance élémentaire des techniques d’application web, y compris :
    • le cycle de requête-réponse (XMLHttpRequest/XMLHttpResponse)
    • HTML
    • CSS
    • JavaScript
  • Une connaissance pratique d’Experience Server (CRX), y compris Content Explorer
  • Pour développer dans l’IU classique, connaissances rudimentaires de JSP (JavaServer Pages), notamment comprendre et savoir modifier des exemples JSP simples.

Il est également recommandé de lire et de suivre les Recommandations et bonnes pratiques.

Référentiel de contenu 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.

Les spécifications sont gérées par Adobe Research (Suisse) AG.

Le module JCR API 2.0, javax.jcr.* est utilisé pour l’accès direct et la manipulation du contenu du référentiel.

Experience Server (CRX) et Jackrabbit

Experience Server fournit des services Experience sur lesquels AEM est basé et qui peuvent servir à créer des applications personnalisées. Il intègre le référentiel de contenu basé sur Jackrabbit.

Apache Jackrabbit est une implémentation open source entièrement conforme de l’API JCR 2.0.

Traitement de requête Sling

Introduction à Sling

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, tel que Apache Jackrabbit, ou dans le cas d’AEM, le référentiel de contenu CRX, comme 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. En particulier, lors de la mise en œuvre d’un système de gestion de contenu web comme celui de la solution 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 sont disponibles.

chlimage_1

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.

chlimage_1

Sling est centré sur le contenu

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) :

  • la première cible est la ressource (nœud JCR) contenant le contenu

  • ensuite, la représentation, ou script, est localisée à partir des propriétés de ressource en combinaison avec certaines parties de la requête (par exemple des sélecteurs et/ou l’extension)

Sling RESTful

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 :

  • très bon niveau RESTful, pas seulement en surface ; les ressources et les représentations sont correctement modélisées dans le serveur

  • supprime un ou plusieurs modèles de données

    • auparavant, les éléments suivants étaient nécessaires : structure d’URL, objets métier, schéma de base de données ;

    • ils sont désormais réduits à : URL = ressource = structure JCR

Décomposition d’URL

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 :

http://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) 
http:// myhost tools/spy .printable.a4. html / a/b ? x=12

protocol

HTTP

host

Nom du site web.

content path

Chemin d’accès spécifiant le contenu à rendre. Est utilisé en combinaison avec l’extension. Dans cet exemple, on obtient tools/spy.html.

selector(s)

Utilisé pour les méthodes secondaires de rendu du contenu. Dans cet exemple, on obtient la version imprimable au format A4.

extension

Format de contenu. Spécifie également le script à utiliser pour le rendu.

suffix

Peut servir à spécifier des informations supplémentaires.

param(s)

Tous les paramètres requis pour le contenu dynamique.

De l’URL au contenu et aux scripts

Selon ces principes :

  • le mappage utilise le chemin d’accès au contenu extrait de la requête pour localiser la ressource

  • lorsque la ressource appropriée est localisée, le type de ressource sling est extrait et utilisé pour localiser le script à appliquer pour le rendu du contenu

La figure ci-dessous illustre le mécanisme (décrit plus en détail dans les sections suivantes).

chlimage_1

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.

Mappage des requêtes avec les ressources

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 :

  • d’abord, Sling vérifie si un nœud existe à l’emplacement spécifié dans la requête. Par exemple. ../content/corporate/jobs/developer.html

  • si aucun nœud n’est identifié, l’extension est supprimée et la recherche recommence ; par exemple. ../content/corporate/jobs/developer

  • si aucun nœud n’est trouvé, Sling retourne le code http 404 (Not Found).

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.

Localisation du script

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 :

  • absolu
  • relatif à un paramètre de configuration
    . Les chemins relatifs sont recommandés par Adobe car ils augmentent la portabilité.

Tous les scripts Sling sont stockés dans des sous-dossiers /apps ou /libs qui font l’objet d’une recherche dans cet ordre (voir Personnalisation de composants et d’autres éléments).

Autres points à noter sont :

  • si la méthode (GET, POST) est requise, elle est indiquée en majuscules selon la spécification HTTP, par ex. jobs.POST.esp (voir ci-dessous)
  • divers moteurs de script sont pris en charge :
    • .esp, .ecma : pages ECMAScript (JavaScript) (exécution côté serveur)
    • .jsp : Java Server Pages (exécution côté serveur)
    • .java : Java Servlet Compiler (exécution côté serveur)
    • .jst : modèles JavaScript (exécution côté client)

La liste des moteurs de script pris en charge par l’instance donnée de CQ figure dans la Felix Management Console (http://localhost:4502/system/console/config/slingscripting.txt ).

En outre, Apache Sling prend en charge l’intégration avec d’autres moteurs de script répandus (par exemple, Groovy, JRuby, Freemarker) et offre un moyen d’intégrer de nouveaux moteurs de script.

En reprenant l’exemple ci-dessus, si sling:resourceType est hr/jobs alors pour :

  • Requêtes GET/HEAD et URL se terminant par .html (types de requêtes par défaut, format par défaut)
    Le script est /apps/hr/jobs/jobs.esp et la dernière section de sling:resourceType forme le nom du fichier.
  • Requêtes POST (tous les types de requêtes à l’exception de GET/HEAD, le nom de la méthode doit être en majuscules)
    POST est utilisé dans le nom du script.
    Le script est /apps/hr/jobs/jobs.POST.esp.
  • URL dans d’autres formats, ne se terminant pas par .html
    Par exemple ../content/corporate/jobs/developer.pdf
    Le script est apps/hr/jobs/jobs.pdf.esp/ et le suffixe est ajouté au nom du script.
  • URL avec sélecteurs
    Les sélecteurs peuvent être utilisés pour afficher le même contenu dans un autre format. Par exemple une version imprimable, un flux rss ou un résumé.
    Si nous prenons l’exemple d’une version imprimable où le sélecteur pourrait être print ; comme dans ../content/corporate/jobs/developer.print.html
    Le script est /apps/hr/jobs/jobs.print.esp et le sélecteur est ajouté au nom du script.
  • Si aucun sling:resourceType a été défini alors :
    • le chemin d’accès au contenu est utilisé pour rechercher un script correspondant (si ResourceTypeProvider basé sur un chemin est actif).
      Par exemple, le script pour ../content/corporate/jobs/developer.html génère une recherche dans /apps/content/corporate/jobs/.
    • le type de nœud principal est utilisé.
  • Si aucun script n’est trouvé, le script par défaut est utilisé.
    Le rendu par défaut est actuellement pris en charge sous la forme de texte brut (.txt), HTML (.html) et JSON (.json) qui répertorie 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).
  • Pour la gestion des erreurs http (codes 403 ou 404), Sling recherche un script dans :
    • l’emplacement /apps/sling/servlet/errorhandler pour scripts personnalisés
    • ou l’emplacement des scripts standard /libs/sling/servlet/errorhandler/403.esp ou 404.esp respectivement.

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.

Prenons l’exemple d’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 :

  1. GET.esp
  2. jobs.esp
  3. html.esp
  4. print.esp
  5. print.html.esp
  6. print/a4.esp
  7. print/a4/html.esp
  8. 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 :

  • par la propriété sling:resourceSuperType de la ressource.
  • par la propriété 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 est [c, b, a, <par défaut>] tandis que pour /y la hiérarchie est [c, a,<par défaut>] car /y possède la propriété sling:resourceSuperType contrairement à /x, donc son supertype est issu de son type de ressource.

Les scrips Sling ne peuvent pas être appelés directement

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 :

  • le traitement automatique des méthodes http autres que GET, y compris :

    • les méthodes POST, PUT, DELETE qui sont gérées avec une implémentation par défaut de Sling

    • le script POST.jsp dans votre emplacement sling:resourceType

  • l’architecture du code perd de son intégrité et de sa structure qui sont primordiales dans les développements à grande échelle

API Sling

Elle utilise le module API Sling org.apache.sling.* et ses bibliothèques de balises.

Référencement d’éléments existants avec sling:include

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("/<chemin>/<ressource>"). Cela inclut effectivement la définition de la ressource référencée, comme dans l’instruction suivante qui fait référence à une définition existante pour le rendu des images :

%><sling:include resourceType="geometrixx/components/image/img"/><% 

OSGI

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 :

  • des services mis en œuvre dans le conteneur
  • un contrat entre le conteneur et votre application

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.

Remarque :

Vous trouverez des informations complètes sur la technologie OSGi dans OSGi Alliance Technology Overview.

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 CQ5, utilise l’implémentation Apache Felix d’OSGI (Open Services Gateway Initiative) et est basé sur les spécifications OSGi Service Platform Release 4, Version 4.2. 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 :

  • installation
  • démarrage
  • arrêt
  • mise à jour
  • désinstallation
  • voir l’état actuel
  • accéder à des informations plus détaillées (par exemple, nom symbolique, version, emplacement, etc.) pour des bundles en particulier

Pour plus d’informations, reportez-vous à Console web, Configuration OSGI et Paramètres de configuration OSGi.

Objets de développement dans l’environnement AEM

Les éléments suivants présentent un intérêt pour le développement :

Objets Item

Un élément est un nœud ou une propriété.

Pour plus d’informations sur la manipulation des objets Item, reportez-vous aux Javadocs de l’interface javax.jcr.Item.

Objets Node (et leurs propriétés)

Les nœuds et les propriétés sont définis dans la spécification de l’API JCR 2.0 (JSR 283). Ils stockent le contenu, les définitions d’objets, les scripts de rendu et d’autres données.

Les nœuds définissent la structure du contenu et leurs propriétés stockent le contenu réel et les métadonnées.

Les nœuds de contenu pilotent le rendu. Sling récupère le nœud de contenu de la requête entrante. La propriété sling:resourceType de ce nœud pointe vers le composant de rendu Sling à utiliser.

Un nœud, qui est un nom JCR, est également appelé « ressource » dans l’environnement Sling.

Par exemple, pour obtenir les propriétés du nœud actif, vous pouvez utiliser le code suivant dans votre script :

    PropertyIterator properties = currentNode.getProperties();

currentNode étant l’objet du nœud actif.

Pour plus d’informations sur la manipulation des objets Node, reportez-vous aux Javadocs.

Widget

Dans AEM, toutes les entrées utilisateur sont gérées par des widgets. Ceux-ci sont souvent utilisés pour contrôler la modification d’un contenu.

Les boîtes de dialogue sont construites en combinant des Widgets.

AEM a été développé à partir de la bibliothèque de widgets ExtJS.

Boîte de dialogue

Une boîte de dialogue est un type spécial de widget.

Pour modifier le contenu, AEM utilise des boîtes de dialogue définies par le développeur de l’application. Celles-ci combinent une série de widgets pour présenter à l’utilisateur tous les champs et toutes les actions nécessaires pour modifier le contenu associé.

Les boîtes de dialogue servent également à modifier les métadonnées et sont utilisées par divers outils d’administration.

Composant

Un composant logiciel est un élément système offrant un service ou un événement prédéfini et capable de communiquer avec d’autres composants.

Dans AEM, un composant est souvent utilisé pour effectuer le rendu du contenu d’une ressource. Lorsque la ressource est une page, le composant chargé de son rendu est appelé « composant de niveau supérieur » ou « composant de page ». Cependant, un composant n’effectue pas nécessairement le rendu de contenu, ni n’est lié à une ressource spécifique. Par exemple, un composant de navigation affiche des informations sur plusieurs ressources.

La définition d’un composant comprend :

  • le code utilisé pour le rendu du contenu

  • une boîte de dialogue pour la saisie utilisateur et la configuration du contenu résultant.

Modèle

Un modèle ou template est la base d’un type de page spécifique. Lors de la création d’une page dans l’onglet Sites web, l’utilisateur doit sélectionner un modèle. La nouvelle page est ensuite créée en copiant ce modèle.

Un modèle est une hiérarchie de nœuds qui a la même structure que la page à créer, mais sans contenu réel.

Il définit le composant de page utilisé pour afficher la page et le contenu par défaut (contenu principal de premier niveau). Le contenu définit la façon dont il est rendu car AEM est centré sur le contenu.

Composant de page (composant de niveau supérieur)

Le composant à utiliser pour rendre la page.

Page

Une page est une « instance » d’un modèle.

Une page comporte un nœud de hiérarchie de type cq:Page et un nœud de contenu de type cq:PageContent. La propriété sling:resourceType du nœud de contenu pointe vers le composant de page utilisé pour le rendu de la page.

Par exemple, pour obtenir le nom de la page active, vous pouvez utiliser le code suivant dans votre script :

String pageName = currentPage.getName();

currentPage étant l’objet de la page active. Pour plus d’informations sur la manipulation des objets Page, reportez-vous aux Javadocs.

Gestionnaire de pages

Le gestionnaire de page est une interface qui fournit des méthodes pour les opérations au niveau de la page.

Par exemple, pour obtenir la page de contenu d’une ressource, vous pouvez utiliser le code suivant dans votre script :

Page myPage = pageManager.getContainingPage(myResource);

pageManager étant l’objet de gestionnaire de page et myResource un objet de ressource. Pour plus d’informations sur les méthodes fournies par le gestionnaire de page, reportez-vous aux Javadocs.

Structure dans le référentiel

La liste suivante donne un aperçu de la structure que vous verrez dans le référentiel.

Attention :

Les modifications apportées à cette structure, ou aux fichiers qu’elle contient, doivent l’être prudemment.

Des changements sont nécessaires lors du développement, mais il faut toutefois bien comprendre les conséquences de tout changement apporté.

Attention :

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.

  • /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/foundation/components.
  • content/
    Contenu créé pour votre site web.
  • /etc
    Section Outils pour des informations détaillées.
  • 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, par exemple la recherche ou la réplication.  Le contenu de /libs ne doit pas être modifié car il affecte le fonctionnement d’AEM. Les fonctionnalités spécifiques à votre site web doivent être développées sous /apps (voir Personnalisation de composants et d’autres éléments).
  • 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. Le sous-dossier /var/classes contient les servlets Java dans les formulaires source et compilés qui ont été générés à partir des scripts des composants.

Environnements

Avec AEM, un environnement de production se compose souvent de deux types d’instances différents : une instance de création et une instance de publication.

Le dispatcher

Le dispatcher est un outil Adobe qui sert à la mise en cache et/ou l’équilibrage de charge. Plus d’informations sont disponibles sous le dispatcher.

FileVault (système de révision de code source)

FileVault fournit à votre référentiel JCR des fonctions de mappage du système de fichiers et de gestion des versions. Il permet de gérer des projets de développement AEM avec une prise en charge complète du stockage et de la gestion du code de projet, du contenu, des configurations, etc. dans des systèmes de gestion de versions standard (par exemple, Subversion).

Consultez la documentation FileVault pour plus d’informations.

Workflows

Votre contenu est souvent soumis à des processus organisationnels, y compris des étapes telles que l’approbation et la validation par différents participants. Ces processus peuvent être représentés comme des workflows définis et développés dans AEM, puis appliqués aux pages de contenu appropriées ou actifs numériques, selon les besoins.

 

Le moteur de workflow sert à gérer l’implémentation de vos workflows et leur application ultérieure sur votre contenu.

Gestion multisite

Multi Site Manager (MSM) permet de gérer facilement plusieurs sites web partageant du contenu commun. MSM vous permet de définir des relations entre les sites afin que les modifications de contenu d’un site soient automatiquement répliquées sur d’autres sites.

Par exemple, les sites web sont souvent proposés dans plusieurs langues à l’intention d’un public international. Lorsque le nombre de sites dans la même langue est faible (trois à cinq), un processus manuel de synchronisation du contenu entre les sites est possible. Cependant, dès que le nombre de sites augmente ou si plusieurs langues sont concernées, il est plus efficace d’automatiser le processus.

  • Gérer efficacement différentes versions de langue d’un site web.
  • Mettre à jour automatiquement un ou plusieurs sites d’après un seul site source :
    • Appliquer une structure de base commune et utiliser du contenu commun sur plusieurs sites.
    • Maximiser l’utilisation des ressources disponibles.
    • Uniformiser l’aspect de plusieurs sites.
    • Concentrer les efforts sur la gestion de contenu qui diffère entre les sites.
Pour plus d’informations, voir Multi Site Manager.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne