Headful ou Headless AEM ? Pourquoi pas les deux avec Hybrid ? / Blogs / Perdu

Il n’est pas rare, face à un nouveau problème, de se rabattre sur une solution éprouvée. Ensuite, rappelez-vous soudainement pourquoi l’équipe a abandonné cette solution en premier lieu. Récemment, j’ai constaté cette tendance avec des équipes d’ingénierie et un désir de contenu multicanal.

Un cas courant de contenu sans tête sur AEM

Préparons le terrain avec un exemple. Une équipe de marketing numérique a obtenu une licence Adobe Experience Manger 6.5 dans l’espoir d’utiliser l’édition de contenu WYSIWYG pour produire et publier rapidement du contenu découplé des déploiements de code. Ils voient également qu’AEM a la capacité de produire du contenu multicanal réutilisable via des fragments de contenu. Les spécialistes du marketing prévoient d’utiliser ces fragments dans un site Web marketing, une application mobile associée et des appareils d’assistance vocale. Enfin, ce serait formidable si le site offrait l’option de pages hautement interactives qui ne nécessitaient pas de rafraîchissement. Ils demandent à l’équipe d’ingénierie de mettre en œuvre la solution.

L’équipe d’ingénierie est pleine de développeurs backend talentueux qui ont des années d’expérience dans la fourniture de contenu Web. Les ingénieurs creusent dans la plate-forme, et même si certains sont capables d’apprendre le développement de composants AEM, cela prend du temps. Ils ont bientôt quelques soucis :

• Ils souhaitent utiliser un framework frontal pour fournir les parties hautement interactives du site Web. L’élargissement de l’équipe est difficile car seuls quelques développeurs sur le marché ont à la fois une expérience des composants AEM et du framework frontal.
• Il existe déjà une déconnexion entre la création de fragments de contenu et l’attente de création de contenu sur place sur la page.
• Il existe une myriade d’options pour la mise en œuvre d’applications à page unique (SPA) dans AEM. Lequel correspond le mieux au cas d’utilisation ?
• La lenteur des progrès pour obtenir ne serait-ce qu’une seule page de démonstration ensemble. Si c’était juste dans [insert technology] au lieu de plusieurs modèles HTL, modèles Sling et boîtes de dialogue de composants, ce serait plus rapide.

Frustrée, l’équipe d’ingénierie lance une preuve de concept avec sa pile précédente. Ils retournent voir l’équipe marketing et montrent à quelle vitesse ils ont créé une nouvelle page et de nouveaux composants. L’ingénierie pousse pour un compromis de contenu sans tête sur AEM et un site SPA séparé avec la pile qu’ils connaissent. À mon avis, cela va largement à l’encontre de l’objectif de la licence AEM. Avec cette approche, la possibilité d’utiliser l’édition WYSIWYG et les versions de code/contenu découplées a disparu.

Pourquoi devriez-vous envisager des exportateurs de fragments et de modèles Sling

Au lieu de cela, envisagez d’utiliser des fragments de contenu, des fragments d’expérience et des exportateurs de modèles Sling combinés avec des SPA pour bénéficier des deux approches.

Fragments de contenu sont des contenus de texte et d’image structurés et sans code que vous pouvez créer et exposer à n’importe quel canal via JSON ou GraphQL.

Fragments d’expérience sont également sans code, mais présentent des expériences avec une mise en page partielle ou complète en HTML. En option, ils incluent la conception et les fonctionnalités via CSS et JavaScript. Les fragments d’expérience peuvent utiliser n’importe quel composant AEM et sont destinés à des expériences réutilisables « prêtes/presque prêtes ». Avec un développement personnalisé léger, vous pouvez même tirer parti des fragments de contenu dans les composants AEM et donc de tout fragment d’expérience.

Exportateurs de modèles d’élingues peut sérialiser la plupart des créations de composants AEM dans JSON pour les exposer à n’importe quel canal. Il s’agit de l’option préférée pour conserver l’édition en contexte, car la plupart des autres solutions nécessitent de naviguer vers une autre page pour modifier l’expérience. Tous Composants de base d’Adobe avoir ceci activé par défaut. Cela nécessite une petite quantité de développement pour configurer les composants personnalisés, mais est assez puissant et rapide pour les implémentations AEM existantes afin de permettre la diffusion de contenu multicanal.

L’utilisation de ces solutions ensemble plutôt que sans tête présente plusieurs avantages. Avoir l’un de ces fragments avec au moins une des expériences dans l’environnement d’auteur AEM signifie que vous pouvez prévisualiser de manière native les modifications dans un canal avant qu’elles ne soient mises en ligne. Vous pouvez également créer une grande partie de la structure de base du site avec les composants principaux et la création basée sur des fragments sans aucun développement. Ensuite, une fois que votre équipe est plus à l’aise avec le développement AEM, utilisez Sling Model Exporter pour la diffusion multicanal d’expériences personnalisées. Plus important encore, vous conservez l’édition WYSIWYG et les versions de code/contenu découplées.

Mais qu’en est-il du SPA pour AEM ?

Vous remarquerez peut-être qu’il y a un élément clé qui reste sans réponse ici – quelle est la meilleure façon de le faire en combinaison avec SPA ? Heureusement, il existe plusieurs options, que je couvrirai la semaine prochaine dans la partie 2. À bientôt !

Pour plus d’informations sur la façon dont Perficient peut mettre en œuvre vos expériences numériques de rêve, nous aimerions avoir de vos nouvelles. Contactez Perficient pour commencer votre voyage.