Client-seitige Anpassung client-side-customization

Um das Erscheinungsbild und/oder Verhalten einer AEM Communities-Komponente Client-seitig anzupassen, gibt es mehrere Ansätze.

Zwei Hauptansätze bestehen darin, eine Komponente zu überlagern oder zu erweitern.

Überlagern Eine Komponente ändert die Standardkomponente und wirkt sich auf jeden Verweis auf die Komponente aus.

Erweitern Eine Komponente mit eindeutigem Namen begrenzt den Umfang der Änderungen. Der Begriff „Verlängern“ wird synonym mit „Überschreiben“ verwendet.

Überlagerungen overlays

Das Überlagern einer Komponente ist eine Methode zum Ändern einer Standardkomponente und wirkt sich auf alle Instanzen aus, die die Standardkomponente verwenden.

Die Überlagerung erfolgt durch Ändern einer Kopie der Standardkomponente im Verzeichnis /apps anstatt durch Ändern der ursprünglichen Komponente im Verzeichnis /libs. Die Komponente wird mit einem identischen relativen Pfad erstellt, mit der Ausnahme, dass „libs“ durch „apps“ ersetzt wird.

Der Ordner "/apps“ ist der erste Ort, an dem gesucht wird, um Anfragen zu beheben. Wenn er nicht gefunden wird, wird die Standardversion im Ordner "/libs“ verwendet.

Die Standardkomponente im Verzeichnis /libs darf niemals geändert werden, da zukünftige Patches und Upgrades das Verzeichnis /libs bei Aufrechterhaltung öffentlicher Schnittstellen in beliebiger Weise ändern können.

Dies unterscheidet sich von Erweitern einer Standardkomponente, bei der Änderungen für einen bestimmten Zweck vorgenommen werden sollen, ein eindeutiger Pfad zur Komponente erstellt wird und auf die ursprüngliche Standardkomponente im Verzeichnis /libs als übergeordneten Ressourcentyp verwiesen wird.

Ein schnelles Beispiel für das Überlagern der Kommentarkomponente finden Sie im Tutorial Überlagerungskommentarkomponente.

Erweiterungen extensions

Das Erweitern (Überschreiben) einer Komponente ist eine Methode, um Änderungen für eine bestimmte Verwendung vorzunehmen, ohne dass sich dies auf alle Instanzen auswirkt, die die Standardeinstellung verwenden. Die erweiterte Komponente hat einen eindeutigen Namen im Ordner "/apps“ und verweist auf die Standardkomponente im Ordner "/libs“, sodass das Standarddesign und -verhalten einer Komponente nicht geändert wird.

Dies unterscheidet sich von Überlagerung der Standardkomponente, bei der die Natur von Sling relative Verweise auf die Programme/Ordner auflöst, bevor im Ordner „libs/" gesucht wird, sodass das Design oder Verhalten einer Komponente global geändert wird.

Ein kurzes Beispiel für die Erweiterung der Kommentarkomponente finden Sie im Tutorial Kommentarkomponente erweitern.

JavaScript-Bindung javascript-binding

Das HBS-Skript für die Komponente muss an die JavaScript-Objekte, -Modelle und -Ansichten gebunden sein, die diese Funktion implementieren.

Der Wert des data-scf-component kann der Standardwert sein, z. B. social/tally/components/hbs/rating, oder eine erweiterte (angepasste) Komponente für angepasste Funktionen wie weretail/components/hbs/rating.

Um eine Komponente zu binden, muss das gesamte Komponentenskript in ein <div>-Element mit den folgenden Attributen eingeschlossen werden:

Zum Beispiel von /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 custom-properties

Beim Erweitern oder Überlagern einer Komponente ist es möglich, Eigenschaften zu einem geänderten Dialogfeld hinzuzufügen.

Sie können auf alle Eigenschaften einer Komponente/Ressource zugreifen, indem Sie auf die Eigenschaftsschlüssel in der Handlebars-Vorlage verweisen:

{{properties.<property_name>}}

CSS wird skindern skinning-css

Die Anpassung von Komponenten an das allgemeine Design der Website kann durch „Skinning“ erreicht werden - Änderung von Farben, Schriftarten, Bildern, Schaltflächen, Links, Abständen und sogar Positionierung in einem gewissen Umfang.

Die Hautextrusion kann durch selektives Überschreiben der Framework-Stile oder durch das Schreiben völlig neuer Stylesheets erreicht werden. Die SCF-Komponenten definieren CSS-Klassen mit Namespace, Modular und Semantik, die sich auf die verschiedenen Elemente auswirken, aus denen eine Komponente besteht.

So hauten Sie eine Komponente ein:

Die benutzerdefinierten Stile setzen jetzt die Standard-Framework-Stile außer Kraft und die Komponente wird mit dem neuen Design gerendert.

Erweitern von JavaScript extending-javascript

Um eine JavaScript-Implementierung von zu erweitern, ist Folgendes erforderlich:

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

Skript-Tags script-tags

Skript-Tags sind ein inhärenter Bestandteil des Client-seitigen Frameworks. Sie sind der Kleber, der dabei hilft, das auf der Server-Seite generierte Markup mit den Modellen und Ansichten auf der Client-Seite zu verbinden.

Skript-Tags in SCF-Skripten sollten beim Überlagern oder Überschreiben von Komponenten nicht entfernt werden. SCF-Skript-Tags, die automatisch für das Einfügen von JSON in die HTML erstellt wurden, werden mit dem Attribut data-scf-json=true gekennzeichnet.

Clientlibs für SCF clientlibs-for-scf

Die Verwendung Client-seitigen(clientlibs) bietet eine Möglichkeit, die JavaScript und CSS, die zum Rendern von Inhalten auf dem Client verwendet werden, zu organisieren und zu optimieren.

Die Client-Bibliotheken für SCF folgen einem sehr spezifischen Benennungsmuster für zwei Varianten, die nur durch das Vorhandensein von „author“ im Kategorienamen variieren:

Vollständige Clientlibs complete-clientlibs

Die vollständigen (Nicht-Autoren-)Client-Bibliotheken enthalten Abhängigkeiten und eignen sich bequem zum Einschließen in ui:includeClientLib.

Diese Versionen befinden sich in:

Zum Beispiel:

Das Handbuch für Community-Komponenten listet die vollständigen Client-Bibliotheken auf, die für jede SCF-Komponente erforderlich sind.

Clientlibs für Communities-Komponenten beschreibt, wie einer Seite Clientlibs hinzugefügt werden.

Autoren-Clientlibs author-clientlibs

Die Client-Bibliotheken der Autorenversion werden auf das Minimum von JavaScript reduziert, das zur Implementierung der Komponente erforderlich ist.

Diese Client-Bibliotheken sollten niemals direkt eingeschlossen werden, sondern können stattdessen in andere Client-Bibliotheken eingebettet werden, die für eine Site handgefertigt werden.

Diese Versionen befinden sich im Ordner „SCF libs“:

Zum Beispiel:

Hinweis: Während Autoren-Client-Bibliotheken nie andere Bibliotheken einbetten, listen sie ihre Abhängigkeiten auf. Wenn die Abhängigkeiten in andere Bibliotheken eingebettet werden, werden sie nicht automatisch abgerufen und müssen ebenfalls eingebettet werden.

Die erforderlichen Autoren-Client-Bibliotheken können identifiziert werden, indem „author“ in die Client-Bibliotheken eingefügt wird, die für jede SCF-Komponente im Community-Komponentenhandbuch“ aufgeführt.

Überlegungen zur Verwendung usage-considerations

Jede Site unterscheidet sich in der Verwaltung von Client-Bibliotheken. Zu den verschiedenen Faktoren gehören: