Clientseitige Anpassung

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.

Überlagerungen

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".

Erweiterungen

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.

JavaScript-Bindung

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>

Benutzerdefinierte Eigenschaften

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>}}

Skin-CSS

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:

1. Identifizieren Sie die Elemente, die Sie ändern möchten (z. B. Komponentenbereich, Symbolleistenschaltflächen, Meldungsart usw.).

2. Identifizieren Sie die CSS-Klasse/die CSS-Regeln, die sich auf diese Elemente auswirken.

3. Erstellen Sie eine Stylesheet-Datei (.css).

4. 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.

5. 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.

Erweitern von JavaScript

Um eine JavaScript-Implementierung der Komponenten zu erweitern, müssen Sie:

1. Erstellen Sie eine Komponente für Ihre App, deren Wert "jcr:resourceSuperType"auf den Wert "jcr:resourceType"der erweiterten Komponente gesetzt ist, z. B. "social/forum/components/hbs/forum".
2. Prüfen Sie das Javascript der Standardkomponente der SCF, um zu bestimmen, welche Methoden mit SCF.registerComponent() registriert werden müssen.
3. Kopieren Sie entweder das JavaScript oder den Beginn der erweiterten Komponente von Grund auf.
4. Erweitern Sie die Methode.
5. Verwenden Sie SCF.registerComponent(), um alle Methoden entweder mit den Standardwerten oder den angepassten Objekten und Ansichten zu registrieren.

forum.js: Beispielerweiterung des Forums - 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);

Skript-Tags

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.

clipplibs für SCF

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:

Complete Clientlibs

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:

• Client-Ordnerknoten: /etc/clientlibs/social/hbs/forum
• Eigenschaft "Kategorien": 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.

Autor-Clientlibs

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:

• Client-Ordnerknoten: /libs/social/forum/hbs/forum/clientlibs
• Eigenschaft "Kategorien": 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.

Überlegungen zur Verwendung

Jede Website ist anders, wenn es darum geht, Client-Bibliotheken zu verwalten. Zu den verschiedenen Faktoren gehören:

• Gesamtgeschwindigkeit: Vielleicht möchten Sie, dass die Site reagiert, aber es ist akzeptabel, dass die erste Seite etwas langsam geladen wird. Wenn viele der Seiten dasselbe Javascript verwenden, können die verschiedenen Javascripts in eine clientlib eingebettet und von der ersten zu ladenden Seite aus referenziert werden. Das Javascript in diesem einzelnen Download bleibt zwischengespeichert, wodurch die Menge der herunterzuladenden Daten für nachfolgende Seiten minimiert wird.
• Kurzzeit bis zur ersten Seite: Vielleicht möchten Sie, dass die erste Seite schnell geladen wird. In diesem Fall befindet sich das Javascript in mehreren kleinen Dateien, auf die nur bei Bedarf verwiesen werden kann.
• Ein Gleichgewicht zwischen dem ersten Laden der Seite und nachfolgenden Downloads.