⇐ Fonctionnalités Essentials | Personnalisation côté serveur |
---|---|
Aide-mémoire SCF → |
Pour personnaliser l’aspect et/ou le comportement d’un composant AEM Communities côté client, plusieurs approches sont possibles.
Deux approches principales consistent à superposer ou à étendre un composant.
La superposition d’un composant modifie le composant par défaut et affecte chaque référence au composant.
L’ extension d’un composant, dont le nom est unique, limite la portée des modifications. Le terme "extension" est utilisé de manière interchangeable avec "override".
Le chevauchement 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.
L’incrustation est réalisé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, sauf que 'libs' est remplacé par 'apps'.
Le répertoire /apps est le premier répertoire recherché pour résoudre les requêtes. S'il n'est pas trouvé, 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 futurs sont libres de modifier le répertoire /libs de toute manière nécessaire tout en conservant les interfaces publiques.
Il est différent de extension un composant par défaut où 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 se basant 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, consultez le didacticiel sur le composant de commentaires d’incrustation.
L’extension (remplacement) d’un composant est une méthode permettant d’apporter des modifications à une utilisation spécifique sans affecter toutes les instances qui utilisent la valeur par défaut. Le composant étendu porte un nom 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.
Ceci diffère de l'incrustation du composant par défaut dans lequel la nature de Sling résout des références relatives aux applications/ dossiers 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, consultez le didacticiel Étendre le composant de commentaires.
Le script HBS pour le 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, telle que 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, le script de composant entier doit être inclus dans un élément <div> avec les attributs suivants :
data-component-id
="{{id}}"
résout la propriété id du contexte
data-scf-component
="<resourceType>
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>
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 de barres de poignées :
{{properties.<property_name>}}
La personnalisation des composants pour correspondre au thème global du site Web peut être réalisée en "habillant" - en modifiant les couleurs, les polices, les images, les boutons, les liens, l'espacement et même le positionnement dans une certaine mesure.
L'habillage peut être réalisé en remplaçant sélectivement les styles de cadre ou en écrivant des feuilles de style entièrement nouvelles. Les composants SCF définissent des classes CSS espacées de noms, modulaires et sémantiques qui affectent les différents éléments qui composent un composant.
Pour habiller un composant :
Identifiez les éléments que vous souhaitez modifier (par exemple, zone de compositeur, boutons de barre d’outils, police du message, etc.).
Identifiez la classe/les règles CSS qui affectent ces éléments.
Créez un fichier de feuille de style (.css).
Incluez la feuille de style dans un dossier de bibliothèque client (clientlibs) pour votre site et assurez-vous qu'elle est incluse dans vos modèles et pages avec ui:includeClientLib.
Redéfinissez les classes CSS et les règles que vous avez identifiées (#2) dans votre feuille de style et ajoutez des styles.
Les styles personnalisés remplacent désormais les styles de cadre par défaut et le composant est rendu avec le nouvel habillage.
Tout nom de classe CSS précédé de scf-js-* a une utilisation spécifique dans le code javascript. Ces classes affectent l’état d’un composant (par exemple, bascule de masqué à visible) et ne doivent ni être remplacées ni supprimées.
Pendant que scf-js-& ; ast ; n'affecte pas les styles, les noms de classe peuvent être utilisés dans les feuilles de style avec la mise en garde que, puisqu'ils contrôlent l'état des éléments, il peut y avoir des effets secondaires.
Pour étendre une implémentation JavaScript de composants, vous devez uniquement
(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);
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 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 JSON dans le code HTML sont identifiées avec l’attribut data-scf-json=
true.
L’utilisation de bibliothèques côté client (clientlibs) permet d’organiser et d’optimiser le code JavaScript et le code CSS utilisés pour générer le 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 :
Variante Clientlib | Modèle pour la propriété Catégories |
---|---|
complete clientlib | cq.social.hbs.<component name=""> |
auteur clientlib | cq.social.author.hbs.<component name=""> |
Les clientlibs complets (non-auteur) incluent des dépendances et sont pratiques pour inclure avec ui:includeClientLib.
Ces versions se trouvent dans :
Par exemple :
Le guide Composants de la communauté liste les clientlibs complets requis pour chaque composant SCF.
Clientlibs for Communities Components décrit comment ajouter des clientlibs à une page.
Les clientlibs de version d’auteur sont réduits au minimum JavaScript nécessaire pour implémenter le composant.
Ces clientlibs ne doivent jamais être inclus directement, mais sont disponibles pour être incorporés à d'autres clientlibs, qui sont fabriqués à la main pour un site.
Ces versions se trouvent dans le dossier libs SCF :
Par exemple :
Remarque : bien que les clientlibs d'auteur n'intègrent jamais d'autres bibliothèques, ils font liste à 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 requis peuvent être identifiés en insérant "author" dans les clientlibs répertoriées pour chaque composant SCF dans le Guide des composants de la communauté.
Chaque site est différent dans la manière dont il gère les bibliothèques client. Divers facteurs sont à prendre en compte :
⇐ Fonctionnalités Essentials | Personnalisation côté serveur |
---|---|
Aide-mémoire SCF → |