Social Component Framework

Das Social Component Framework (SCF) vereinfacht die Konfiguration, Anpassung und Erweiterung von Communities-Komponenten auf Server- und Client-Seite.

Vorteile des Frameworks:

  • Funktionell: Native Integration mit wenig oder gar keiner Anpassung für 80 % der Anwendungsfälle.
  • Skinable: Konsistente Verwendung von HTML-Attributen für CSS-Stile.
  • Erweiterbar: Die Komponentenimplementierung ist objektorientiert und basiert auf der Geschäftslogik - einfach hinzuzufügen, inkrementelle Geschäftsanmeldungen auf dem Server.
  • Flexibel: Einfache JavaScript-Vorlagen ohne Logik, die einfach überlagert und angepasst werden können.
  • Zugänglich: Die HTTP-API unterstützt das Posten von jedem Client, einschließlich mobiler Apps.
  • Tragbar: Integrieren/einbetten Sie in jede Webseite, die auf einer beliebigen Technologie basiert.

Erkunden Sie eine Autoren- oder Veröffentlichungsinstanz mithilfe des interaktiven Leitfadens Community-Komponenten.

Übersicht

In SCF besteht eine Komponente aus einem SocialComponent POJO, einer Handlebars-JS-Vorlage (zum Rendern der Komponente) und CSS (zum Formatieren der Komponente).

Eine Handlebars-JS-Vorlage kann die JS-Komponenten model/view erweitern, um die Benutzerinteraktion mit der Komponente auf dem Client zu handhaben.

Wenn eine Komponente die Änderung von Daten unterstützen muss, kann die Implementierung der SocialComponent-API geschrieben werden, um die Bearbeitung/Speicherung von Daten ähnlich den Modell-/Datenobjekten in herkömmlichen Webanwendungen zu unterstützen. Darüber hinaus können Vorgänge (Controller) und ein Vorgangsdienst hinzugefügt werden, um Vorgangsanfragen zu verarbeiten, Geschäftslogik auszuführen und die APIs für die Modell-/Datenobjekte aufzurufen.

Die SocialComponent-API kann erweitert werden, um Daten bereitzustellen, die von einem Client für eine Ansichtsebene oder einen HTTP-Client benötigt werden.

Darstellung von Seiten für Client

scf-page-rendering

Komponentenanpassung und -erweiterung

Um die Komponenten anzupassen oder zu erweitern, schreiben Sie nur die Überlagerungen und Erweiterungen in Ihr Verzeichnis /apps , wodurch die Aktualisierung auf zukünftige Versionen vereinfacht wird.

  • Für Skinning:
  • Für Look and Feel:
    • Ändern Sie die JS-Vorlage und CSS.
  • Für Look, Feel und UX:
  • So ändern Sie die Informationen, die für die JS-Vorlage oder für den GET-Endpunkt verfügbar sind:
  • So fügen Sie benutzerdefinierte Verarbeitung während Vorgängen hinzu:
  • So fügen Sie einen neuen benutzerdefinierten Vorgang hinzu:
    • Erstellen Sie einen neuen Sling Post Operation.
    • Verwenden Sie bei Bedarf vorhandene OperationServices.
    • Fügen Sie nach Bedarf JavaScript-Code hinzu, um Ihren Vorgang vom Client aus aufzurufen.

Server-seitiges Framework

Das Framework stellt APIs für den Zugriff auf Funktionen auf dem Server und die Interaktion zwischen Client und Server bereit.

Java-APIs

Die Java-APIs bieten abstrakte Klassen und Schnittstellen, die einfach geerbt oder unterteilt werden können.

Die Hauptklassen werden auf der Seite Serverseitige Anpassung beschrieben.

Besuchen Sie Übersicht über den Speicheranbieter, um mehr über die Arbeit mit UGC zu erfahren.

HTTP-API

Die HTTP-API unterstützt die einfache Anpassung und Auswahl von Client-Plattformen für PhoneGap-Apps, native Apps und andere Integrationen und Mashups. Darüber hinaus ermöglicht die HTTP-API es einer Community-Site, als Dienst ohne Client ausgeführt zu werden, sodass Framework-Komponenten in jede auf einer beliebigen Technologie aufbauende Webseite integriert werden können.

HTTP-API - GET-Anfragen

Für jede SocialComponent stellt das Framework einen HTTP-basierten API-Endpunkt bereit. Der Zugriff auf den Endpunkt erfolgt durch Senden einer GET-Anfrage an die Ressource mit der Selektor + Erweiterung ".social.json". Mit Sling wird die Anfrage an DefaultSocialGetServlet übergeben.

DefaultSocialGetServlet

  1. Übergibt die Ressource (resourceType) an SocialComponentFactoryManager und erhält eine SocialComponentFactory, die eine SocialComponent-Ressource auswählen kann, die die Ressource darstellt.

  2. Ruft die Factory auf und erhält einen SocialComponent , der die Ressource und Anforderung verarbeiten kann.

  3. Ruft SocialComponent auf, wodurch die Anfrage verarbeitet und eine JSON-Darstellung der Ergebnisse zurückgegeben wird.

  4. Gibt die JSON-Antwort an den Client zurück.

GET Request

Ein standardmäßiges GET-Servlet überwacht .social.json -Anfragen, auf die die SocialComponent mit anpassbarer JSON antwortet.

scf-framework

HTTP-API - POST-Anfragen

Zusätzlich zu den GET (Lesen)-Vorgängen definiert das Framework ein Endpunktmuster, um andere Vorgänge für eine Komponente zu aktivieren, darunter Erstellen, Aktualisieren und Löschen. Diese Endpunkte sind HTTP-APIs, die Eingaben akzeptieren und entweder mit HTTP-Statuscodes oder mit einem JSON-Antwortobjekt antworten.

Dieses Framework-Endpunktmuster macht CUD-Vorgänge erweiterbar, wiederverwendbar und prüfbar.

POST Request

Für jeden Vorgang "SocialComponent"gibt es einen Sling-Vorgang POST:operation. Die Geschäftslogik und der Wartungscode für jeden Vorgang sind in einen OperationService eingeschlossen, auf den über die HTTP-API oder von einem anderen Ort aus als OSGi-Dienst zugegriffen werden kann. Erweiterungen von Plug-ins für Vor-/Nach-Aktionen werden über Erweiterungen von Erweiterungen bereitgestellt.

scf-post-request

Storage Resource Provider (SRP)

Informationen zur Handhabung von UGC, die im Community-Inhaltsspeicher gespeichert sind, finden Sie unter:

Serverseitige Anpassungen

Unter Serverseitige Anpassungen finden Sie Informationen zum Anpassen der Geschäftslogik und des Verhaltens einer Communities-Komponente auf der Server-Seite.

Handlebars JS-Vorlagensprache

Eine der auffälligsten Änderungen im neuen Framework ist die Verwendung der Vorlagensprache Handlebars JS (HBS), einer beliebten Open-Source-Technologie für Server-Client-Rendering.

HBS-Skripte sind einfach, logiklos, auf dem Server und Client kompiliert, einfach zu überlagern und anzupassen und sind natürlich mit der Client-UX verbunden, da HBS das Client-seitige Rendering unterstützt.

Das Framework stellt mehrere Handlebars-Helfer bereit, die bei der Entwicklung von SocialComponents nützlich sind.

Wenn Sling auf dem Server eine GET-Anfrage auflöst, identifiziert er das Skript, das zur Beantwortung der Anfrage verwendet wird. Wenn das Skript eine HBS-Vorlage (.hbs) ist, delegiert Sling die Anforderung an die Handlebars-Engine. Die Handlebars-Engine ruft dann die SocialComponent von der entsprechenden SocialComponentFactory ab, erstellt einen Kontext und rendert den HTML-Code.

Keine Zugriffsbeschränkung

Handlebars (HBS)-Vorlagendateien (.hbs) entsprechen .jsp- und .html-Vorlagendateien, können jedoch sowohl im Client-Browser als auch auf dem Server für die Wiedergabe verwendet werden. Daher erhält ein Client-Browser, der eine clientseitige Vorlage anfordert, eine .hbs-Datei vom Server.

Dies erfordert, dass alle HBS-Vorlagen im Sling-Suchpfad (alle .hbs-Dateien unter /libs/ oder /apps) von jedem Benutzer aus der Autoren- oder Veröffentlichungsinstanz abgerufen werden können.

HTTP-Zugriff auf .hbs-Dateien ist möglicherweise nicht verboten.

Hinzufügen oder Einschließen einer Communities-Komponente

Die meisten Communities-Komponenten müssen added als adressierbare Sling-Ressource sein. Einige Communitys-Komponenten können enthalten in einer Vorlage als nicht vorhandene Ressource sein, um eine dynamische Einbindung und Anpassung des Speicherorts zu ermöglichen, an dem benutzergenerierte Inhalte geschrieben werden (UGC).

In beiden Fällen müssen auch die erforderlichen Client-Bibliotheken der Komponente vorhanden sein.

Hinzufügen einer Komponente

Das Hinzufügen einer Komponente bezieht sich auf den Prozess des Hinzufügens einer Instanz einer Ressource (Komponente), z. B. wenn diese aus dem Komponenten-Browser (Sidekick) auf eine Seite im Bearbeitungsmodus für Autoren gezogen wird.

Das Ergebnis ist ein untergeordneter JCR-Knoten unter einem par -Knoten, der Sling-adressierbar ist.

Komponente einschließen

Das Einschließen einer Komponente bezieht sich auf den Prozess zum Hinzufügen eines Verweises auf eine "nicht vorhandene"Ressource (kein JCR-Knoten) innerhalb der Vorlage, z. B. mithilfe einer Skriptsprache.

Ab AEM 6.1 ist es möglich, die Eigenschaften der Komponente im Authoring *design *mode zu bearbeiten, wenn eine Komponente dynamisch eingeschlossen statt hinzugefügt wird.

Es können nur einige ausgewählte AEM Communities-Komponenten dynamisch eingeschlossen werden. Sie sind:

Im Community Components Guide können einbeziehbare Komponenten umgeschaltet werden, sodass sie nicht hinzugefügt werden.

Bei Verwendung der Vorlagensprache Handlebarstemplating wird die nicht vorhandene Ressource mit dem include- Helperby eingeschlossen, indem der Ressourcentyp angegeben wird:

{{include this.id path="comments" resourceType="social/commons/components/hbs/comments"}}

Bei Verwendung von JSP wird eine Ressource mit dem Tag cq:include eingeschlossen:

<cq:include path="votes"
 resourceType="social/tally/components/voting" />
HINWEIS

Informationen zum dynamischen Hinzufügen einer Komponente zu einer Seite finden Sie unter Komponenten-Sideloading, anstatt sie in eine Vorlage hinzuzufügen oder einzufügen.

Handlebars Helpers

Eine Liste und Beschreibung der in SCF verfügbaren benutzerdefinierten Helfer finden Sie unter SCF Handlebars Helpers .

Client-seitiges Framework

JavaScript-Framework für Modellansichten

Das Framework umfasst eine Erweiterung von Backbone.js, einem JavaScript-Framework für Modellansichten, um die Entwicklung von komplexen, interaktiven Komponenten zu erleichtern. Die objektorientierte Natur unterstützt ein erweiterbares/wiederverwendbares Framework. Die Kommunikation zwischen Client und Server wird mithilfe der HTTP-API vereinfacht.

Das Framework nutzt serverseitige Handlebars-Vorlagen, um die Komponenten für den Client zu rendern. Die Modelle basieren auf den von der HTTP-API generierten JSON-Antworten. Die Ansichten binden sich an HTML, das von den Handlebars-Vorlagen generiert wurde, und bieten Interaktivität.

CSS-Konventionen

Die folgenden Konventionen werden zum Definieren und Verwenden von CSS-Klassen empfohlen:

  • Verwenden Sie eindeutig Namespace-CSS-Klassenselektornamen und vermeiden Sie allgemeine Namen wie "Überschrift", "Bild"usw.
  • Definieren Sie bestimmte Stile für Klassenselektoren, damit die CSS-Stylesheets mit anderen Elementen und Stilen auf der Seite gut funktionieren. Beispiel: .social-forum .topic-list .li { color: blue; }
  • Halten Sie CSS-Klassen für die Formatierung getrennt von CSS-Klassen für UX, die von JavaScript gesteuert werden.

Clientseitige Anpassungen

Um das Erscheinungsbild und Verhalten einer Communities-Komponente Client-seitig anzupassen, verweisen Sie auf Client-seitige Anpassungen, die Informationen zu folgenden Themen enthalten:

Funktionen und Komponentengrundlagen

Grundlegende Informationen für Entwickler werden im Abschnitt Funktionen und Komponenten-Grundlagen beschrieben.

Weitere Entwicklerinformationen finden Sie im Abschnitt Coding Guidelines .

Fehlerbehebung

Allgemeine Probleme und bekannte Probleme werden im Abschnitt Fehlerbehebung beschrieben.

Auf dieser Seite