Show Menu
SUJETS×

Présentation et présentation des applications monopages

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.
L’éditeur de SPA constitue une solution complète pour la prise en charge des SPA dans AEM. Cet article décrit l’utilisation d’une application d’application d’une seule page pour la création et montre comment elle se rapporte à l’AEM SPA Editor sous-jacent.
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).

Présentation

Objectif de l'article

Cet article présente les concepts de base des applications monopages avant de guider le lecteur dans une présentation pas à pas de l’éditeur d’applications monopages en utilisant une application d’application monopages simple pour démontrer l’édition de base du contenu. Il détaille ensuite la construction de la page et comment l'application SPA se rattache à l'éditeur SPA AEM et interagit avec lui.
L’objectif de cette introduction et de cette présentation est de montrer à un développeur AEM pourquoi les applications monopages sont pertinentes, comment elles fonctionnent généralement, comment l’éditeur d’applications monopages AEM gère les applications monopages et comment elles diffèrent d’une application d’application d’un site Web standard.
La procédure pas à pas est basée sur la fonctionnalité AEM standard et l'exemple d'application de Journal We.Retail. Les exigences suivantes doivent être respectées :
Ce document utilise l’application de Journal We.Retail à des fins de démonstration uniquement. Il ne doit être utilisé pour aucun travail de projet.
Tout projet AEM doit tirer parti de l’archétype de projet AEM, qui prend en charge les projets d’application d’une seule page à l’aide de React ou d’Angular et qui utilise le SDK d’application d’une seule page.

Qu'est-ce qu'un APM ?

Une application d’une seule page diffère d’une page conventionnelle en ce qu’elle est rendue côté client et qu’elle est principalement pilotée par JavaScript, en utilisant les appels Ajax pour charger des données et mettre à jour dynamiquement la page. La plupart ou la totalité du contenu est récupérée une fois au chargement d’une seule page avec des ressources supplémentaires chargées de manière asynchrone, selon les besoins, en fonction de l’interaction de l’utilisateur avec la page.
Cela réduit la nécessité d’actualiser les pages et offre à l’utilisateur une expérience transparente, rapide et qui ressemble davantage à une expérience d’application native.
L’éditeur d’applications d’une seule page permet aux développeurs de créer des applications d’une seule page qui peuvent être intégrées à un site AEM, ce qui permet aux auteurs de contenu de modifier le contenu de l’application d’une seule page aussi facilement que tout autre contenu de l’AEM.

Pourquoi une ZPS ?

En étant plus rapide, fluide et plus semblable à une application native, une application d’une seule page devient une expérience très attrayante non seulement pour le visiteur de la page Web, mais également pour les marketeurs et les développeurs en raison de la nature du fonctionnement des applications d’une seule page.
Visiteurs
  • Les visiteurs souhaitent des expériences de type natif lorsqu’ils interagissent avec du contenu.
  • Il existe des données claires indiquant que plus une page est rapide, plus une conversion est probable.
Marqueurs
  • Les marketeurs veulent offre des expériences riches et originales pour inciter les visiteurs à s'engager pleinement dans le contenu.
  • La personnalisation peut rendre ces expériences encore plus attrayantes.
Développeurs
  • Les développeurs veulent une séparation nette des préoccupations entre le contenu et la présentation.
  • Une séparation nette rend le système plus extensible et permet un développement frontal indépendant.

Comment fonctionne une application d’une seule page ?

L’idée Principale derrière une application d’une seule page est que les appels et la dépendance sur un serveur sont réduits afin de minimiser les retards causés par les appels au serveur, de sorte que l’application d’une seule page puisse approcher la réactivité d’une application native.
Dans une page Web séquentielle traditionnelle, seules les données nécessaires à la page immédiate sont chargées. Cela signifie que lorsque le visiteur passe à une autre page, le serveur est appelé pour les ressources supplémentaires. Des appels supplémentaires peuvent s’avérer nécessaires lorsque le visiteur interagit avec les éléments de la page. Ces appels multiples peuvent donner une impression de retard ou de retard car la page doit rattraper les demandes du visiteur.
Pour une expérience plus fluide, qui approche ce qu’un visiteur attend des applications mobiles natives, une application d’une seule page charge toutes les données nécessaires pour le visiteur au premier chargement. Bien que cette opération puisse prendre un peu plus de temps au début, elle élimine ensuite la nécessité d’appels de serveur supplémentaires.
En effectuant le rendu côté client, l’élément de page réagit plus rapidement et les interactions avec la page par le visiteur sont immédiates. Toute donnée supplémentaire qui peut être nécessaire est appelée de manière asynchrone afin d’optimiser la vitesse de la page.
Pour obtenir des détails techniques sur le fonctionnement des applications monopages en AEM, consultez l’article Prise en main des applications monopages en AEM .
Pour un aperçu plus approfondi de la conception, de l’architecture et du processus technique de l’éditeur d’applications monopages, consultez l’article Présentation de l’éditeur d’ applications monopages.

Modification du contenu avec l’application d’une seule page

Lorsqu’une application d’une seule page est créée pour tirer parti de l’éditeur d’une seule page, l’auteur du contenu ne remarque aucune différence lors de la modification et de la création de contenu. Une fonctionnalité AEM commune est disponible et aucune modification du flux de travail de l’auteur n’est requise.
La procédure pas à pas est basée sur la fonctionnalité AEM standard et l'exemple d'application de Journal We.Retail. Les exigences suivantes doivent être respectées :
  1. Modifiez l'application de Journal We.Retail dans AEM.
    https://localhost:4502/editor.html/content/we-retail-journal/react.html
  2. Sélectionnez un composant d’en-tête et notez qu’une barre d’outils s’affiche comme pour tout autre composant. Sélectionnez Modifier .
  3. Modifiez le contenu normalement dans AEM et notez que les modifications sont conservées.
    Pour plus d’informations sur l’éditeur de texte et les SPA en place, consultez la section Présentation de l’éditeur d’applications monopages (SPA).
  4. Utilisez l’explorateur de ressources pour faire glisser une nouvelle image dans un composant d’image.
  5. Le changement est maintenu.
D’autres outils de création, tels que le glisser-déposer de composants supplémentaires sur la page, la réorganisation des composants et la modification de la mise en page, sont pris en charge, comme dans toute application autre que SPA.
L’éditeur d’applications monopages ne modifie pas le DOM de l’application. L'APS lui-même est responsable du DOM.
Pour voir comment cela fonctionne, passez à la section suivante de cet article Applications SPA et à l’éditeur d’applications SPA AEM.

Applications d’application d’une seule page et éditeur d’applications d’une seule page AEM

L’expérience de comportement d’une application d’une seule page d’une seule page d’une seule page permet de mieux comprendre comment une application SAP fonctionne avec l’éditeur d’une seule page d’AEM.

Utilisation d’une application SPA

  1. Chargez l’application de Journal We.Retail sur le serveur de publication ou à l’aide de l’option Vue as Published (Publié ) dans le menu Informations sur lapage de l’éditeur de page.
    /content/we-retail-journal/react.html
    Notez la structure des pages, y compris la navigation vers les pages enfants, le widget météorologique et les articles.
  2. Accédez à une page enfant à l’aide du menu et voyez que la page se charge immédiatement sans qu’il faille procéder à une actualisation.
  3. Ouvrez les outils de développement intégrés à votre navigateur et surveillez l’activité du réseau lorsque vous parcourez les pages enfants.
    Il y a très peu de trafic lorsque vous passez d’une page à l’autre dans l’application. La page n’est pas rechargée et seules les nouvelles images sont demandées.
    L’application d’une seule page gère le contenu et le routage entièrement du côté client.
Ainsi, si la page n’est pas rechargée lors de la navigation dans les pages enfants, comment est-elle chargée ?
La section suivante, Chargement d’une application d’application d’une seule page, approfondit les mécanismes de chargement de l’application d’une seule page et explique comment le contenu peut être chargé de façon synchrone et asynchrone.

Chargement d’une application d’application d’une seule page

  1. Si ce n’est pas déjà fait, chargez l’application de Journal We.Retail sur le serveur de publication ou à l’aide de la Vue d’options Publié dans le menu Informations sur la page de l’éditeur de page.
    /content/we-retail-journal/react.html
  2. Utilisez l’outil intégré de votre navigateur pour vue la source de la page.
  3. Notez que le contenu de la source est extrêmement limité.
    <!DOCTYPE HTML>
    <html lang="en-CH">
        <head>
        <meta charset="UTF-8">
        <title>We.Retail Journal</title>
    
        <meta name="template" content="we-retail-react-template"/>
    
    <link rel="stylesheet" href="/etc.clientlibs/we-retail-journal/react/clientlibs/we-retail-journal-react.css" type="text/css">
    
    <link rel="stylesheet" href="/libs/wcm/foundation/components/page/responsive.css" type="text/css">
    
    </head>
        <body class="page basicpage">
    
    <div id="page"></div>
    
    <script type="text/javascript" src="/etc.clientlibs/we-retail-journal/react/clientlibs/we-retail-journal-react.js"></script>
    
        </body>
    </html>
    
    
    La page ne comporte aucun contenu dans son corps. Il est principalement composé de feuilles de style et d'un appel à un script React we-retail-journal-react.js .
    Ce script React est le Principal pilote de cette application et est responsable du rendu de tout le contenu.
  4. Utilisez les outils intégrés de votre navigateur pour inspecter la page. Affichez le contenu du modèle DOM entièrement chargé.
  5. Accédez à l'onglet Réseau de l'Inspecteur et rechargez la page.
    Ignorant les demandes d’image, notez que les Principales ressources chargées pour la page sont la page elle-même, CSS, le code JavaScript de réaction, ses dépendances, ainsi que les données JSON de la page.
  6. Chargez le react.model.json dans un nouvel onglet.
    /content/we-retail-journal/react.model.json
    L’éditeur d’applications monopages AEM utilise AEM Content Services pour diffuser l’intégralité du contenu de la page sous forme de modèle JSON.
    En implémentant des interfaces spécifiques, les modèles Sling fournissent les informations nécessaires à l’application d’une seule page. La diffusion des données JSON est déléguée vers le bas à chaque composant (de la page, au paragraphe, au composant, etc.).
    Chaque composant choisit ce qu’il expose et comment il est rendu (côté serveur avec HTL ou côté client avec React). Bien sûr, cet article se concentre sur le rendu côté client avec React.
  7. Le modèle peut également regrouper les pages afin qu’elles soient chargées de manière synchrone, ce qui réduit le nombre de rechargements de page nécessaires.
    Dans l'exemple du Journal We.Retail, les pages home , blog et aboutus les pages sont chargées de manière synchrone, car les visiteurs visitent généralement toutes ces pages. Cependant, la weather page est chargée de manière asynchrone, car les visiteurs sont moins susceptibles de la consulter.
    Ce comportement n’est pas obligatoire et est entièrement définissable.
  8. Pour vue cette différence de comportement, rechargez la page et effacez l'activité réseau de l'inspecteur. Accédez au blog et aux pages qui nous concernent dans le menu de la page et vérifiez qu'aucune activité réseau n'est signalée.
    Accédez à la page Météo et vérifiez que l’ weather.model.json appel est asynchrone.

Interaction avec l’éditeur d’applications monopages

En utilisant l'exemple d'application de Journal We.Retail, vous savez comment se comporte l'application et comment elle est chargée lorsqu'elle est publiée, en exploitant les services de contenu pour la diffusion de contenu JSON ainsi que le chargement asynchrone des ressources.
De plus, pour l’auteur de contenu, la création de contenu à l’aide d’un éditeur d’application d’une seule page est transparente dans AEM.
Dans la section suivante, nous étudierons le contrat qui permet à l'éditeur d'application d'une seule page d'établir des relations entre les composants de l'application d'une seule page d'une page d'une page d'une page d'une page d'une page d'une page d'une page d'une page d'une page d'une page d'une page d'une page d'une page d'une autre.
  1. Chargez l'application de Journal We.Retail dans l'éditeur et passez en mode Prévisualisation .
    https://localhost:4502/editor.html/content/we-retail-journal/react.html
  2. A l’aide des outils de développement intégrés à votre navigateur, inspectez le contenu de la page. A l’aide de l’outil de sélection, sélectionnez un composant modifiable sur la page et vue le détail de l’élément.
    Notez que le composant possède un nouvel attribut de données data-cq-data-path .
    Par exemple,
    data-cq-data-path="root/responsivegrid/paragraph_1
    Ces chemins permettent de récupérer et d’associer l’objet de configuration de contexte de modification de chaque composant.
    Il s’agit du seul attribut de balisage requis par l’éditeur pour reconnaître qu’il s’agit d’un composant modifiable dans l’application d’une seule page. En fonction de cet attribut, l’éditeur d’applications monopages détermine la configuration modifiable associée au composant, de sorte que le cadre, la barre d’outils, etc. appropriés soient définis. est chargé.
    Certains noms de classe spécifiques sont également ajoutés pour marquer les espaces réservés et pour la fonctionnalité de glisser-déposer des ressources.
    Il s’agit d’un changement de comportement des pages générées côté serveur dans AEM, où un cq élément est inséré pour chaque composant modifiable.
    Cette approche dans l’application d’une seule page permet d’éliminer la nécessité d’injecter des éléments personnalisés, en n’utilisant qu’un attribut de données supplémentaire, ce qui simplifie le balisage pour le développeur frontal.

Étapes suivantes

Maintenant que vous comprenez l’expérience de modification de l’application d’une seule page en AEM et comment une application d’une seule page se rapporte à l’éditeur d’une seule page, plongez-vous dans la compréhension de la création d’une application d’une seule page.