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 /apps plutôt que de modifier le composant d’origine dans /libs répertoire . 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 située dans le 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.

Différent de extension un composant par défaut dans lequel vous souhaitez apporter des modifications pour une utilisation spécifique, en créant un chemin d’accès unique au composant et en vous reposant sur 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 de 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.

Différent de superposition le composant par défaut dans lequel la nature de Sling résout les références relatives au dossier apps/ avant de rechercher 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 de commentaires, essayez le Tutoriel sur le composant Extension des 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 la variable data-scf-component peut être la valeur par défaut, par exemple social/tally/components/hbs/rating ou un composant étendu (personnalisé) pour des fonctionnalités personnalisées, telles que weretail/components/hbs/rating.

Pour lier un composant, l’intégralité du script du composant doit être incluse dans une balise <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 "peignant" : en changeant dans une certaine mesure les couleurs, polices, images, boutons, liens, espacements 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 sémantiques, modulaires et à espaces 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 implémentation JavaScript de composants, vous devez uniquement

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 le HTML sont identifiées par l’attribut . data-scf-json=true.

Clientlibs pour SCF clientlibs-for-scf

L’utilisation de bibliothèques côté client (clientlibs) fournit un moyen d’organiser et d’optimiser le code JavaScript et le code 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 communauté répertorie les bibliothèques client complètes requises pour chaque composant SCF.

Clientlibs des composants Communities décrit comment ajouter des bibliothèques client à une page.

Création de bibliothèques clientes author-clientlibs

Les clientlibs de version de création sont réduites au JavaScript minimal 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 d’auteur 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 la variable 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. Plusieurs facteurs sont les suivants :