Show Menu
SUJETS×

Développement d’applications monopages pour AEM

Les applications d’une seule page (SPA) peuvent améliorer considérablement l’expérience des utilisateurs de sites web. Le souhait des développeurs est de pouvoir créer des sites avec des structures SPA. Les auteurs, pour leur part, souhaitent modifier facilement du contenu dans AEM pour un site conçu à l’aide de telles structures.
Cet article présente des questions importantes à prendre en compte lorsque vous demandez à un développeur principal de développer une application d’une seule page pour AEM et présente une vue d’ensemble de l’architecture d’AEM en ce qui concerne le déploiement d’applications d’une seule page sur AEM.
La fonctionnalité Editeur d’application monopage (SPA) requiert AEM 6.4 Service Pack 2 ou version ultérieure.
L’éditeur d’applications monopages est la solution recommandée pour les projets qui nécessitent un rendu côté client basé sur la structure d’applications monopages (par exemple, Réagir ou Angular).

Archétype de projet AEM

Tout projet AEM doit tirer parti de l’archétype du projet AEM, qui prend en charge les projets d’application d’une seule page à l’aide de React ou d’Angular et exploite le SDK de l’application d’une seule page.

Principes de développement des applications monopages pour AEM

Le développement d’applications d’une seule page sur AEM suppose que le développeur principal respecte les meilleures pratiques standard lors de la création d’une application d’une seule page. Si en tant que développeur frontal vous suivez ces bonnes pratiques générales ainsi que quelques principes spécifiques à AEM, votre application d’une seule page sera fonctionnelle avec AEM et ses fonctionnalités de création de contenu.
  • Portabilité - ​Comme pour tout composant, les composants doivent être construits pour être aussi portables que possible. L’application d’une seule page doit être créée avec des composants portatifs et réutilisables, ce qui évite les chemins statiques faisant référence à la structure de contenu.
  • AEM pilote la structure ​du site : le développeur principal crée des composants et possède leur structure interne, mais compte sur AEM pour définir la structure de contenu du site.
  • Rendu ​dynamique : tous les rendus doivent être dynamiques.
  • Routage dynamique - ​L’application d’une seule page est responsable du routage et AEM l’écoute et récupère les données du composant en fonction de celui-ci. Tout routage devrait également être dynamique.
Si vous gardez ces principes à l’esprit lorsque vous développez votre application d’une seule page, elle sera aussi flexible et aussi future que possible, tout en activant toutes les fonctionnalités de création AEM prises en charge.
Si vous n’avez pas besoin de prendre en charge les fonctionnalités de création d’AEM, vous devrez peut-être envisager un autre modèle de conception d’ application d’une seule page.

Portabilité

Comme lors du développement de n'importe quel composant, vos composants doivent être conçus de manière à optimiser leur portabilité. Tout modèle qui va à l'encontre de la portabilité ou de la réutilisation des composants doit être évité pour assurer la compatibilité, la flexibilité et la maintenabilité à l'avenir.
Le développeur doit éviter d’utiliser des chemins statiques faisant référence à la structure de contenu, car les chemins peuvent être modifiés à tout moment par les auteurs de contenu. Cela limite également la réutilisation de la bibliothèque et empêche l’éditeur de modèles AEM d’être utilisé car sa structure se trouve à un autre emplacement que le contenu.
L'application d'une seule page doit être construite avec des composants hautement portables et réutilisables.

Structure du site des lecteurs AEM

Le développeur principal doit se considérer comme responsable de la création d’une bibliothèque de composants SPA utilisés pour créer l’application. Le développeur frontal a un contrôle total de la structure interne des composants. Cependant, AEM détient toujours la structure du site.
Cela signifie que le développeur principal peut ajouter du contenu client avant ou après le point d’entrée des composants et peut également effectuer des appels tiers à l’intérieur du composant. Cependant, le développeur frontal ne contrôle pas entièrement la manière dont les composants sont imbriqués, par exemple.

Rendu dynamique

L’application d’une seule page doit reposer sur le rendu dynamique du contenu. Il s’agit de l’attente par défaut à laquelle AEM récupère et rend tous les enfants de la structure de contenu.
Tout rendu explicite pointant vers un contenu spécifique est considéré comme un rendu statique et bien que pris en charge ne sera pas compatible avec les fonctionnalités de création de contenu d’AEM. Cela va aussi à l'encontre du principe de portabilité .

Routage dynamique

Comme pour le rendu, tous les routages doivent également être dynamiques. Dans AEM, l’application d’une seule page doit toujours posséder le routage et AEM l’écoute et récupère le contenu en fonction de celui-ci.
Tout routage statique va à l’encontre du principe de portabilité et limite l’auteur en n’étant pas compatible avec les fonctionnalités de création de contenu d’AEM. Par exemple, avec un routage statique, si l’auteur du contenu souhaite modifier un itinéraire ou une page, il doit demander au développeur principal de le faire.

Modèles de conception SPA

Si les principes de développement d’applications monopages dans AEM sont respectés, votre application d’une seule page sera fonctionnelle avec toutes les fonctionnalités de création de contenu AEM prises en charge.
Il peut toutefois y avoir des cas où cela n'est pas tout à fait nécessaire. Le tableau suivant présente un aperçu des différents modèles de conception, leurs avantages et leurs inconvénients.
Modèle de conception Avantages Inconvénients
AEM est utilisé comme CMS sans en-tête sans utiliser la structure du SDK de l’éditeur d’applications monopages. Le développeur frontal a un contrôle total sur l’application.
Les auteurs de contenu ne peuvent pas tirer parti de l’expérience de création de contenu d’AEM.
Le code n'est ni portable ni réutilisable s'il contient des références statiques ou un routage.
N’autorise pas l’utilisation de l’éditeur de modèles ; le développeur principal doit donc gérer les modèles modifiables via le JCR.
Le développeur principal utilise la structure du SDK de l’éditeur d’applications monopages, mais n’ouvre que certaines zones à l’auteur du contenu. Le développeur garde le contrôle de l’application en activant uniquement la création dans des zones restreintes de l’application.
Les auteurs de contenu sont limités à un ensemble limité d’expériences de création de contenu AEM.
Le code risque de ne pas être portable ni réutilisable s'il contient des références statiques ou un routage.
N’autorise pas l’utilisation de l’éditeur de modèles ; le développeur principal doit donc gérer les modèles modifiables via le JCR.
Le projet tire pleinement parti du SDK de l’éditeur d’applications monopages et les composants frontaux sont développés en tant que bibliothèque et la structure de contenu de l’application est déléguée à AEM.
L'application est réutilisable et portable.
L’auteur du contenu peut modifier l’application à l’aide de l’expérience de création de contenu d’AEM.
L’application d’une seule page est compatible avec l’éditeur de modèles.
Le développeur ne contrôle pas la structure de l’application et la partie du contenu déléguée à AEM.
Le développeur peut toujours réserver des zones de l’application pour le contenu qui ne doit pas être créé à l’aide d’AEM.
Bien que tous les modèles soient pris en charge dans AEM, ce n’est qu’en implémentant le troisième modèle (et en respectant ainsi les principes de développement d’ applications monopages recommandés dans AEM ) que les auteurs de contenu pourront interagir avec le contenu de l’application monopages et le modifier dans AEM tel qu’ils sont habitués.

Migration des applications monopages existantes vers AEM

En règle générale, si votre application d’une seule page respecte les principes de développement de l’ application d’une seule page pour AEM , elle fonctionne dans AEM et peut être modifiée à l’aide de l’éditeur d’applications d’une seule page.
Pour préparer votre application d’une seule page à travailler avec AEM, procédez comme suit.
  1. Rendez vos composants JS modulaires.
    Rendez-les capables d’être rendus dans n’importe quel ordre, position et taille.
  2. Utilisez les conteneurs fournis par notre SDK pour placer vos composants à l’écran.
    AEM fournit un composant système de pages et de paragraphes que vous pouvez utiliser.
  3. Créez un composant AEM pour chaque composant JS.
    Les composants AEM définissent la boîte de dialogue et la sortie JSON.

Instructions destinées aux développeurs de premier plan

La principale tâche de création d’une application d’une seule page pour AEM par un développeur frontal consiste à convenir des composants et de leurs modèles JSON.
Vous trouverez ci-dessous un aperçu des étapes qu’un développeur principal doit suivre lors du développement d’une application d’une seule page pour AEM.
  1. Accepter les composants et leur modèle JSON
    Les développeurs frontaux et les développeurs principaux d’AEM doivent s’entendre sur les composants nécessaires et sur un modèle afin qu’il y ait une correspondance individualisée entre les composants d’une application d’une seule page et les composants de l’arrière-plan.
    Les composants AEM sont toujours nécessaires principalement pour fournir des boîtes de dialogue de modification et pour exporter le modèle de composant.
  2. Dans les composants Réagir, accédez au modèle via this.props.cqModel
    Une fois les composants acceptés et le modèle JSON en place, le développeur frontal est libre de développer l'application d'une seule page et peut simplement accéder au modèle JSON via this.props.cqModel .
  3. Mise en oeuvre de la render() méthode du composant
    Le développeur frontal met en oeuvre la render() méthode à sa convenance et peut utiliser les champs de la cqModel propriété. Cette opération génère le DOM et les fragments HTML qui seront insérés dans la page. Il s’agit de la méthode standard de création d’une application dans React.
  4. Faites correspondre le composant au type de ressource AEM via MapTo()
    Le mappage stocke les classes de composants et est utilisé en interne par le Container composant fourni pour récupérer et instancier dynamiquement les composants en fonction du type de ressource donné.
    Il sert de "colle" entre l'avant et l'arrière-plan afin que l'éditeur sache quels composants correspondent les composants réactifs.
    Les Page et ResponsiveGrid sont de bons exemples de classes qui étendent la base Container .
  5. Définissez le composant comme EditConfig paramètre pour MapTo()
    Ce paramètre est nécessaire pour indiquer à l’éditeur comment le composant doit être nommé aussi longtemps qu’il n’est pas encore rendu ou n’a aucun contenu à rendre.
  6. Étendre la Container classe fournie pour les pages et les conteneurs
    Les systèmes de pages et de paragraphes doivent étendre cette classe afin que la délégation aux composants internes fonctionne comme prévu.
  7. Implémentez une solution de routage qui utilise l’ History API HTML5.
    Lorsque la fonction ModelRouter est activée, l’appel des pushState fonctions et replaceState déclenche une demande à la PageModelManager fonction pour récupérer un fragment manquant du modèle.
    La version actuelle du modèle ModelRouter ne prend en charge que l'utilisation d'URL pointant vers le chemin de ressource réel des points d'entrée du modèle Sling. Il ne prend pas en charge l’utilisation d’URL ou de alias mineurs.
    Il ModelRouter peut être désactivé ou configuré pour ignorer une liste d'expressions régulières.

AEM-Agnostic

Ces blocs de code illustrent comment vos composants React et Angular n’ont besoin d’aucun élément spécifique à Adobe ou AEM.
  • Tout ce qui se trouve dans le composant JavaScript est agnostique AEM.
  • Toutefois, ce qui est spécifique à AEM est que le composant JS doit être mappé à un composant AEM avec l’aide MapTo.
L' MapTo aide est la "colle" qui permet de faire correspondre les composants back-end et front-end :
  • Il indique au conteneur JS (ou système de paragraphes JS) quel composant JS est responsable du rendu de chacun des composants présents dans le fichier JSON.
  • Il ajoute un attribut de données HTML au code HTML généré par le composant JS, de sorte que l’éditeur d’applications monopages sache quelle boîte de dialogue afficher à l’auteur lors de la modification du composant.
Pour plus d’informations sur l’utilisation MapTo et la création d’applications monopages pour AEM en général, voir le guide de prise en main de votre structure choisie.

Architecture et applications monopages AEM

L’architecture générale d’AEM, y compris les environnements de développement, de création et de publication, ne change pas lors de l’utilisation d’applications monopages. Cependant, il est utile de comprendre comment le développement des applications SPA s'intègre dans cette architecture.
  • Créer un Environnement
    C’est ici que la source de l’application SPA et la source du composant sont extraites.
    • Le générateur NPM clientlib crée une bibliothèque cliente à partir du projet SPA.
    • Cette bibliothèque sera prise par Maven et déployée par le module externe Maven Build avec le composant dans AEM Author.
  • Auteur AEM
    Le contenu est créé sur l’auteur AEM, y compris la création d’applications monopages.
    Lorsqu’une application d’une seule page est modifiée à l’aide de l’éditeur d’applications d’une seule page sur l’environnement de création :
    1. L’application d’une seule page demande le code HTML externe.
    2. Le fichier CSS est chargé.
    3. Le script JavaScript de l’application SPA est chargé.
    4. Lorsque l’application d’une seule page est exécutée, le fichier JSON est demandé, ce qui permet à l’application de créer le DOM de la page, y compris les cq-data attributs.
    5. Ces cq-data attributs permettent à l’éditeur de charger des informations de page supplémentaires afin de connaître les configurations de modification disponibles pour les composants.
  • Publication AEM
    C’est ici que le contenu créé et les bibliothèques compilées, y compris les artefacts d’application SPA, les clientlibs et les composants, sont publiés pour la consommation publique.
  • Répartiteur / CDN
    Le répartiteur sert de couche de mise en cache d’AEM pour les visiteurs sur le site.
    • Les requêtes sont traitées de la même manière que sur l’auteur AEM. Toutefois, aucune requête d’informations de page n’est envoyée, car cette requête n’est requise que par l’éditeur.
    • Javascript, CSS, JSON et HTML sont mis en cache, ce qui optimise la page pour une diffusion rapide.
Dans AEM, il n’est pas nécessaire d’exécuter les mécanismes de création Javascript ni d’exécuter Javascript lui-même. AEM héberge uniquement les artefacts compilés de l’application SPA.

Étapes suivantes

Pour une vue d’ensemble de la structure d’une seule application monopage dans AEM et de son fonctionnement, reportez-vous au guide de prise en main pour réagir et Angular .
Pour obtenir un guide détaillé sur la création de votre propre application d’une seule page, consultez le didacticiel getting-started-spa-wknd-tutorial-develop.htmlPrise en main de l’éditeur d’applications d’une seule page - Événements WKND.
Pour plus d’informations sur le mappage entre le modèle dynamique et les composants et son fonctionnement dans les applications monopages dans AEM, voir l’article Mappage entre le modèle dynamique et les composants pour les applications monopages .
Si vous souhaitez mettre en oeuvre des applications monopages dans AEM pour une structure autre que React ou Angular ou si vous souhaitez simplement plonger dans le fonctionnement du SDK SPA pour AEM, reportez-vous à l’article SPA Blueprint .