Personnalisation côté client client-side-customization

Plusieurs méthodes permettent de personnaliser l’aspect et/ou le comportement d’un composant AEM Communities côté client.

Deux approches principales sont de superposer ou d’étendre un composant.

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

Extension un composant, dont le nom est unique, limite la portée des modifications. Le terme "extension" est utilisé de manière interchangeable avec "override".

Recouvrements overlays

Le recouvrement d’un composant est une méthode permettant d’apporter des modifications à un composant par défaut et d’affecter toutes les instances qui utilisent le composant par défaut.

La superposition est effectuée en modifiant une copie du composant par défaut dans le répertoire /apps, plutôt que de modifier le composant d’origine dans le répertoire /libs. Le composant est construit avec un chemin relatif identique, à l’exception près que "libs" est remplacé par "apps".

Le répertoire /apps est le premier emplacement recherché pour résoudre les requêtes. 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 peuvent modifier le répertoire /libs de toute manière nécessaire tout en conservant les interfaces publiques.

Ceci diffère de l’extension d’un composant par défaut dans lequel le désir est d’apporter des modifications pour une utilisation spécifique, en créant un chemin d’accès unique au composant et en utilisant le référencement du composant par défaut d’origine dans le répertoire /libs comme type de super-ressource.

Pour un exemple rapide de superposition du composant Commentaires, essayez le tutoriel sur le composant Commentaires de superposition.

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 référence le 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.

Ceci diffère de la superposition du composant par défaut dans lequel la nature de Sling résout les références relatives aux applications/dossiers avant la recherche dans le dossier libs/ , de sorte que la conception ou le comportement d’un composant est modifié globalement.

Pour un exemple rapide d’extension du composant Commentaires, essayez le tutoriel Étendre le composant Commentaires.

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, comme weretail/components/hbs/rating.

Pour lier un composant, le script de composant entier doit être inclus dans un élément <div> avec les attributs suivants :

Par exemple, de /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>}}

Esquisse de CSS skinning-css

Il est possible de personnaliser les composants pour qu’ils correspondent au thème global du site web en les "peignant" : en modifiant dans une certaine mesure les couleurs, les polices, les images, les boutons, les liens, l’espacement et même le positionnement.

L’habillage peut être réalisé en remplaçant sélectivement les styles de structure ou en écrivant des feuilles de style entièrement nouvelles. Les composants SCF définissent des classes CSS sémantiques, modulaires et avec espace de noms qui affectent les différents éléments qui constituent un composant.

Pour appliquer l’habillage d’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 une mise en oeuvre 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. Il s’agit de la colle qui permet de lier les balises générées côté serveur aux modèles et aux vues côté client.

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

Clientlibs pour SCF clientlibs-for-scf

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

Les clientlibs pour SCF suivent un modèle de dénomination très spécifique pour deux variantes, qui varie uniquement en fonction de la présence de "author" dans le nom de la catégorie :

Complète Clientlibs complete-clientlibs

Les clientlibs complètes (non-auteur) incluent des dépendances et sont pratiques pour inclure avec ui:includeClientLib.

Ces versions sont disponibles dans :

Par exemple :

Le Guide des composants de la communautérépertorie les bibliothèques clientes complètes requises pour chaque composant SCF.

Clientlibs for Communities Components décrit comment ajouter des clientlibs à une page.

Création de bibliothèques clientes author-clientlibs

Les clientlibs de version de création sont réduites au minimum JavaScript nécessaire pour mettre en oeuvre le composant.

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

Ces versions se trouvent dans le dossier libs SCF :

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 clientlibs d’auteur requises peuvent être identifiées en insérant "author" dans les clientlibs répertoriées pour chaque composant SCF dans le guide des composants de communauté.

Considérations sur l’utilisation usage-considerations

Chaque site est différent dans la manière dont il gère les bibliothèques clientes. Les facteurs suivants sont à prendre en compte :