Entwickeln von AEM-Komponenten developing-aem-components
AEM-Komponenten werden verwendet, um den Inhalt, den Sie auf Ihren Web-Seiten bereitstellen, zu speichern, zu formatieren und zu rendern.
-
Beim Erstellen von Seiten erlauben es die Komponenten den Autoren, den Inhalt zu bearbeiten und zu konfigurieren.
-
Beim Erstellen einer Commerce-Site können die Komponenten beispielsweise Informationen aus dem Katalog sammeln und rendern.
Weitere Informationen finden Sie unter Entwicklung von eCommerce.
-
Wenn Sie eine Communities-Site erstellen, können die Komponenten Informationen für Ihre Besucher bereitstellen und Informationen erfassen.
Weitere Informationen finden Sie unter Entwicklung von Communities.
-
-
Auf der Veröffentlichungsinstanz rendern die Komponenten Ihren Inhalt und stellen ihn Ihren Besuchern wie gewünscht dar.
/libs/cq/gui/components/authoring/dialog
stehende Komponenten sollen nur im Editor (Komponentendialogfelder beim Schreiben) verwendet werden. Wenn sie an anderer Stelle verwendet werden (z. B. in einem Assistenten-Dialogfeld), verhalten sie sich möglicherweise nicht wie erwartet.Codebeispiele code-samples
Diese Seite enthält die Referenzdokumentation (oder Links zur Referenzdokumentation) die für die Entwicklung neuer Komponenten für AEM erforderlich sind. Einige praktische Beispiele finden Sie unter Entwickeln von AEM-Komponenten - Codebeispiele.
Struktur structure
Die grundlegende Struktur einer Komponente wird auf der Seite AEM Komponenten - Grundlagen beschrieben. Dieses Dokument gilt sowohl für die Touch-optimierte als auch für die klassische Benutzeroberfläche. Auch wenn Sie die klassischen Einstellungen in Ihrer neuen Komponente nicht verwenden müssen, kann es hilfreich sein, sie beim Erben von vorhandenen Komponenten zu beachten.
Erweitern vorhandener Komponenten und Dialogfelder extending-existing-components-and-dialogs
Je nach der Komponente, die Sie implementieren möchten, kann es möglich sein, eine vorhandene Instanz zu erweitern oder anzupassen, anstatt die gesamte structure von Grund auf neu.
Beim Erweitern oder Anpassen einer vorhandenen Komponente oder eines vorhandenen Dialogfelds können Sie entweder die gesamte Struktur oder die für das Dialogfeld erforderliche Struktur kopieren oder replizieren, bevor Sie Ihre Änderungen vornehmen.
Erweitern einer vorhandenen Komponente extending-an-existing-component
Die Erweiterung einer vorhandenen Komponente kann mit Ressourcentyphierarchie und die zugehörigen Vererbungsmechanismen.
/apps
muss die gesamte Überlagerung definieren.Anpassen eines Dialogfelds "Vorhandene Komponente" customizing-a-existing-component-dialog
Es ist auch möglich, ein Komponentendialogfeld mithilfe des Sling Resource Mergers zu überschreiben und die Eigenschaft sling:resourceSuperType
zu definieren.
Dies bedeutet, dass Sie nur die erforderlichen Unterschiede neu definieren müssen, anstatt das gesamte Dialogfeld neu zu definieren (mit sling:resourceSuperType
). Diese Methode wird jetzt zum Erweitern eines Komponentendialogfelds empfohlen
Siehe Sling Resource Merger für weitere Details.
Markup definieren defining-the-markup
Ihre Komponente wird mit HTML gerendert. Ihre Komponente muss den HTML-Code definieren, der erforderlich ist, um den erforderlichen Inhalt zu übernehmen und anschließend in der Autoren- und Veröffentlichungsumgebung nach Bedarf zu rendern.
Verwenden der HTML-Vorlagensprache using-the-html-template-language
Die HTML Vorlagensprache (HTL), die mit AEM 6.0 eingeführt wurde, löst JSP (JavaServer Pages) als bevorzugtes und empfohlenes serverseitiges Vorlagensystem für HTML ab. Für Webentwickler, die robuste Unternehmenswebsites erstellen müssen, hilft HTL bei der Verbesserung von Sicherheit und Entwicklungseffizienz.
Entwickeln der Inhaltslogik developing-the-content-logic
Diese optionale Logik wählt und/oder berechnet den Inhalt, der gerendert werden soll. Sie wird aus HTL-Ausdrücken mit dem entsprechenden Anwendungs-API-Muster aufgerufen.
Der Mechanismus zum Trennen der Logik von der Erscheinung hilft zu verdeutlichen, was für eine gegebene Sicht aufgerufen wird. Es ermöglicht auch eine unterschiedliche Logik für verschiedene Ansichten derselben Ressource.
Verwendung von Java using-java
Mit der Java-Anwendungs-API von HTL kann eine HTL-Datei auf Hilfsmethoden in einer benutzerdefinierten Java-Klasse zugreifen.Dies ermöglicht es Ihnen, Java-Code zu verwenden, um die Logik zum Auswählen und Konfigurieren des Komponenteninhalts zu implementieren.
Verwenden von JavaScript using-javascript
Die HTL JavaScript Use-API ermöglicht es einer HTL-Datei, auf den in JavaScript geschriebenen Hilfscode zuzugreifen. Dies ermöglicht es Ihnen, JavaScript-Code zu verwenden, um die Logik zum Auswählen und Konfigurieren des Komponenteninhalts zu implementieren.
Verwendung Client-seitiger HTML-Bibliotheken using-client-side-html-libraries
Moderne Websites beruhen in hohem Maße auf der Client-seitigen Verarbeitung durch einen komplexen JavaScript- und CSS-Code. Die Organisation und Optimierung der Bereitstellung dieses Codes kann äußerst kompliziert sein.
Um Abhilfe zu schaffen, stellt AEM Client-seitige Bibliotheksordner zur Verfügung, mit denen Sie Ihren Client-seitigen Code im Repository speichern, in Kategorien gruppieren und definieren können, wann und wie jede Codekategorie dem Client bereitgestellt werden soll. Das Client-seitige Bibliotheksystem übernimmt dann das Herstellen der richtigen Links auf der endgültigen Webseite, um den korrekten Code zu laden.
Lesen Sie Verwendung Client-seitiger HTML-Bibliotheken für weitere Informationen.
Konfigurieren des Bearbeitungsverhaltens configuring-the-edit-behavior
Sie können das Bearbeitungsverhalten einer Komponente konfigurieren, einschließlich Attributen wie Aktionen, die für die Komponente verfügbar sind, Eigenschaften des Editors für die Bearbeitung im Kontext, die sich auf Ereignisse für die Komponente beziehen. Die Konfiguration ist sowohl für die Touch-optimierte als auch für die klassische Benutzeroberfläche üblich, allerdings mit bestimmten, spezifischen Unterschieden.
Um das Bearbeitungsverhalten einer Komponente zu konfigurieren, fügen Sie einen cq:editConfig
-Knoten des Typs cq:EditConfig
unter dem Komponentenknoten (des Typs cq:Component
) hinzu sowie spezifische Eigenschaften und untergeordnete Knoten.
Konfigurieren des Vorschauverhaltens configuring-the-preview-behavior
Der WCM-Modus-Cookie wird beim Wechsel in den Vorschaumodus gesetzt, auch wenn die Seite nicht aktualisiert wird.
Komponenten mit einem Rendering, die für den WCM-Modus empfindlich sind, müssen so definiert werden, dass sie sich selbst aktualisieren und sich dann auf den Wert des Cookies verlassen.
EDIT
und PREVIEW
für den WCM-Modus-Cookie verwendet.Erstellen und Konfigurieren eines Dialogfelds creating-and-configuring-a-dialog
Dialogfelder werden verwendet, um dem Autor die Interaktion mit der Komponente zu ermöglichen. Mit einem Dialogfeld können Autorinnen und Autoren und/oder Admins Inhalte bearbeiten, die Komponente konfigurieren oder Design-Parameter definieren (mit einem Design-Dialogfeld)
Coral- und Granite-Benutzeroberfläche coral-ui-and-granite-ui
Coral-Benutzeroberfläche und Granite-Benutzeroberfläche definieren das moderne Erscheinungsbild von AEM.
Die Granite-Benutzeroberfläche bietet einen großen Bereich der grundlegenden Komponenten (Widgets), die zum Erstellen Ihres Dialogfelds in der Autorenumgebung benötigt werden. Falls erforderlich, können Sie diese Auswahl erweitern und Ihr eigenes Widget erstellen.
Ausführliche Informationen finden Sie unter:
-
Coral-Benutzeroberfläche
- Bietet eine konsistente Benutzeroberfläche für alle Cloud-Lösungen
- Konzepte der Touch-optimierten Benutzeroberfläche von AEM - Coral-Benutzeroberfläche
- Coral-Benutzeroberfläche - Handbuch
-
Granite-Benutzeroberfläche
- Bietet Markup der Coral-Benutzeroberfläche in Sling-Komponenten zum Erstellen von UI-Konsolen und -Dialogfeldern
- Konzepte der Touch-optimierten Benutzeroberfläche von AEM - Granite-Benutzeroberfläche
- Dokumentation zur Granite-Benutzeroberfläche
Erstellen eines neuen Dialogfelds creating-a-new-dialog
Dialogfelder für die Touch-optimierte Benutzeroberfläche:
-
haben den Namen
cq:dialog
. -
sind als Knoten
nt:unstructured
mit der Eigenschaftsling:resourceType
definiert. -
befinden sich unter ihrem Knoten
cq:Component
und neben ihrer Komponentendefinition. -
werden auf der Serverseite (als Sling-Komponenten) basierend auf ihrer Inhaltsstruktur und der Eigenschaft
sling:resourceType
gerendert. -
Verwenden Sie das Granite-UI-Framework.
-
enthalten eine Knotenstruktur, die die Felder im Dialogfeld beschreibt.
- Diese Knoten sind
nt:unstructured
mit der erforderlichen Eigenschaftsling:resourceType
.
- Diese Knoten sind
Eine Beispielknotenstruktur könnte wie folgt aussehen:
newComponent (cq:Component)
cq:dialog (nt:unstructured)
content
layout
items
column
items
file
description
Das Anpassen eines Dialogfelds ähnelt der Entwicklung einer Komponente, da das Dialogfeld selbst eine Komponente ist (z. B. Markup, das von einem Komponentenskript zusammen mit dem von einer Client-Bibliothek bereitgestellten Verhalten/Stil gerendert wird).
Beispiele finden Sie hier:
/libs/foundation/components/text/cq:dialog
/libs/foundation/components/download/cq:dialog
Anpassen von Dialogfeldern customizing-dialog-fields
- AEM-Gems-Session zum Anpassen von Dialogfeldern.
- Der zugehörige Beispiel-Code wird unter Codebeispiel – So passen Sie Dialogfelder an behandelt.
Erstellen eines neuen Felds creating-a-new-field
Widgets für die Touch-optimierte Benutzeroberfläche werden als Granite-UI-Komponenten implementiert.
Um ein neues Widget zur Verwendung in einem Komponentendialogfeld für die Touch-optimierte Benutzeroberfläche zu erstellen, müssen Sie Erstellen einer neuen Granite-UI-Feldkomponente.
Wenn Sie das Dialogfeld für einen einfachen Container für ein Formularelement halten, können Sie den Primärinhalt Ihres Dialogfeldinhalts als auch Formularfelder sehen. Um ein neues Formularfeld zu erstellen, müssen Sie einen Ressourcentyp erstellen. Dies entspricht dem Erstellen einer neuen Komponente. Um Ihnen bei dieser Aufgabe zu helfen, bietet die Granite-Benutzeroberfläche eine generische Feldkomponente, von der eine Vererbung möglich ist (mithilfe von sling:resourceSuperType
):
/libs/granite/ui/components/coral/foundation/form/field
Genauer gesagt bietet die Granite-Benutzeroberfläche eine Reihe von Feldkomponenten, die für die Verwendung in Dialogfeldern (oder allgemein in Formularen) geeignet sind.
cq:Widgets
-Knoten mit jeweils einem bestimmten xtype
repräsentiert werden, um die Beziehung zum entsprechenden ExtJS-Widget herzustellen. Aus Sicht der Implementierung wurden diese Widgets auf der Client-Seite von ExtJS-Framewrrk gerendert.Sobald Sie Ihren Ressourcentyp erstellt haben, können Sie Ihr Feld instanziieren, indem Sie in Ihrem Dialogfeld einen neuen Knoten hinzufügen, wobei die Eigenschaft sling:resourceType
auf den Ressourcentyp verweist, den Sie gerade eingeführt haben.
Erstellen einer Client-Bibliothek für Stil und Verhalten creating-a-client-library-for-style-and-behavior
Wenn Sie Stil und Verhalten für Ihre Komponente definieren möchten, können Sie eine dedizierte Client-Bibliothek , das Ihre benutzerdefinierte CSS/LESS- und JS-Datei definiert.
Damit Ihre Client-Bibliothek ausschließlich für Ihr Komponentendialogfeld geladen wird (d. h. sie wird nicht für eine andere Komponente geladen), müssen Sie die -Eigenschaft festlegen extraClientlibs
des Dialogfelds zum Kategorienamen der zuvor erstellten Client-Bibliothek. Dies empfiehlt sich, wenn die Client-Bibliothek recht groß ist und/oder das Feld für dieses Dialogfeld spezifisch ist und nicht in anderen Dialogfeldern benötigt wird.
Um die Client-Bibliothek für alle Dialogfelder zu laden, legen Sie die Kategorieeigenschaft Ihrer Client-Bibliothek auf cq.authoring.dialog
fest. Dies ist der Kategoriename der Client-Bibliothek, die beim Rendern aller Dialogfelder standardmäßig enthalten ist. Dies empfiehlt sich, wenn die Client-Bibliothek klein ist und/oder Ihr Feld allgemein ist und in anderen Dialogfeldern wiederverwendet werden kann.
Ein Beispiel finden Sie unter:
-
cqgems/customizingfield/components/colorpicker/clientlibs
- gegeben durch das Code-Beispiel
Erweitern (Vererben von) eines Felds extending-inheriting-from-a-field
Je nach Ihren Anforderungen haben Sie folgende Möglichkeiten:
- Ein gegebenes Granite-Benutzeroberflächenfeld um Komponentenvererbung (
sling:resourceSuperType
) erweitern - Erweitern Sie ein bestimmtes Widget aus der zugrunde liegenden Widget-Bibliothek (im Fall der Granite-Benutzeroberfläche ist dies die Coral-Benutzeroberfläche), indem Sie der Widget-Bibliotheks-API (JS-/CSS-Vererbung) folgen.
Zugriff auf Dialogfelder access-to-dialog-fields
Sie können auch Render-Bedingungen (rendercondition
) verwenden, um festzulegen, wer Zugriff auf bestimmte Registerkarten/Felder in Ihrem Dialogfeld hat. Beispielsweise:
+ mybutton
- sling:resourceType = granite/ui/components/coral/foundation/button
+ rendercondition
- sling:resourceType = myapp/components/renderconditions/group
- groups = ["administrators"]
Umgang mit Feldereignissen handling-field-events
Die Methode zur Behandlung von Ereignissen in Dialogfeldern wird jetzt mit Listenern in einer benutzerdefinierten Client-Bibliothek ausgeführt. Dies ist eine Änderung gegenüber der älteren Methode, Listener in der Inhaltsstruktur.
Listener in einer benutzerdefinierten Client-Bibliothek listeners-in-a-custom-client-library
Um Logik in Ihr Feld zu injizieren, sollten Sie Folgendes beachten:
- Lassen Sie Ihr Feld mit einer bestimmten CSS-Klasse markiert (die Hook).
- Definieren Sie in Ihrer Client-Bibliothek einen JS-Listener, der auf diesen CSS-Klassennamen basiert (dadurch wird sichergestellt, dass Ihre benutzerdefinierte Logik nur auf Ihr Feld angewendet wird und keine anderen Felder desselben Typs betroffen sind).
Um dies zu erreichen, müssen Sie die zugrunde liegende Widget-Bibliothek kennen, mit der Sie interagieren möchten. Informationen darüber, auf welches Ereignis Sie reagieren möchten, finden Sie in der Dokumentation zur Coral-Benutzeroberfläche. Dies ähnelt dem Prozess, den Sie in der Vergangenheit mit ExtJS durchführen mussten: Suchen Sie die Dokumentationsseite eines bestimmten Widgets und überprüfen Sie dann die Details seiner Ereignis-API.
Ein Beispiel finden Sie unter:
-
cqgems/customizingfield/components/clientlibs/customizingfield
- gegeben durch das Code-Beispiel
Listener in der Inhaltsstruktur listeners-in-the-content-structure
In der klassischen Benutzeroberfläche mit ExtJS war es üblich, Listener für ein bestimmtes Widget in der Inhaltsstruktur zu haben. Dasselbe in der Touch-optimierten Benutzeroberfläche zu erreichen ist anders, als der JS-Listener-Code (oder jeglicher Code) im Inhalt nicht mehr definiert ist.
Die Inhaltsstruktur beschreibt die semantische Struktur. Sie sollte (muss) nicht die Art des zugrunde liegenden Widget implizieren. Wenn Sie keinen JS-Code in der Inhaltsstruktur haben, können Sie die Implementierungsdetails ändern, ohne die Inhaltsstruktur ändern zu müssen. Mit anderen Worten: Sie können die Widget-Bibliothek ändern, ohne die Inhaltsstruktur zu berühren.
Erkennen der Verfügbarkeit des Dialogfelds dialog-ready
Wenn Sie über ein benutzerdefiniertes JavaScript verfügen, das nur ausgeführt werden muss, wenn das Dialogfeld verfügbar und bereit ist, sollten Sie auf das dialog-ready
-Ereignis achten.
Dieses Ereignis wird ausgelöst, wenn das Dialogfeld geladen (oder erneut geladen) wird und einsatzbereit ist, d. h., wenn eine Änderung (Erstellen/Aktualisieren) im DOM des Dialogfelds erfolgt.
dialog-ready
kann verwendet werden, um in JavaScript benutzerdefinierten Code einzubinden, der Anpassungen an den Feldern in einem Dialogfeld oder ähnliche Aufgaben durchführt.
Feldüberprüfung field-validation
Obligatorisches Feld mandatory-field
Um ein bestimmtes Feld als Pflichtfeld zu markieren, legen Sie die folgende Eigenschaft im Inhaltsknoten Ihres Felds fest:
- Name:
required
- Typ:
Boolean
Ein Beispiel finden Sie unter:
/libs/foundation/components/page/cq:dialog/content/items/tabs/items/basic/items/column/items/title/items/title
Feldvalidierung (Granite-Benutzeroberfläche) field-validation-granite-ui
Die Feldüberprüfung in der Granite-Benutzeroberfläche und den Granite-Benutzeroberflächenkomponenten (entspricht Widgets) erfolgt mithilfe der API foundation-validation
. Weitere Informationen finden Sie in der foundation-valdiation
Granite-Dokumentation.
Beispiele finden Sie hier:
-
cqgems/customizingfield/components/clientlibs/customizingfield/js/validations.js
- im Abschnitt Codebeispiel
-
/libs/cq/gui/components/authoring/dialog/clientlibs/dialog/js/validations.js
Erstellen und Konfigurieren eines Design-Dialogfelds creating-and-configuring-a-design-dialog
Das Design-Dialogfeld wird bereitgestellt, wenn eine Komponente Entwurfsdetails enthält, die im Entwurfsmodus bearbeitet werden können.
Die Definition ist der eines Dialogfelds sehr ähnlich, das für die Bearbeitung von Inhalten verwendet wird, mit dem Unterschied, dass es als Knoten definiert ist:
- Knotenname:
cq:design_dialog
- Typ:
nt:unstructured
Erstellen und Konfigurieren eines Editors für Bearbeitung im Kontext creating-and-configuring-an-inplace-editor
Ein Editor für die Bearbeitung im Kontext ermöglicht es dem Benutzer, Inhalte direkt im Absatzfluss zu bearbeiten, ohne dass ein Dialogfeld geöffnet werden muss. Beispielsweise verfügen die Standardkomponenten Text und Titel über einen Editor für die Bearbeitung im Kontext.
Ein Editor für die Bearbeitung im Kontext ist nicht für jeden Komponententyp erforderlich/sinnvoll.
Siehe Erweitern der Seitenbearbeitung - Hinzufügen eines neuen Editors für die Bearbeitung im Kontext für weitere Informationen.
Anpassen der Komponentensymbolleiste customizing-the-component-toolbar
Die Komponentensymbolleiste bietet dem Benutzer Zugriff auf eine Reihe von Aktionen für die Komponente, z. B. Bearbeiten, Konfigurieren, Kopieren und Löschen.
Siehe Erweitern der Seitenbearbeitung - Hinzufügen einer neuen Aktion zur Komponentensymbolleiste für weitere Informationen.
Konfigurieren einer Komponente für die Verweisleiste (geliehen/verliehen) configuring-a-component-for-the-references-rail-borrowed-lent
Wenn Ihre neue Komponente auf Inhalte von anderen Seiten verweist, können Sie überlegen, ob sich dies auf die Geliehener Inhalt und Geliehener Inhalt der Verweise Leiste.
Die Standardinstallation von AEM überprüft nur die Referenzkomponente. Um Ihre Komponente hinzuzufügen, müssen Sie die Referenzkonfiguration für das OSGi-Bundle WCM Authoring Content konfigurieren.
Erstellen Sie einen neuen Eintrag in der Definition und geben Sie Ihre Komponente zusammen mit der zu überprüfenden Eigenschaft an. Beispiel:
/apps/<your-Project>/components/reference@parentPath
Aktivieren und Hinzufügen Ihrer Komponente zum Absatzsystem enabling-and-adding-your-component-to-the-paragraph-system
Nachdem die Komponente entwickelt wurde, muss sie für die Verwendung in einem geeigneten Absatzsystem aktiviert werden, damit sie auf den erforderlichen Seiten verwendet werden kann.
Dies kann folgendermaßen erfolgen:
- using Designmodus beim Bearbeiten einer bestimmten Seite.
- Definieren der Komponenten -Eigenschaft im Absatzsystem einer Vorlage.
Konfigurieren eines Absatzsystems, sodass beim Ziehen eines Assets eine Komponenteninstanz erstellt wird configuring-a-paragraph-system-so-that-dragging-an-asset-creates-a-component-instance
AEM bietet die Möglichkeit, ein Absatzsystem auf Ihrer Seite so zu konfigurieren, dass Eine Instanz der neuen Komponente wird automatisch erstellt, wenn ein Benutzer ein (geeignetes) Asset auf eine Instanz dieser Seite zieht (anstatt immer eine leere Komponente auf die Seite ziehen zu müssen).
Dieses Verhalten und die erforderliche Beziehung zwischen Asset und Komponente können konfiguriert werden:
-
Unter der Absatzdefinition Ihres Seitendesigns. Beispiel:
/etc/designs/<myApp>/page/par
Erstellen Sie einen neuen Knoten:
- Name:
cq:authoring
- Typ:
nt:unstructured
-
Erstellen Sie unter diesem einen neuen Knoten, der alle Zuordnungen zwischen Asset und Komponente enthält:
- Name:
assetToComponentMapping
- Typ:
nt:unstructured
- Name:
-
Erstellen Sie für jede Zuordnung zwischen Asset und Komponente einen Knoten:
- Name: Text, es wird empfohlen, dass der Name des Assets und den zugehörigen Komponententyp angibt; zum Beispiel, Bild
- Typ:
nt:unstructured
Jeweils mit den folgenden Eigenschaften:
-
assetGroup
:- Typ:
String
- Wert: die Gruppe, zu der das zugehörige Asset gehört; zum Beispiel
media
- Typ:
-
assetMimetype
:- Typ:
String
- Wert: der mime-Typ des zugehörigen Assets; zum Beispiel
image/*
- Typ:
-
droptarget
:- Typ:
String
- Wert: das Ablageziel; zum Beispiel,
image
- Typ:
-
resourceType
:- Typ:
String
- Wert: die zugehörige Komponentenressource; zum Beispiel
foundation/components/image
- Typ:
-
type
:- Typ:
String
- Wert: der Typ, z. B.
Images
- Typ:
Beispiele finden Sie unter:
/etc/designs/geometrixx/jcr:content/page/par/cq:authoring
/etc/designs/geometrixx-outdoors/jcr:content/page/par/cq:authoring
/etc/designs/geometrixx-media/jcr:content/article/article-content-par/cq:authoring
CODE FÜR GITHUB
Den Code dieser Seite finden Sie auf GitHub.
- Öffnen Sie das Projekt aem-project-archetype in GitHub
- Laden Sie das Projekt als ZIP-Datei herunter.
Verwenden von AEM Brackets-Erweiterungen using-the-aem-brackets-extension
Die AEM Brackets-Erweiterung bietet einen reibungslosen Workflow zum Bearbeiten AEM Komponenten und Client-Bibliotheken. Sie basiert auf der Brackets Code-Editor.
Die -Erweiterung:
- Erleichtert die Synchronisierung (kein Maven oder File Vault erforderlich), um die Effizienz der Entwickler zu erhöhen, und hilft Frontend-Entwicklern mit begrenztem AEM-Wissen, an Projekten teilzunehmen.
- Bietet HTL-Unterstützung, die Vorlagensprache, die entwickelt wurde, um die Komponentenentwicklung zu vereinfachen und die Sicherheit zu erhöhen.
Migration von einer klassischen Komponente migrating-from-a-classic-component
Wenn Sie eine Komponente, die für die Verwendung mit der klassischen Benutzeroberfläche konzipiert wurde, zu einer Komponente migrieren, die mit der Touch-optimierten Benutzeroberfläche (einzeln oder gemeinsam) verwendet werden kann, sollten die folgenden Probleme berücksichtigt werden:
-
HTL
- Die Verwendung von HTL ist nicht obligatorisch, aber wenn Ihre Komponente aktualisiert werden muss, ist es ein idealer Zeitpunkt, eine Migration von JSP zu HTL in Betracht zu ziehen.
-
Komponenten
- Migrieren Sie
cq:listener
-Code, der klassische benutzeroberflächespezifische Funktionen verwendet - RTE-Plug-in, für weitere Informationen siehe Konfigurieren des Rich-Text-Editors.
- Migrieren Sie
cq:listener
-Code, der Funktionen verwendet, die für die klassische Benutzeroberfläche spezifisch sind
- Migrieren Sie
-
Dialogfelder
- Sie müssen ein neues Dialogfeld zur Verwendung in der Touch-optimierten Benutzeroberfläche erstellen. Aus Kompatibilitätsgründen kann die Touch-optimierte Benutzeroberfläche jedoch die Definition eines Dialogfelds der klassischen Benutzeroberfläche verwenden, wenn für die Touch-optimierte Benutzeroberfläche kein Dialogfeld definiert wurde.
- Die AEM Modernisierungs-Tools wird bereitgestellt, um Sie beim Erweitern vorhandener Komponenten zu unterstützen.
- Das Zuordnen von ExtJS zu Granite-UI-Komponenten bietet einen praktischen Überblick über ExtJS-Xtypes und Knotentypen mit ihren entsprechenden Ressourcentypen in der Granite-Benutzeroberfläche.
- Anpassen von Feldern. Weitere Informationen finden Sie in der Sitzung AEM Gems unter Anpassen von Dialogfeldern.
- Migrieren von Typen zu Validierung der Granite-Benutzeroberfläche
- Verwenden von JS-Listenern finden Sie weitere Informationen unter Umgang mit Feldereignissen und der Sitzung AEM Gems Anpassen von Dialogfeldern.
Migrieren von cq:listener-Code migrating-cq-listener-code
Wenn Sie ein Projekt migrieren, das für die klassische Benutzeroberfläche konzipiert wurde, verwendet der cq:listener
-Code (und komponentenbezogene Client-Bibliotheken) möglicherweise Funktionen, die für die klassische Benutzeroberfläche spezifisch sind (z. B. CQ.wcm.*
). Für die Migration müssen Sie diesen Code mithilfe der entsprechenden Objekte/Funktionen in der Touch-optimierten Benutzeroberfläche aktualisieren.
Wenn Ihr Projekt vollständig in die Touch-optimierte Benutzeroberfläche migriert wird, müssen Sie diesen Code ersetzen, um die Objekte und Funktionen zu verwenden, die für die Touch-optimierte Benutzeroberfläche relevant sind.
Wenn Ihr Projekt während des Migrationszeitraums jedoch sowohl für die klassische als auch für die Touch-optimierte Benutzeroberfläche berücksichtigt werden muss (das übliche Szenario), müssen Sie einen Schalter implementieren, um den separaten Code zu unterscheiden, der auf die entsprechenden Objekte verweist.
Dieser Switch-Mechanismus kann wie folgt implementiert werden:
if (Granite.author) {
// touch UI
} else {
// classic UI
}
Dokumentation der Komponente documenting-your-component
Als Entwickler möchten Sie einfachen Zugriff auf die Komponentendokumentation, damit Sie Folgendes schnell verstehen können:
- Beschreibung
- Beabsichtigter Verwendungszweck
- Inhaltstruktur und Eigenschaften
- Ausgesetzte APIs und Erweiterungspunkte
- usw.
Aus diesem Grund ist es sehr einfach, einen vorhandenen Dokumentations-Markdown innerhalb der Komponente selbst vorzunehmen.
Sie müssen lediglich eine README.md
-Datei in der Komponentenstruktur platzieren. Dieser Markdown wird dann in der Komponentenkonsole angezeigt.
Der unterstützte Markdown ist derselbe wie der für Inhaltsfragmente.