Wie Seiten für den Client gerendert werden

scf-page-rendering

Komponentenanpassung und -erweiterung

Um die Komponenten anzupassen oder zu erweitern, schreiben Sie nur die Überlagerungen und Erweiterungen in Ihr Verzeichnis "/apps“, was den Prozess der Aktualisierung auf zukünftige Versionen vereinfacht.

  • Für die Enthäutung:

  • Für Look-and-Feel:

    • Ändern Sie die JS-Vorlage und das CSS.
  • Für Look-and-Feel und UX:

  • So ändern Sie die für die JS-Vorlage oder den GET-Endpunkt verfügbaren Informationen:

  • So fügen Sie eine benutzerdefinierte Verarbeitung während der Vorgänge hinzu:

  • Hinzufügen eines benutzerdefinierten Vorgangs:

    • Erstellen Sie einen Sling-POST-Vorgang.
    • Verwenden Sie vorhandenennach Bedarf.
    • Fügen Sie JavaScript-Code hinzu, um Ihren Vorgang nach Bedarf Client-seitig aufzurufen.

Server-seitiges Framework

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

Java™-APIs

Die Java™-APIs bieten abstrakte Klassen und Schnittstellen, die einfach vererbt oder unterklassifiziert werden können.

Die wichtigsten Klassen werden auf der Seite Server-seitige Anpassung beschrieben.

Unter Übersicht über den Speicherressourcenanbieter erfahren Sie mehr über die Arbeit mit benutzergenerierten Inhalten.

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 einer Community-Site, als Service ohne Client ausgeführt zu werden, sodass Framework-Komponenten in jede Web-Seite integriert werden können, die auf einer beliebigen Technologie basiert.

HTTP-API - GET-Anfragen

Für jede SocialComponent stellt das Framework einen HTTP-basierten API-Endpunkt bereit. Auf den Endpunkt wird zugegriffen, indem eine GET-Anfrage mit einem ".social.json“-Selektor und einer Erweiterung an die Ressource gesendet wird. Mit Sling wird die Anfrage an den -DefaultSocialGetServlet übergeben.

DefaultSocialGetServlet

  1. Übergibt die Ressource (resourceType) an den SocialComponentFactoryManager und empfängt eine SocialComponentFactory, die einen SocialComponent auswählen kann, der die Ressource darstellt.

  2. Ruft die Factory auf und empfängt ein SocialComponent, das die Ressource und die Anfrage verarbeiten kann.

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

  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 anpassbarem JSON antwortet.

SCF-Framework

HTTP-API - POST-Anfragen

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

Dieses Framework-Endpunktmuster macht CUD-Vorgänge erweiterbar, wiederverwendbar und testbar.

POST Request

Für jeden SocialComponent-Vorgang gibt es einen Sling-Vorgang POST:operation . Die Geschäftslogik und der Wartungscode für jeden Vorgang werden in einen OperationService eingeschlossen, auf den über die HTTP-API oder von einer anderen Stelle aus als OSGi-Dienst zugegriffen werden kann. Hooks unterstützen Plug-In-Operationserweiterungen für Vor-/Nachher-Aktionen.

SCF nach Anfrage

Speicherressourcenanbieter (SRP)

Weitere Informationen zum Umgang mit im Community Content Store gespeicherten benutzergenerierten Inhalten finden Sie unter:

Server-seitige Anpassungen

Unter Server-seitige 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 Handlebars JS (HBS)-Vorlagensprache, einer beliebten Open-Source-Technologie für das Server-Client-Rendering.

HBS-Skripte sind einfach, ohne Logik, auf Server und Client kompiliert, einfach zu überlagern und anzupassen und natürlich an die Client-Benutzeroberfläche zu binden, da HBS das Client-seitige Rendering unterstützt.

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

Wenn Sling eine GET-Anfrage auflöst, identifiziert es auf dem Server das Skript, das verwendet wird, um auf die Anfrage zu reagieren. Wenn es sich bei dem Skript um eine HBS-Vorlage (.hbs) handelt, delegiert Sling die Anfrage an die Handlebars-Engine. Die Handlebars-Engine ruft dann die SocialComponent aus der entsprechenden SocialComponentFactory ab, erstellt einen Kontext und rendert die HTML.

Keine Zugriffsbeschränkung

Handlebars-Vorlagendateien (HBS) (.hbs) sind analog zu .jsp- und .html-Vorlagendateien, mit der Ausnahme, dass sie zum Rendern sowohl im Client-Browser als auch auf dem Server verwendet werden können. Daher erhält ein Client-Browser, der eine Client-seitige Vorlage anfordert, eine HBS-Datei vom Server.

Dazu müssen 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.

Der HTTP-Zugriff auf HBS-Dateien darf nicht verboten werden.