⇐ Essentials | Serverseitige Anpassung ⇒ |
---|---|
SCF-Handlebars Helpers ⇒ |
Zum Anpassen des Erscheinungsbilds und/oder Verhaltens einer AEM Communities-Komponente auf Clientseite gibt es mehrere Ansätze.
Zwei Hauptansätze sind das Überlagern oder Erweitern einer Komponente.
Durch das Überlagern einer Komponente wird die Standardkomponente geändert und jeder Verweis auf die Komponente wird beeinflusst.
Die Erweiterung einer Komponente, die eindeutig benannt ist, schränkt den Umfang der Änderungen ein. Der Begriff "Erweiterung" wird synonym mit "Außerkraftsetzen" verwendet.
Das Überlagern einer Komponente ist eine Methode, um Änderungen an einer Standardkomponente vorzunehmen, die alle Instanzen betreffen, die den Standard verwenden.
Die Überlagerung erfolgt durch Ändern einer Kopie der Standardkomponente im Ordner "/apps", anstatt die Originalkomponente im Ordner "/libs"zu ändern. Die Komponente wird mit einem identischen relativen Pfad erstellt, außer 'libs' wird durch 'apps' ersetzt.
Der Ordner "/apps"ist der erste Ort, der zum Auflösen von Anforderungen gesucht wird. Wenn er nicht gefunden wird, wird die Standardversion im Ordner "/libs"verwendet.
Die Standardkomponente im Verzeichnis /libs darf nie geändert werden, da zukünftige Patches und Upgrades das Verzeichnis /libs auf jede erforderliche Weise ändern können, während öffentliche Schnittstellen beibehalten werden.
Dies unterscheidet sich von extension einer Standardkomponente, bei der Änderungen für eine bestimmte Verwendung vorgenommen werden sollen, wobei ein eindeutiger Pfad zur Komponente erstellt wird und auf der Verweise auf die ursprüngliche Standardkomponente im Verzeichnis /libs als Super-Ressourcentyp verwiesen wird.
Ein kurzes Beispiel zum Überlagern der Komponente "Kommentare"finden Sie im Tutorial Komponente "Überlagerungskommentare".
Das Erweitern (Überschreiben) einer Komponente ist eine Methode, um Änderungen für eine bestimmte Verwendung vorzunehmen, ohne dass alle Instanzen betroffen sind, die den Standard verwenden. Die erweiterte Komponente ist eindeutig im Ordner /apps benannt und verweist auf die Standardkomponente im Ordner /libs. Daher werden Standarddesign und Standardverhalten einer Komponente nicht geändert.
Dies unterscheidet sich von der Standardkomponente overlay, bei der die Art von Sling relative Verweise auf den Ordner "apps/"auflöst, bevor die Suche im Ordner "libs/"erfolgt, sodass das Design oder Verhalten einer Komponente global geändert wird.
Ein kurzes Beispiel zum Erweitern der Komponente "Kommentare"finden Sie im Tutorial Kommentare erweitern.
Das HBS-Skript für die Komponente muss an die JavaScript-Objekte, -Modelle und -Ansichten gebunden sein, die diese Funktion implementieren.
Der Wert des Attributs data-scf-component
kann der Standardwert sein, z. B. social/tally/components/hbs/rating
, oder eine erweiterte (benutzerdefinierte) Komponente für benutzerdefinierte Funktionen, z. B. weretail/components/hbs/rating.
Um eine Komponente zu binden, muss das gesamte Komponentenskript in ein <div>-Element mit den folgenden Attributen eingeschlossen sein:
data-component-id
="{{id}}"
löst die ID-Eigenschaft aus dem Kontext auf
data-scf-component
="<resourceType>
Beispiel:/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>
Beim Erweitern oder Überlagern einer Komponente können Eigenschaften zu einem geänderten Dialogfeld hinzugefügt werden.
Auf alle Eigenschaften, die für eine Komponente/Ressource festgelegt sind, kann über die Eigenschaftenschlüssel in der Vorlage für die Symbolleisten zugegriffen werden:
{{properties.<property_name>}}
Die Anpassung der Komponenten an das allgemeine Thema der Website kann durch "Skin" erreicht werden - durch eine Änderung der Farben, Schriftarten, Bilder, Schaltflächen, Links, Abstände und sogar Positionierung in einem bestimmten Umfang.
Skins lassen sich durch selektives Überschreiben der Rahmenstile oder durch komplett neue Stylesheets erzielen. Die SCF-Komponenten definieren namensespaced-, module- und semantische CSS-Klassen, die die verschiedenen Elemente einer Komponente beeinflussen.
So legen Sie eine Komponente als Skin fest:
Identifizieren Sie die Elemente, die Sie ändern möchten (z. B. Komponentenbereich, Symbolleistenschaltflächen, Meldungsart usw.).
Identifizieren Sie die CSS-Klasse/die CSS-Regeln, die sich auf diese Elemente auswirken.
Erstellen Sie eine Stylesheet-Datei (.css).
Schließen Sie das Stylesheet in einen Clientbibliotheksordner (clientlibs) für Ihre Site ein und vergewissern Sie sich, dass es in Ihren Vorlagen und Seiten mit ui:includeClientLib enthalten ist.
Definieren Sie die CSS-Klassen und -Regeln, die Sie im Stylesheet identifiziert haben (#2), neu und fügen Sie Stile hinzu.
Die benutzerdefinierten Stile überschreiben jetzt die standardmäßigen Rahmenstile und die Komponente wird mit der neuen Skin gerendert.
Jeder CSS-Klassenname, dem scf-js
vorangestellt wird, hat eine bestimmte Verwendung im JavaScript-Code. Diese Klassen wirken sich auf den Status einer Komponente aus (z. B. Umschalten von ausgeblendet zu sichtbar) und sollten weder überschrieben noch entfernt werden.
Die scf-js
-Klassen wirken sich zwar nicht auf Stile aus, die Klassennamen können jedoch in Stylesheets mit dem Vorbehalt verwendet werden, dass, da sie die Zustände von Elementen steuern, möglicherweise Nebenwirkungen auftreten.
Um eine JavaScript-Implementierung der Komponenten zu erweitern, müssen Sie:
(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);
Skript-Tags sind ein wesentlicher Bestandteil des clientseitigen Frameworks. Sie sind der Klebstoff, der dazu beiträgt, das auf dem Server generierte Markup mit den Modellen und Ansichten auf dem Client zu verbinden.
Skript-Tags in SCF-Skripten sollten beim Überlagern oder Überschreiben von Komponenten nicht entfernt werden. SCF-Skript-Tags, die automatisch für die JSON-Injektion in HTML erstellt wurden, werden mit dem Attribut data-scf-json=true
identifiziert.
Die Verwendung von clientseitigen Bibliotheken (clientlibs) bietet eine Möglichkeit zum Organisieren und Optimieren von Javascript und CSS, die zum Rendern von Inhalten auf dem Client verwendet werden.
Die clientlibs für SCF folgen einem sehr spezifischen Benennungsmuster für zwei Varianten, die nur durch das Vorhandensein von "author"im Namen der Kategorie variieren:
Clientlib-Variante | Muster für Eigenschaft "Kategorien" |
---|---|
complete clientlib | cq.social.hbs.<component name=""> |
author clientlib | cq.social.author.hbs.<component name=""> |
Die vollständigen clientlibs (ohne Autor) beinhalten Abhängigkeiten und eignen sich ideal für die Verwendung mit ui:includeClientLib.
Diese Versionen finden Sie unter:
/etc/clientlibs/social/hbs/<component name>
Beispiel:
/etc/clientlibs/social/hbs/forum
cq.social.hbs.forum
Im Handbuch "Community-Komponenten" werden die vollständigen clientlibs Liste, die für jede SCF-Komponente erforderlich sind.
clientlibs für Communities Components beschreibt, wie clientlibs zu einer Seite hinzugefügt werden.
Die Autorenversion clientlibs wird auf das für die Implementierung der Komponente erforderliche JavaScript-Minimum reduziert.
Diese clientlibs sollten niemals direkt eingeschlossen werden, sondern stehen stattdessen zur Einbettung in andere clientlibs zur Verfügung, die für eine Site handgefertigt sind.
Diese Versionen befinden sich im Ordner "SCF libs":
/libs/social/<feature>/components/hbs/<component name>/clientlibs
Beispiel:
/libs/social/forum/hbs/forum/clientlibs
cq.social.author.hbs.forum
Hinweis: Während Autor clientlibs nie andere Bibliotheken einbetten, machen sie Liste ihre Abhängigkeiten. Wenn sie in andere Bibliotheken eingebettet sind, werden die Abhängigkeiten nicht automatisch eingezogen und müssen auch eingebettet werden.
Die erforderlichen Autoren-clientlibs können identifiziert werden, indem Sie "author"in die clientlibs einfügen, die für jede SCF-Komponente im Community-Komponenten-Handbuch aufgelistet sind.
Jede Website ist anders, wenn es darum geht, Client-Bibliotheken zu verwalten. Zu den verschiedenen Faktoren gehören:
⇐ Essentials | Serverseitige Anpassung ⇒ |
---|---|
SCF-Handlebars Helpers ⇒ |