Show Menu
SUJETS×

Routage de modèle SPA

Pour les applications d’une seule page dans AEM, l’application est responsable du routage. Ce document décrit le mécanisme de routage, le contrat et les options disponibles.
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).

Routage du projet

L’application est propriétaire du routage et est ensuite implémentée par les développeurs frontaux du projet. Ce document décrit le routage spécifique au modèle renvoyé par le serveur AEM. La structure des données du modèle de page expose l'URL de la ressource sous-jacente. Le projet frontal peut utiliser toute bibliothèque personnalisée ou tierce fournissant des fonctionnalités de routage. Une fois qu'un itinéraire attend un fragment de modèle, un appel à la PageModelManager.getData() fonction peut être effectué. Lorsqu’un itinéraire de modèle a été modifié, un événement doit être déclenché pour avertir les bibliothèques d’écoute telles que l’éditeur de page.

Architecture

Pour une description détaillée, reportez-vous à la section PageModelManager du document de plan d'application d'une seule page.

ModelRouter

Lorsque cette option est activée, ModelRouter - encapsule les fonctions de l’API d’historique HTML5 pushState et replaceState garantit qu’un fragment donné du modèle est prérécupéré et accessible. Il informe ensuite le composant frontal enregistré que le modèle a été modifié.

Routage de modèle manuel ou automatique

Le ModelRouter système automatise la récupération des fragments du modèle. Mais comme tout outil automatisé vient avec des limites. Si nécessaire, ModelRouter vous pouvez désactiver ou configurer le paramètre pour ignorer les chemins d’accès à l’aide des propriétés de métadonnées (voir la section Meta Properties du document de composants de page SPA). Les développeurs frontaux peuvent alors mettre en oeuvre leur propre couche de routage de modèle en demandant PageModelManager à la fonction de charger tout fragment de modèle donné à l'aide de la getData() fonction.
Actuellement, le projet d'exemple de Journal We.Retail React illustre l'approche automatisée tandis que le projet Angular illustre l'approche manuelle. Une approche semi-automatisée serait également un cas d'utilisation valable.
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 d'alias Vanity.

Contrat de routage

L’implémentation actuelle repose sur l’hypothèse que le projet d’application d’une seule page utilise l’API d’historique HTML5 pour le routage des différentes pages de l’application.

Configuration

Le ModelRouter prend en charge le concept de routage de modèle lorsqu’il écoute pushState et replaceState appelle à prérécupérer les fragments de modèle. En interne, il déclenche le chargement PageModelManager du modèle correspondant à une URL donnée et déclenche un cq-pagemodel-route-changed événement que d’autres modules peuvent écouter.
Par défaut, ce comportement est automatiquement activé. Pour le désactiver, l’application sur une seule page doit effectuer le rendu de la propriété meta suivante :
<meta property="cq:pagemodel_router" content="disable"\>

Note that every route of the SPA should correspond to an accessible resource in AEM (e.g., " /content/mysite/mypage" ) since the PageModelManager will automatically try to load the corresponding page model once the route is selected. Though, if needed, the SPA can also define a "block list" of routes that should be ignored by the PageModelManager :
<meta property="cq:pagemodel_route_filters" content="route/not/found,^(.*)(?:exclude/path)(.*)"/>