Fragments d’expérience experience-fragments

Principes élémentaires the-basics

Un fragment d’expérience est un groupe d’un ou plusieurs composants comprenant un contenu et une disposition pouvant être référencés dans les pages.

Un fragment d’expérience principal ou de variante, ou les deux, utilise les éléments suivants :

Comme il n’y a pas de /libs/cq/experience-fragments/components/xfpage/xfpage.html, il revient à ce qui suit :

Rendu HTML brut the-plain-html-rendition

Le sélecteur .plain. de l’URL permet d’accéder au rendu HTML brut.

Cette fonctionnalité est disponible à partir du navigateur. Toutefois, son principal objectif consiste à autoriser d’autres applications (des applications web tierces et des implémentations mobiles personnalisées, par exemple) à accéder directement au contenu du fragment d’expérience à l’aide de l’URL uniquement.

Le rendu HTML brut ajoute le protocole, l’hôte et le chemin de contexte aux chemins suivants :

Par exemple :

.../brooklyn-coat/master.plain.html

Le sélecteur de rendu brut utilise un transformateur plutôt que des scripts supplémentaires ; le Sling Rewriter est utilisé comme transformateur et configuré comme suit :

Configuration de la génération du rendu HTML configuring-html-rendition-generation

Le rendu HTML est généré à l’aide des pipelines Sling Rewriter. Le pipeline est défini au niveau du chemin /libs/experience-fragments/config/rewriter/experiencefragments. Le transformateur HTML prend en charge les options suivantes :

Il est recommandé de configurer le module de réécriture à l’aide d’un recouvrement. Voir Recouvrements

Variantes sociales social-variations

Les variations sociales peuvent être publiées sur les réseaux sociaux (texte et image). Dans Adobe Experience Manager (AEM), ces variations sociales peuvent contenir des composants ; des composants texte ou image, par exemple.

Vous pouvez récupérer l’image et le texte de la publication sur les réseaux sociaux à partir de n’importe quel type de ressource image ou texte, à n’importe quelle profondeur. Les ressources peuvent provenir du bloc de création ou du conteneur de mises en page.

Les variations sociales permettent également la création de blocs de création et leur prise en compte lors des actions sociales (dans l’environnement de publication).

Pour publier le contenu texte et image approprié sur le réseau social, il convient de respecter certaines conventions si vous développez vos propres composants personnalisés.

Les propriétés suivantes doivent être utilisées :

Seuls les composants qui utilisent cette convention sont pris en compte.

Modèles de fragments d’expérience templates-for-experience-fragments

Lors du développement d’un nouveau modèle pour les fragments d’expérience, vous pouvez suivre les pratiques standard en vigueur pour un modèle modifiable.

Pour créer un modèle de fragment d’expérience détecté par l’assistant Créer un fragment d’expérience, vous devez suivre l’un des ensembles de règles suivants :

Composants des fragments d’expérience components-for-experience-fragments

Les composants de développement à utiliser avec ou dans les fragments d’expérience sont conformes aux pratiques standard.

La seule configuration supplémentaire consiste à s’assurer que les composants sont autorisés sur le modèle. Cette fonctionnalité est réalisée avec la politique de contenu.

Fournisseur de réécriture de liens de fragments d’expérience – HTML the-experience-fragment-link-rewriter-provider-html

Dans AEM, vous avez la possibilité de créer des fragments d’expérience. Un fragment d’expérience :

De tels groupes sont notamment utilisés pour incorporer du contenu dans des points de contact tiers, tels qu’Adobe Target.

Réécriture de lien par défaut default-link-rewriting

La fonction Exporter vers Target vous permet :

Cette fonction peut être activée sur une instance de création d’AEM. Elle nécessite une configuration Adobe Target valide, ainsi que des configurations pour l’externaliseur de liens.

L’externaliseur de liens sert à déterminer les URL appropriées qui sont nécessaires lors de la création de la version de l’offre Target HTML, qui est ensuite envoyée à Adobe Target. Adobe Target nécessite un accès public à tous les liens d’une offre Target HTML. Publiez le fragment d’expérience et toutes les ressources auxquelles ces liens font référence avant de les utiliser.

Par défaut, lorsque vous créez une offre HTML Target, une requête est envoyée à un sélecteur Sling personnalisé dans AEM. Ce sélecteur est appelé .nocloudconfigs.html. Comme son nom l’indique, il crée un rendu HTML brut d’un fragment d’expérience, mais n’inclut pas de configurations cloud (qui seraient des informations superflues).

Une fois que vous avez généré la page HTML, le pipeline Sling Rewriter apporte des modifications à la sortie :

Lors de l’utilisation d’une implémentation prête à l’emploi, le processus décrit ci-dessus est suffisant pour générer l’offre cible à partir du fragment d’expérience, puis l’exporter vers Adobe Target. Cependant, certains cas d’utilisation ne sont pas pris en compte dans ce processus, notamment les suivants :

Pour ces cas d’utilisation, AEM propose l’interface du fournisseur de réécriture de liens.

Interface du fournisseur de réécriture de liens link-rewriter-provider-interface

Pour les cas plus complexes, non couverts par le paramètre par défaut, AEM propose l’interface du fournisseur de réécriture de liens. Ce workflow est une interface ConsumerType que vous pouvez implémenter dans vos lots, en tant que service. Elle ignore les modifications qu’AEM effectue sur les liens internes d’une offre HTML telle qu’elle est générée à partir d’un fragment d’expérience. Cette interface vous permet de personnaliser le processus de réécriture des liens HTML internes afin de l’adapter aux besoins de votre entreprise.

Voici quelques exemples d’implémentation de cette interface en tant que service :

L’interface du fournisseur de réécriture de liens (ExperienceFragmentLinkRewriterProvider) se présente comme suit :

public interface ExperienceFragmentLinkRewriterProvider {

    String rewriteLink(String link, String tag, String attribute);

    boolean shouldRewrite(ExperienceFragmentVariation experienceFragment);

    int getPriority();

}

Utilisation de l’interface du fournisseur de réécriture de liens how-to-use-the-link-rewriter-provider-interface

Pour utiliser l’interface , vous devez d’abord créer un lot contenant un nouveau composant de service qui implémente l’interface du fournisseur de réécriture de liens.

Ce service est utilisé pour se connecter à la réécriture Exporter vers Target du fragment d’expérience afin qu’elle puisse avoir accès aux différents liens.

Par exemple, ComponentService :

import com.adobe.cq.xf.ExperienceFragmentLinkRewriterProvider;
import com.adobe.cq.xf.ExperienceFragmentVariation;
import org.osgi.service.component.annotations.Service;
import org.osgi.service.component.annotations.Component;

@Component
@Service
public class GeneralLinkRewriter implements ExperienceFragmentLinkRewriterProvider {

    @Override
    public String rewriteLink(String link, String tag, String attribute) {
        return null;
    }

    @Override
    public boolean shouldRewrite(ExperienceFragmentVariation experienceFragment) {
        return false;
    }

    @Override
    public int getPriority() {
        return 0;
    }

}

Pour que le service fonctionne, trois méthodes doivent à présent être implémentées en interne :

shouldRewrite shouldrewrite

Vous devez indiquer au système s’il doit ou non réécrire les liens lorsqu’un appel est effectué pour Exporter vers Target sur une variation donnée du fragment d’expérience. Vous pouvez effectuer cette implémentation en utilisant la méthode suivante :

shouldRewrite(ExperienceFragmentVariation experienceFragment);

Par exemple :

@Override
public boolean shouldRewrite(ExperienceFragmentVariation experienceFragment) {
    return experienceFragment.getPath().equals("/content/experience-fragment/master");
}

Cette méthode reçoit, en tant que paramètre, la variation du fragment d’expérience qui est actuellement réécrite par le système Exporter vers Target.

Dans l’exemple ci-dessus, vous souhaitez réécrire :

Le système Exporter vers Target ignore tous les autres fragments d’expérience qui transitent par ce système et ce service ne les affecte pas.

rewriteLink rewritelink

Pour la variation de fragment d’expérience affectée par le processus de réécriture, il continue à laisser le service gérer la réécriture des liens. Chaque fois qu’un lien est détecté dans le code HTML interne, la méthode suivante est appelée :

rewriteLink(String link, String tag, String attribute)

En entrée, la méthode reçoit les paramètres suivants :

Si, par exemple, le système Exporter vers Target traite cet élément, vous pouvez définir CSSInclude en tant que :

<link rel="stylesheet" href="/etc.clientlibs/foundation/clientlibs/main.css" type="text/css">

L’appel de la méthode rewriteLink() est effectué à l’aide des paramètres suivants :

rewriteLink(link="/etc.clientlibs/foundation/clientlibs/main.css", tag="link", attribute="href" )

Lorsque vous créez le service, vous pouvez prendre des décisions en fonction de l’entrée indiquée, puis réécrire le lien en conséquence.

Par exemple, vous souhaitez supprimer la partie /etc.clientlibs de l’URL et ajouter le domaine externe approprié. Pour simplifier les choses, nous partons du principe que nous avons accès à un résolveur de ressources pour le service, comme dans rewriteLinkExample2 :

private ResourceResolver resolver;

private Externalizer externalizer;

@Override
public String rewriteLink(String link, String tag, String attribute) {

    // get the externalizer service
    externalizer = resolver.adaptTo(Externalizer.class);
    if(externalizer == null) {
        // if there was an error, then we do not modify the link
        return null;
    }

    // remove leading /etc.clientlibs from resource link before externalizing
    link = link.replaceAll("/etc.clientlibs", "");

    // considering that we configured our publish domain, we directly apply the publishLink() method
    link = externalizer.publishLink(resolver, link);

    return link;
}

Priorités - getPriority priorities-getpriority

Vous aurez peut-être besoin de plusieurs services pour prendre en charge différents types de fragments d’expérience. Vous pouvez également utiliser un service générique pour externaliser et mapper tous les fragments d’expérience. Dans ce cas, des conflits peuvent survenir au niveau du service à utiliser. Aussi, AEM permet-il de définir des priorités pour différents services. Les priorités sont spécifiées en utilisant la méthode suivante :

Cette méthode permet d’utiliser plusieurs services pour lesquels la méthode shouldRewrite() renvoie la valeur « true » pour le même fragment d’expérience. Le service qui renvoie la valeur la plus élevée à partir de sa méthode getPriority() est celui qui traite la variation du fragment d’expérience.

Par exemple, un GenericLinkRewriterProvider peut gérer le mappage de base pour tous les fragments d’expérience et lorsque la méthode shouldRewrite() renvoie true pour toutes les variations du fragment d’expérience. Pour plusieurs fragments d’expérience spécifiques, une gestion spéciale peut être souhaitable. Dans ce cas, vous pouvez donc fournir un SpecificLinkRewriterProvider pour lequel la méthode shouldRewrite() ne renvoie la valeur « true » que pour certaines variations du fragment d’expérience. Pour s’assurer que SpecificLinkRewriterProvider est choisi pour traiter ces variations du fragment d’expérience, il doit renvoyer dans sa méthode getPriority() un nombre supérieur à GenericLinkRewriterProvider.