Grundlegende AEM-Konzepte aem-core-concepts

Voraussetzungen für die Entwicklung in AEM prerequisites-for-developing-on-aem

Sie benötigen die folgenden Fähigkeiten, um zusätzlich zu AEM entwickeln zu können:

Es wird außerdem empfohlen, dass Sie die Richtlinien und Best Practices lesen und befolgen.

Java Content Repository java-content-repository

Der Java Content Repository-Standard JSR 283 legt eine hersteller- und implementierungsunabhängige Methode für den bidirektionalen Zugriff auf Inhalte auf einer granularen Ebene in einem Content-Repository fest.

Spezifikations-Lead wird von der Adobe Research (Switzerland) AG gehalten.

Das JCR API 2.0-Paket, javax.jcr.* wird für den direkten Zugriff und die Bearbeitung von Repository-Inhalten verwendet.

Experience Server (CRX) und Jackrabbit experience-server-crx-and-jackrabbit

Der Experience Server stellt die Experience Services bereit, auf denen AEM aufbaut und die zum Erstellen benutzerdefinierter Anwendungen genutzt werden können. Außerdem wird das Content Repository basierend auf Jackrabbit eingebettet.

Apache Jackrabbit ist eine Open-Source-Implementierung der JCR-API 2.0, die vollständig konform ist.

Sling-Anfrageverarbeitung sling-request-processing

Einführung in Sling introduction-to-sling

AEM basiert auf Sling, einem auf REST-Prinzipien basierenden Web-Anwendungs-Framework, das eine einfache Entwicklung von inhaltsorientierten Programmen ermöglicht. Sling verwendet ein JCR-Repository wie Apache Jackrabbit oder im Falle von AEM das CRX Content Repository als eigenen Datenspeicher. Sling ist Teil der Apache Software Foundation – weitere Informationen finden Sie bei Apache.

Bei Verwendung von Sling ist der Typ des zu rendernden Inhalts nicht die erste Verarbeitungsüberlegung. Stattdessen ist die Hauptüberlegung, ob die URL zu einem Inhaltsobjekt aufgelöst wird, für das dann ein Skript gefunden werden kann, um das Rendering durchzuführen. Dies bietet Autoren von Web-Inhalten hervorragende Unterstützung beim Erstellen von Seiten, die einfach an ihre Anforderungen angepasst werden können.

Die Vorteile dieser Flexibilität zeigen sich in Programmen mit einer großen Auswahl verschiedener Inhaltselemente oder wenn Sie Seiten benötigen, die einfach angepasst werden können. Insbesondere bei der Implementierung eines Web Content Management-Systems wie WCM in die AEM Lösung.

Siehe Entdecken Sie Sling in 15 Minuten für die ersten Schritte zur Entwicklung mit Sling.

Das folgende Diagramm erläutert die Sling-Skriptauflösung: Es wird gezeigt, wie Sie von der HTTP-Anfrage zum Inhaltsknoten, vom Inhaltsknoten zum Ressourcentyp, vom Ressourcentyp zum Skript gelangen und welche Skriptvariablen verfügbar sind.

Das folgende Diagramm erläutert alle ausgeblendeten, aber leistungsfähigen Anforderungsparameter, die Sie beim Umgang mit dem SlingPostServlet verwenden können, dem Standardhandler für alle POST-Anforderungen, der Ihnen endlose Optionen zum Erstellen, Ändern, Löschen, Kopieren und Verschieben von Knoten im Repository bietet.

Sling ist inhaltszentriert sling-is-content-centric

Sling ist inhaltzentriert. Dies bedeutet, dass sich die Verarbeitung auf den Inhalt konzentriert, da jede (HTTP-)Anfrage auf den Inhalt in Form einer JCR-Ressource (eines Repository-Knotens) abgebildet wird:

RESTful Sling restful-sling

Aufgrund der inhaltsorientierten Philosophie implementiert Sling einen REST-orientierten Server und bietet damit ein neues Konzept für Webanwendungs-Frameworks. Die Vorteile:

URL-Zerlegung url-decomposition

In Sling wird die Verarbeitung durch die URL der Benutzeranfrage gesteuert. Dies definiert den Inhalt, der von den entsprechenden Skripten angezeigt werden soll. Zu diesem Zweck werden Informationen aus der URL extrahiert.

Wenn wir die folgende URL analysieren:

https://myhost/tools/spy.printable.a4.html/a/b?x=12

Wir können ihn in seine zusammengesetzten Teile aufschlüsseln:

protocol – HTTP

host – Name der Website.

content path – Pfad, der den Inhalt angibt, der gerendert werden soll. Wird in Kombination mit der Erweiterung verwendet. In diesem Beispiel werden sie in tools/spy.html übersetzt.

selector(s)  – wird für alternative Methoden zum Rendern des Inhalts verwendet. In diesem Beispiel eine druckerfreundliche Version im A4-Format.

extension  – Inhaltsformat; gibt außerdem das Skript an, das zum Rendern verwendet werden soll.

suffix  – kann verwendet werden, um zusätzliche Information anzugeben.

param(s)  – Alle Parameter, die für dynamischen Inhalt erforderlich sind.

Von URL zu Inhalt und Skripten from-url-to-content-and-scripts

Gehen Sie wie folgt vor:

Die nachstehende Abbildung zeigt den verwendeten Mechanismus, der in den folgenden Abschnitten ausführlicher behandelt wird.

Mit Sling geben Sie an, welches Skript eine bestimmte Entität rendert (indem Sie die Eigenschaft sling:resourceType im JCR-Knoten festlegen). Dieser Mechanismus bietet mehr Freiheit als einer, in dem das Skript auf die Datenentitäten zugreift (wie es eine SQL-Anweisung in einem PHP-Skript tun würde), da eine Ressource mehrere Ausgabedarstellungen haben kann.

Anforderungen Ressourcen zuordnen mapping-requests-to-resources

Die Anfrage wird zerlegt und die notwendigen Informationen werden extrahiert. Das Repository wird nach der angeforderten Ressource (Inhaltsknoten) gesucht:

Sling erlaubt auch anderen Elementen als JCR-Knoten, als Ressourcen zu fungieren, dies ist jedoch eine erweiterte Funktion.

Skript suchen locating-the-script

Wenn die entsprechende Ressource (Inhaltsknoten) gefunden wird, wird der Sling-Ressourcentyp extrahiert. Dies ist ein Pfad, der das Skript findet, das zum Rendern des Inhalts verwendet werden soll.

Der vom sling:resourceType angegebene Pfad kann wie folgt sein:

Alle Sling-Skripte werden in Unterordnern von entweder /apps oder /libs gespeichert. Diese werden in dieser Reihenfolge durchsucht (siehe Anpassen von Komponenten und anderen Elementen).

Einige andere zu beachtende Punkte sind:

Die Liste der von der angegebenen Instanz von AEM unterstützten Skript-Engines wird in der Felix Management Console aufgeführt (http://<host>:<port>/system/console/slingscripting).

Darüber hinaus unterstützt Apache Sling die Integration mit anderen gängigen Skript-Engines (z. B. Groovy, JRuby, Freemarker) und bietet eine Möglichkeit zur Integration neuer Skript-Engines.

Unter Verwendung des obigen Beispiels, wenn der sling:resourceType hr/jobs lautet:

Wenn mehrere Skripte für eine bestimmte Anfrage gelten, wird das Skript mit der besten Übereinstimmung ausgewählt. Je genauer eine Übereinstimmung ist, desto besser ist sie. Mit anderen Worten: Je mehr Selektor dem Besseren entspricht, unabhängig von einer beliebigen Anfrageerweiterung oder einer Übereinstimmung mit dem Methodennamen.

Beispiel: Eine Anfrage zum Zugriff auf die Ressource
/content/corporate/jobs/developer.print.a4.html
vom Typ
sling:resourceType="hr/jobs"

Angenommen, wir haben die folgende Liste von Skripten am richtigen Speicherort:

Dann wäre die Reihenfolge der Bevorzugung (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1).

Zusätzlich zu den Ressourcentypen (primär definiert durch die Eigenschaft sling:resourceType) gibt es auch den Supertyp der Ressource. Dieser wird normalerweise durch die Eigenschaft sling:resourceSuperType angezeigt. Diese Supertypen werden ebenfalls berücksichtigt, wenn Sie versuchen, ein Skript zu finden. Der Vorteil von Ressourcensupertypen besteht darin, dass sie eine Hierarchie von Ressourcen bilden können, wobei der Standard-Ressourcentyp sling/servlet/default (von den Standard-Servlets verwendet) effektiv der Stamm ist.

Der Ressourcensupertyp einer Ressource kann auf zwei Arten definiert werden:

Beispiel:

Die Typhierarchie von:

Grund hierfür ist, dass /y die Eigenschaft sling:resourceSuperType aufweist, während /x sie nicht aufweist und daher der Obertyp vom Ressourcentyp übernommen wird.

Sling-Skripte können nicht direkt aufgerufen werden sling-scripts-cannot-be-called-directly

In Sling können Skripte nicht direkt aufgerufen werden, da dies das strikte Konzept eines REST-Servers beeinträchtigen würde. würden Sie Ressourcen und Darstellungen mischen.

Wenn Sie die Repräsentation (das Skript) direkt aufrufen, blenden Sie die Ressource in Ihrem Skript aus, sodass das Framework (Sling) nicht mehr davon weiß. So verlieren Sie bestimmte Funktionen:

Sling-API sling-api

Hierbei wird das Sling-API-Paket org.apache.sling verwendet.* und -Tag-Bibliotheken.

Referenzieren von vorhandenen Elementen mithilfe von sling:include referencing-existing-elements-using-sling-include

Eine letzte Überlegung ist die Notwendigkeit, auf vorhandene Elemente innerhalb der Skripte zu verweisen.

Komplexere Skripte (aggregierende Skripte) müssen möglicherweise auf mehrere Ressourcen zugreifen (z. B. Navigation, Seitenleiste, Fußzeile, Elemente einer Liste) und tun dies durch Einbeziehen der Ressource.

Dazu können Sie den Befehl sling:include("/<path>/<resource>") verwenden. Dies umfasst effektiv die Definition der referenzierten Ressource, wie in der folgenden Anweisung, die auf eine vorhandene Definition für das Rendern von Bildern verweist:

%><sling:include resourceType="geometrixx/components/image/img"/><%

OSGI osgi

OSGi definiert eine Architektur für die Entwicklung und Bereitstellung modularer Anwendungen und Bibliotheken (es wird auch als Dynamic Module System für Java bezeichnet). OSGi-Container erlauben es Ihnen, Ihr Programm in einzelne Module aufzuteilen (JAR-Dateien mit zusätzlichen Metainformationen und sogenannten Bundles in OSGi-Terminologie) und die Querabhängigkeiten zwischen ihnen zu verwalten mit:

Diese Services und Verträge bieten eine Architektur, die es einzelnen Elementen ermöglicht, sich dynamisch für die Zusammenarbeit zu entdecken.

Ein OSGi-Framework bietet Ihnen dann dynamisches Laden/Entladen, Konfiguration und Steuerung dieser Bundles - ohne dass ein Neustart erforderlich ist.

Diese Architektur ermöglicht es Ihnen, Sling um programmspezifische Module zu erweitern. Sling, und daher CQ5, verwendet die Apache Felix-Implementierung von OSGI (Open Services Gateway Initiative) und basiert auf der OSGi Service Platform Release 4 Version 4.2. Beide sind Sammlungen von OSGi-Bundles, die in einem OSGi-Framework ausgeführt werden.

Auf diese Weise können Sie die folgenden Aktionen für beliebige Pakete innerhalb Ihrer Installation durchführen:

Weitere Informationen finden Sie unter Web-Konsole, OSGI-Konfiguration und OSGi-Konfigurationseinstellungen.

Entwicklungsobjekte in der AEM Umgebung development-objects-in-the-aem-environment

Folgendes ist für die Entwicklung von Interesse:

Element Ein Element ist entweder ein Knoten oder eine Eigenschaft.

Ausführliche Informationen zum Bearbeiten von Item-Objekten finden Sie in den Javadocs der Schnittstelle javax.jcr.Item

Knoten (und ihre Eigenschaften) Knoten und ihre Eigenschaften sind in der JCR API 2.0-Spezifikation (JSR 283) definiert. Sie speichern Inhalte, Objektdefinitionen, Rendering-Skripte und andere Daten.

Knoten definieren die Inhaltsstruktur und ihre Eigenschaften speichern den tatsächlichen Inhalt und die Metadaten.

Inhaltsknoten steuern das Rendering. Sling ruft den Inhaltsknoten von der eingehenden Anfrage ab. Die Eigenschaft sling:resourceType dieses Knotens verweist auf die zu verwendende Sling-Rendering-Komponente.

Ein Knoten, bei dem es sich um einen JCR-Namen handelt, wird auch als Ressource in der Sling-Umgebung bezeichnet.

Um beispielsweise die Eigenschaften des aktuellen Knotens abzurufen, können Sie folgenden Code in Ihrem Skript verwenden:

PropertyIterator properties = currentNode.getProperties();

Dabei ist currentNode das aktuelle Knotenobjekt.

Weitere Informationen zum Bearbeiten von Knotenobjekten finden Sie in den Javadocs.

Widget In AEM werden sämtliche Benutzereingaben von Widgets verwaltet. Diese werden häufig verwendet, um die Bearbeitung eines Inhaltselements zu steuern.

Dialogfelder werden durch die Kombination von Widgets erstellt.

AEM wurde mit der ExtJS-Bibliothek von Widgets entwickelt.

Dialog Ein Dialogfeld ist eine spezielle Art von Widget.

Um Inhalte zu bearbeiten, verwendet AEM Dialogfelder, die vom Anwendungsentwickler definiert wurden. Diese kombinieren eine Reihe von Widgets, um dem Benutzer alle Felder und Aktionen darzustellen, die zum Bearbeiten des zugehörigen Inhalts erforderlich sind.

Dialogfelder werden auch zur Bearbeitung von Metadaten und von verschiedenen Admin Tools verwendet.

Komponente Eine Softwarekomponente ist ein Systemelement, das einen vordefinierten Dienst oder ein vordefiniertes Ereignis bietet und in der Lage ist, mit anderen Komponenten zu kommunizieren.

Innerhalb von AEM wird häufig eine Komponente zum Rendern des Inhalts einer Ressource verwendet. Wenn es sich bei der Ressource um eine Seite handelt, wird die Komponente, die sie rendert, als Top-Level-Komponente oder als Seitenkomponente bezeichnet. Eine Komponente muss jedoch weder Inhalte rendern noch mit einer bestimmten Ressource verknüpft sein. Beispielsweise zeigt eine Navigationskomponente Informationen über mehrere Ressourcen an.

Die Definition einer Komponente umfasst:

Vorlage Eine Vorlage ist die Grundlage für einen bestimmten Seitentyp. Beim Erstellen einer Seite auf der Registerkarte „Websites“ muss der Benutzer eine Vorlage auswählen. Die neue Seite wird dann durch Kopieren dieser Vorlage erstellt.

Eine Vorlage ist eine Hierarchie von Knoten, die dieselbe Struktur wie die zu erstellende Seite aufweisen, jedoch keinen tatsächlichen Inhalt haben.

Sie definiert die Seitenkomponente, die zum Rendern der Seite verwendet wird, und den Standardinhalt (primären Top-Level-Inhalt). Der Inhalt definiert, wie er gerendert wird, da AEM inhaltsorientiert ist.

Seitenkomponente (Komponente auf oberster Ebene) Die Komponente, die zum Rendern der Seite verwendet werden soll.

Seite Eine Seite ist eine „Instanz“ einer Vorlage.

Eine Seite hat einen Hierarchieknoten vom Typ cq:Page und einen Inhaltsknoten vom Typ cq:PageContent. Die Eigenschaft sling:resourceType des Inhaltsknotens verweist auf die Seitenkomponente, die zum Rendern der Seite verwendet wird.

Um beispielsweise den Namen der aktuellen Seite abzurufen, können Sie folgenden Code in Ihrem Skript verwenden:

String pageName = currentPage.getName();

Dabei ist „currentPage“ das aktuelle Seitenobjekt. Weitere Informationen zum Bearbeiten von Seitenobjekten finden Sie in den Javadocs.

Seiten-Manager Der Seiten-Manager ist eine Schnittstelle, die Methoden für Vorgänge auf Seitenebene bereitstellt.

Um beispielsweise die übergeordnete Seite einer Ressource abzurufen, können Sie folgenden Code in Ihrem Skript verwenden:

Page myPage = pageManager.getContainingPage(myResource);

Dabei ist „pageManager“ das Seiten-Manager-Objekt und „myResource“ ein Ressourcenobjekt. Weitere Informationen zu den vom Seiten-Manager bereitgestellten Methoden finden Sie in den Javadocs.

Struktur innerhalb des Repositorys structure-within-the-repository

Die folgende Liste gibt einen Überblick über die Struktur, die Sie im Repository sehen.

Umgebungen environments

AEM eine Produktionsumgebung häufig aus zwei verschiedenen Instanztypen besteht: ein Autoren- und Veröffentlichungsinstanzen.

Der Dispatcher the-dispatcher

Der Dispatcher ist das Tool von Adobe für Caching und/oder Lastenausgleich. Weitere Informationen finden Sie unter den Dispatcher.

FileVault (Quellüberarbeitungssystem) filevault-source-revision-system

FileVault stellt Ihrem JCR-Repository Dateisystemzuordnung und Versionskontrolle zur Verfügung. Es kann verwendet werden, um AEM Entwicklungsprojekte mit voller Unterstützung für das Speichern und Versionieren von Projektcode, Inhalten, Konfigurationen usw. in standardmäßigen Versionskontrollsystemen (z. B. Subversion) zu verwalten.

Siehe FileVault-Tool Dokumentation für detaillierte Informationen.

Workflows workflows

Ihre Inhalte unterliegen oft organisatorischen Prozessen, einschließlich Schritten wie Genehmigung und Freigabe durch verschiedene Teilnehmer. Diese Prozesse können als Workflows dargestellt werden. in AEMund anschließend auf die geeignete Inhaltsseiten oder digitale Assets nach Bedarf.

Die Workflow-Engine wird verwendet, um die Implementierung Ihrer Workflows und deren anschließende Anwendung auf Ihren Inhalt zu verwalten.

Multi-Site-Management multi-site-management

Multi-Site-Manager (MSM) ermöglicht es Ihnen, mehrere Websites mit gemeinsamen Inhalten problemlos zu verwalten. Mit MSM können Sie Beziehungen zwischen den Sites definieren, sodass Inhaltsänderungen auf einer Site automatisch auf anderen Sites repliziert werden.

Zum Beispiel werden Websites oft in mehreren Sprachen für internationale Zielgruppen bereitgestellt. Wenn die Anzahl der Websites in derselben Sprache niedrig ist (drei bis fünf), ist ein manueller Prozess für die Synchronisierung von Inhalten über Seiten hinweg möglich. Sobald jedoch die Anzahl der Sites zunimmt oder mehrere Sprachen involviert sind, wird es effizienter, den Prozess zu automatisieren.

Weitere Informationen finden Sie unter Multi-Site-Manager.