Wie Seiten für den Client gerendert werden
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:
- Ändern Sie die JS-Vorlage, das CSS und JavaScript erweitern/überschreiben.
-
So ändern Sie die für die JS-Vorlage oder den GET-Endpunkt verfügbaren Informationen:
- Erweitern Sie die SocialComponent.
-
So fügen Sie eine benutzerdefinierte Verarbeitung während der Vorgänge hinzu:
- Schreiben Sie eine OperationExtension.
-
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
-
Übergibt die Ressource (resourceType) an den
SocialComponentFactoryManager
und empfängt eine SocialComponentFactory, die einenSocialComponent
auswählen kann, der die Ressource darstellt. -
Ruft die Factory auf und empfängt ein
SocialComponent
, das die Ressource und die Anfrage verarbeiten kann. -
Ruft die
SocialComponent
auf, die die Anfrage verarbeitet und eine JSON-Darstellung der Ergebnisse zurückgibt. -
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.
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.
Speicherressourcenanbieter (SRP)
Weitere Informationen zum Umgang mit im Community Content Store gespeicherten benutzergenerierten Inhalten finden Sie unter:
- Speicherressourcenanbieter - Übersicht - Einführung und Repository-Nutzung - Übersicht.
- SRP und UGC Essentials - SRP API-Dienstprogrammmethoden und -Beispiele.
- Zugriff auf benutzergenerierten Inhalt mit SRP - Codierungs-Richtlinien.
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.