Architecture de l’éditeur universel

Découvrez l’architecture de l’éditeur universel et le flux de données entre ses services et couches.

Blocs de création d’architecture

L’éditeur universel est constitué de quatre blocs de création essentiels qui interagissent pour permettre aux auteurs de contenu de modifier n’importe quel aspect de contenu dans n’importe quelle mise en oeuvre afin que vous puissiez offrir des expériences exceptionnelles, augmenter la vitesse du contenu et offrir une expérience de développement à la pointe de la technologie.

  1. Éditeurs
  2. Application distante
  3. Couche API
  4. Couche de persistance

Ce document décrit tous les blocs de création et la manière dont ils échangent des données.

Architecture de l’éditeur universel

CONSEIL

Pour voir Universal Editor et son architecture en action, consultez le document . Prise en main d’Universal Editor dans AEM pour savoir comment accéder à l’éditeur universel et comment commencer à instrumenter votre première application AEM pour l’utiliser.

Éditeurs

  • Éditeur universel – L’éditeur universel utilise un DOM instrumenté pour permettre la modification statique du contenu. Voir Attributs et types pour plus d’informations sur les métadonnées nécessaires. Consultez le document Prise en main de l’éditeur universel dans AEM pour découvrir un exemple de l’instrumentation dans AEM.
  • Rail Propriétés – Certaines propriétés des composants ne peuvent pas être modifiées en contexte ; par exemple, l’heure de rotation d’un carrousel ou quel onglet accordéon doit toujours être ouvert ou fermé. Pour activer la modification de ces informations de composant, utilisez l’éditeur basé sur les formulaires qui apparaît dans le rail latéral de l’éditeur.

Application distante

Pour rendre une application modifiable en contexte dans l’éditeur universel, le DOM doit être instrumenté. L’application distante doit effectuer le rendu de certains attributs dans le DOM. Voir Attributs et types pour plus d’informations sur les métadonnées nécessaires. Consultez le document Prise en main de l’éditeur universel dans AEM pour découvrir un exemple de l’instrumentation dans AEM.

L’éditeur universel s’efforce d’obtenir un SDK minimal. Par conséquent, l’instrumentation relève de la mise en œuvre de l’application distante.

Couche API

  • Données de contenu – Pour l’éditeur universel, les systèmes source des données de contenu et la manière dont elles sont utilisées n’ont pas d’importance. Il est uniquement important de définir et de fournir les attributs requis à l’aide de données modifiables en contexte.
  • Données persistantes – Il existe un identifiant d’URL pour chaque donnée modifiable. Cette URL est utilisée pour acheminer la persistance vers le système et la ressource appropriés.

Couche de persistance

  • Modèle de fragment de contenu – Pour prendre en charge le rail de modification des propriétés de fragment de contenu, l’éditeur de fragment de contenu et les éditeurs basés sur des formulaires, des modèles par composant et fragment de contenu sont requis.
  • Contenu – Le contenu peut être stocké n’importe où, par exemple dans AEM, Magento, etc.

Couche de persistance

Le service Éditeur universel et Backend System Dispatch

L’éditeur universel distribue toutes les modifications de contenu à un service centralisé appelé Service Éditeur universel. Ce service, exécuté sur Adobe I/O Runtime, charge les plug-ins disponibles dans le registre des extensions en fonction de l’URL fournie. Le plug-in est chargé de communiquer avec le backend et de renvoyer une réponse unifiée.

Service Éditeur universel

Rendu des pipelines

Rendu côté serveur

Rendu côté serveur

Génération statique du site

Génération statique du site

Rendu côté client

Rendu côté client

Ressources supplémentaires

Pour en savoir plus sur l’éditeur universel, consultez ces documents.

Sur cette page