Éditeur de page et éditeur universel page-editor-universal-editor
L’éditeur de page continue d’être pris en charge par Adobe, mais l’éditeur universel offre des possibilités intéressantes pour vos nouveaux projets.
Contexte background
Adobe a introduit l’éditeur universel en 2024 en tant qu’éditeur rationalisé adoptant une approche de développement moderne basée sur JavaScript. L’éditeur universel constitue la vision d’Adobe pour une expérience visuelle de création de contenu transparente et extensible.
Reconnaissant la richesse des fonctionnalités de l’éditeur de page et les innombrables projets qui y ont été investis au cours de la longue histoire d’AEM, Adobe continue à prendre entièrement en charge l’éditeur de page, bien que l’innovation se concentre sur l’éditeur universel.
Recommandation recommendation
Bien qu’il se réduise rapidement, il reste un écart de fonctionnalité entre l’éditeur universel et l’éditeur de page (une comparaison des fonctionnalités est disponible dans la section suivante).
En règle générale :
- Les nouveaux projets doivent utiliser l’éditeur universel par défaut.
- Les projets existants devez continuer à utiliser l’éditeur de page et tenir compte de l’éditeur universel lors des efforts dans Edge Delivery ou découplés.
L’éditeur choisi doit être entièrement adapté aux besoins de votre projet.
Comparaison des fonctionnalités feature-comparison
L’écart de fonctionnalités entre les deux éditeurs se réduisant constamment, veillez à consulter les notes de mise à jour de l’éditeur universel pour connaître les derniers développements.
Diffusion delivery
Persistance persistence
Fonctionnalités capabilities
Adoption de l’éditeur universel adopt-ue
L’éditeur universel offre de nombreux avantages, ce qui en fait une excellente solution pour les nouveaux projets.
- Modification visuelle : comme pour l’éditeur de page, les créateurs et créatrices peuvent modifier le contenu directement dans l’aperçu et voir instantanément comment leurs modifications affectent l’expérience du visiteur ou de la visiteuse.
- Préparation à l’avenir : la feuille de route d’AEM donne la priorité à l’éditeur universel en tant qu’éditeur visuel. Son adoption garantit l’accès aux dernières innovations et améliorations.
- Intégration plus simple : aucun SDK spécifique à AEM n’est nécessaire pour utiliser l’éditeur universel, ce qui réduit le verrouillage de tech stack.
- Utilisez votre propre application : l’éditeur universel prend en charge n’importe quelle structure ou architecture web, ce qui permet l’adoption sans nécessiter de refactorisation complexe.
- Extensibilité : l’éditeur universel bénéficie d’un cadre d’extension robuste qui comprend des intégrations à GenAI, Workfront, etc.
Migration vers l’éditeur universel migrate-ue
Il n’existe pas de chemin de migration direct de l’éditeur de page vers l’éditeur universel. Cela est dû à des différences fondamentales entre les deux technologies.
-
L’éditeur universel ne réintroduit pas de fonctionnalités telles que l’éditeur de modèles, le système de style ou la grille réactive.
- Ces cas d’utilisation peuvent désormais être gérés plus efficacement avec un CSS front-end et JavaScript allégés dans les projets Edge Delivery Services ou découplés.
-
Comme l’éditeur universel est un éditeur en tant que service, il ne peut pas permettre aux personnes en charge de l’implémentation d’injecter des éléments CSS ou JS dans les boîtes de dialogue des composants.
- Cela empêche la conversion automatique des boîtes de dialogue des composants à partir de l’éditeur de page.
- Cela affecte de nombreux domaines des boîtes de dialogue, tels que les widgets personnalisés, la validation des champs, l’affichage/le masquage des règles et les personnalisations basées sur des modèles.
- Bien que de telles fonctionnalités soient toujours possibles, l’éditeur universel les résout par le biais de la configuration, au lieu d’un JavaScript personnalisé déployé dans les boîtes de dialogue.
Bien que l’éditeur universel puisse techniquement activer la modification des pages pour les projets AEM traditionnels (par exemple, créés avec les composants principaux), ces sites reposent généralement sur plusieurs fonctionnalités spécifiques à l’éditeur de page, telles que le système de style, la grille réactive, les modèles modifiables et le code JavaScript personnalisé dans les boîtes de dialogue.
Dans la mesure où l’éditeur universel suit une approche plus rationalisée et moderne qui ne prend pas en charge ces fonctionnalités héritées, la migration de ces sites nécessiterait une refactorisation importante. Pour cette raison, la migration des sites de l’éditeur de page vers l’éditeur universel n’est recommandée que pour les projets qui passent à Edge Delivery Services.