Personnalisation côté client client-side-customization

Pour personnaliser l’apparence et/ou le comportement d’un composant AEM Communities côté client, il existe plusieurs approches.

Deux approches principales consistent à recouvrir ou étendre un composant.

Recouvrement un composant modifie le composant par défaut et affecte chaque référence au composant.

L’extension ​’un composant, qui porte un nom unique, limite la portée des modifications. Le terme « extend » est utilisé de manière interchangeable avec « override ».

Recouvrements overlays

Le recouvrement d’un composant permet d’apporter des modifications à un composant par défaut et d’affecter toutes les instances qui utilisent le paramètre par défaut.

Pour ce faire, modifiez une copie du composant par défaut dans le répertoire /apps, plutôt que le composant d’origine dans le répertoire /libs. Le composant est construit avec un chemin relatif identique, sauf que « libs » est remplacé par « apps ».

Le répertoire /apps est la première recherche effectuée pour résoudre des demandes. S’il est introuvable, la version par défaut du répertoire /libs est utilisée.

Le composant par défaut du répertoire /libs ne doit jamais être modifié, car les correctifs et mises à niveau ultérieurs sont libres de modifier le répertoire /libs de toute manière nécessaire tout en conservant les interfaces publiques.

Cette opération diffère de l’extension d’un composant par défaut extension, où le souhait est d’apporter des modifications pour une utilisation spécifique, en créant un chemin d’accès unique au composant et en s’appuyant sur le référencement du composant par défaut d’origine dans le répertoire /libs comme type de super ressource.

Pour obtenir un exemple rapide de recouvrement du composant Commentaires, consultez le tutoriel Recouvrement du composant Commentaires.

Extensions extensions

L’extension (remplacement) d’un composant est une méthode permettant d’apporter des modifications pour une utilisation spécifique sans affecter toutes les instances qui utilisent la valeur par défaut. Le composant étendu est nommé de manière unique dans le dossier /apps et fait référence au composant par défaut dans le dossier /libs. Par conséquent, la conception et le comportement par défaut d’un composant ne sont pas modifiés.

Cela diffère du recouvrement composant par défaut où la nature de Sling résout les références relatives au dossier apps/ avant la recherche dans le dossier libs/ , de sorte que la conception ou le comportement d’un composant est modifié globalement.

Pour obtenir un exemple rapide d’extension du composant Comments, consultez le tutoriel Extension du composant Comments.

Liaison JavaScript javascript-binding

Le script HBS du composant doit être lié aux objets, modèles et vues JavaScript qui implémentent cette fonctionnalité.

La valeur de l’attribut data-scf-component peut être la valeur par défaut, par exemple social/tally/components/hbs/rating, ou un composant étendu (personnalisé) pour les fonctionnalités personnalisées, par exemple weretail/components/hbs/rating.

Pour lier un composant, l’intégralité du script du composant doit être incluse dans un élément <div> avec les attributs suivants :

Par exemple, depuis /apps/weretail/components/hbs/rating/rating.hbs :

<div class="we-Rating" data-component-id="`{{id}}`" data-scf-component="weretail/components/hbs/rating">

     <!-- HTML with HBS accessing the rating component -->

</div>

Propriétés personnalisées custom-properties

Lors de l’extension ou du recouvrement d’un composant, il est possible d’ajouter des propriétés à une boîte de dialogue modifiée.

Toutes les propriétés définies sur un composant/une ressource sont accessibles en référençant les clés de propriété dans le modèle Handlebars :

{{properties.<property_name>}}

CSS d’application de la peau skinning-css

La personnalisation des composants pour qu’ils correspondent au thème global du site web peut être réalisée en « créant l’habillage », c’est-à-dire en modifiant les couleurs, les polices, les images, les boutons, les liens, l’espacement et même le positionnement dans une certaine mesure.

La peau peut être créée en remplaçant de manière sélective les styles de structure ou en écrivant des feuilles de style entièrement nouvelles. Les composants SCF définissent des classes CSS d’espace de noms, modulaires et sémantiques qui affectent les différents éléments qui constituent un composant.

Pour appliquer l’enveloppe à un composant :

Les styles personnalisés remplacent désormais les styles de structure par défaut et le composant est rendu avec le nouvel habillage.

Extension de JavaScript extending-javascript

Pour étendre l’implémentation d’un JavaScript de composants, vous devez :

forum.js : Exemple d’extension de forum - HBS forum-js-sample-extension-of-forum-hbs

(function($CQ, _, Backbone, SCF) {
    "use strict";
    var GMForumView = SCF.ForumView.extend({
        viewName: "GMForum",
        showComposer: function(e) {
            SCF.ForumView.prototype.toggleComposer.apply(this);
            var cancel = this.$el.find('.cancel-new-topic');
            cancel.toggle();
        },
        hideComposer: function(e) {
            SCF.ForumView.prototype.toggleComposer.apply(this);
            var cancel = this.$el.find('.cancel-new-topic');
            cancel.toggle();
        }
    });

    SCF.registerComponent('social/forum/components/hbs/post', SCF.Post, SCF.PostView);
    SCF.registerComponent('social/forum/components/hbs/topic', SCF.Topic, SCF.TopicView);
    SCF.registerComponent('social/forum/components/hbs/forum', SCF.Forum, GMForumView );
})($CQ, _, Backbone, SCF);

Balises de script script-tags

Les balises de script font partie intégrante de la structure côté client. Ils constituent la colle qui permet de lier les balises générées côté serveur aux modèles et vues côté client.

Les balises de script dans les scripts SCF ne doivent pas être supprimées lors du remplacement de composants. Les balises de script SCF créées automatiquement pour injecter du code JSON dans HTML sont identifiées avec l’attribut data-scf-json=true.

Bibliothèques clientes pour SCF clientlibs-for-scf

L’utilisation de ​ bibliothèques côté client ​ (clientlibs) permet d’organiser et d’optimiser le JavaScript et le CSS utilisés pour effectuer le rendu du contenu sur le client.

Les bibliothèques clientes pour SCF suivent un modèle de dénomination très spécifique pour deux variantes, qui ne varient que par la présence de « author » dans le nom de la catégorie :

Bibliothèque cliente complète complete-clientlibs

Les bibliothèques clientes complètes (hors création) incluent des dépendances et sont pratiques à inclure dans l’interface utilisateur:includeClientLib.

Ces versions se trouvent dans :

Par exemple :

Le guide des composants de communauté répertorie toutes les bibliothèques clientes requises pour chaque composant SCF.

Clientlibs pour les composants de communautés décrit comment ajouter des bibliothèques clientes à une page.

Créer des bibliothèques clientes author-clientlibs

Les bibliothèques clientes de la version de création sont réduites au JavaScript minimal nécessaire à l’implémentation du composant.

Ces clientlibs ne doivent jamais être directement incluses, mais sont plutôt disponibles pour être intégrées à d’autres clientlibs, qui sont conçues à la main pour un site.

Ces versions se trouvent dans le dossier SCF libs :

Par exemple :

Remarque : bien que les bibliothèques clientes de création n’incorporent jamais d’autres bibliothèques, elles répertorient leurs dépendances. Lorsqu’elles sont incorporées dans d’autres bibliothèques, les dépendances ne sont pas automatiquement extraites et doivent également être incorporées.

Les bibliothèques clientes de création requises peuvent être identifiées en insérant « author » dans les bibliothèques clientes répertoriées pour chaque composant SCF dans le guide des composants de la communauté.

Considérations relatives à l’utilisation usage-considerations

Chaque site est différent dans la manière dont il gère les bibliothèques clientes. Divers facteurs comprennent :