Concepts de base d’AEM aem-core-concepts

Conditions préalables pour le développement sur AEM prerequisites-for-developing-on-aem

Vous aurez besoin des compétences suivantes pour développer en plus de l’AEM :

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

Référentiel de contenu Java java-content-repository

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 dirigées par Adobe Research (Suisse) SA.

Le package 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-crx-and-jackrabbit

Experience Server fournit les services d’expérience sur lesquels AEM est basé et qui peuvent être utilisés pour créer des applications personnalisées. Il incorpore également le référentiel de contenu basé sur Jackrabbit.

Apache Jackrabbit est une mise en oeuvre open source, entièrement conforme, de l’API JCR 2.0.

Traitement des requêtes Sling sling-request-processing

Introduction à Sling introduction-to-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. Cela offre 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. En particulier, lors de la mise en oeuvre d’un système de gestion de contenu web tel que WCM dans 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 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 sling-is-content-centric

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 nœud de référentiel) :

Sling RESTful restful-sling

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 :

Décomposition d’URL url-decomposition

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 le diviser en plusieurs parties composites :

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, il s’agit de 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) Tout paramètre requis pour le contenu dynamique.

De l’URL au contenu et aux scripts from-url-to-content-and-scripts

En suivant ces principes :

La figure ci-dessous illustre le mécanisme utilisé, qui sera abordé 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.

Mappage des requêtes aux ressources mapping-requests-to-resources

La requête est décomposée et les informations nécessaires sont extraites. Le référentiel est recherché pour la ressource demandée (noeud de contenu) :

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 locating-the-script

Lorsque la ressource appropriée (nœud de contenu) est localisée, le type de ressource sling est extrait. Il s’agit d’un chemin d’accès qui localise le script à utiliser pour le rendu du contenu.

Le chemin spécifié par le sling:resourceType peut être :

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

Un certain nombre d’autres points sont à noter :

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

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 elle est; en d’autres termes, plus le sélecteur correspond mieux, 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 :

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

La hiérarchie de type de :

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.

Les scripts Sling ne peuvent pas être appelés directement sling-scripts-cannot-be-called-directly

Dans Sling, les scripts ne peuvent pas être appelés directement, car cela violerait 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 :

API Sling sling-api

Il utilise le package d’API Sling org.apache.sling.* et les bibliothèques de balises.

Référencement d’éléments existants avec sling:include referencing-existing-elements-using-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

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 individuels 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.

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. Il s’agit de deux groupes OSGi s’exécutant dans une structure OSGi.

Vous pouvez ainsi effectuer les actions suivantes sur l’un des packages de votre installation :

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

Objets de développement dans l’environnement AEM development-objects-in-the-aem-environment

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

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

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

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

Les noeuds 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 noeud pointe vers le composant de rendu Sling à utiliser.

Un noeud, qui est un nom JCR, est également appelé une ressource dans l’environnement Sling.

Par exemple, pour obtenir les propriétés du noeud 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. Ils sont souvent utilisés pour contrôler la modification d’un élément de contenu.

Les boîtes de dialogue sont créées en combinant des widgets.

AEM a été développé à l’aide 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. Ils combinent une série de widgets pour présenter à l’utilisateur tous les champs et actions nécessaires pour modifier le contenu associé.

Les boîtes de dialogue sont également utilisées pour modifier les métadonnées et 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’a pas à effectuer le rendu du contenu ni à être lié à une ressource spécifique ; par exemple, un composant de navigation affiche des informations sur plusieurs ressources.

La définition d’un composant comprend :

Modèle Un modèle 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 alors créée en copiant ce modèle.

Un modèle est une hiérarchie de noeuds ayant 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 manière dont il est rendu, AEM étant centré sur le contenu.

Composant de page (composant de niveau supérieur) Composant à utiliser pour effectuer le rendu de 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 noeud de contenu pointe vers le composant 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 conteneur d’une ressource, vous pouvez utiliser le code suivant dans votre script :

Page myPage = pageManager.getContainerPage(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 structure-within-the-repository

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

Environnements environments

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

Le dispatcher the-dispatcher

Le dispatcher est un outil Adobe qui sert à la mise en cache et/ou l’équilibrage de charge. Vous trouverez plus d’informations sous Dispatcher.

FileVault (système de révision source) filevault-source-revision-system

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

Voir Outil FileVault documentation pour plus d’informations.

Workflows 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 sous forme de workflows, définis et développés dans AEM, puis appliqué à la variable pages de contenu appropriées ou ressources numériques selon les besoins.

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

Gestion multisite multi-site-management

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, de sorte 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 que plusieurs langues sont impliquées, il devient plus efficace d’automatiser le processus.

Pour plus d’informations, voir Multi Site Manager.