Show Menu
THEMEN×

Entwickeln von AEM-Komponenten

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.
This page is a continuation of the document AEM Components - The Basics .
Components below /libs/cq/gui/components/authoring/dialog are meant to be used only in the Editor (component dialogs in Authoring). Wenn sie an anderer Stelle verwendet werden (z. B. in einem Assistentendialogfeld), verhalten sie sich möglicherweise nicht wie erwartet.

Codebeispiele

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

Die grundlegende Struktur einer Komponente wird auf der Seite AEM Komponenten - Grundlagen beschrieben. Dieses Dokument behandelt sowohl die touchfähigen als auch die klassischen Benutzeroberflächen. 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.

Erweiterung bestehender Komponenten und Dialogfelder

Abhängig von der Komponente, die Sie implementieren möchten, könnte es möglich sein, eine vorhandene Instanz zu erweitern oder anzupassen, anstatt die gesamte Struktur von Grund auf neu zu definieren und zu entwickeln.
Wenn Sie eine vorhandene Komponente oder ein bestehendes Dialogfeld erweitern oder anpassen, 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

Das Erweitern einer vorhandenen Komponente kann mit der Ressourcentyphierarchie und den zugehörigen Vererbungsmechanismen erreicht werden.
Komponenten können mit einer Überlagerung ebenfalls neu definiert werden, die auf der Suchpfadlogik basiert. However in such case, the Sling Resource Merger will not be triggered and /apps must define the entire overlay.
Die Inhaltsfragmentkomponente kann auch angepasst und erweitert werden, obwohl die vollständige Struktur und die Beziehungen zu Assets berücksichtigt werden müssen.

Anpassen eines vorhandenen Komponentendialogfelds

Es ist auch möglich, ein Komponentendialogfeld mithilfe des Sling Resource Mergers zu überschreiben und die Eigenschaft sling:resourceSuperType zu definieren.
This means you only need to redefine the required differences, as opposed to redefining the entire dialog (using sling:resourceSuperType ). Dies ist jetzt die empfohlene Methode für die Erweiterung eines Komponentendialogfelds
Siehe Sling Resource Merger für weitere Informationen.

Definieren von 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

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. Webentwicklern, die robuste Unternehmenswebsites erstellen müssen, hilft HTL, eine höhere Sicherheit und Entwicklungseffizienz zu erreichen.
Obwohl sowohl HTL als auch JSP zur Entwicklung von Komponenten verwendet werden können, zeigen wir auf dieser Seite die Entwicklung mit HTL, da dies die empfohlene Skriptsprache für AEM ist.

Entwicklung der Inhaltslogik

Diese optionale Logik wählt und/oder berechnet den Inhalt, der gerendert werden soll. Sie wird aus HTL-Ausdrücken mit dem entsprechenden Gebrauch-API Muster aufgerufen.
Der Mechanismus zum Trennen der Logik von der Erscheinung hilft zu verdeutlichen, was für eine gegebene Sicht aufgerufen wird. Er erlaubt auch unterschiedliche Logik für verschiedene Ansichten derselben Quelle.

Verwendung von 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

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 clientseitiger HTML-Bibliotheken

Moderne Websites beruhen in hohem Maße auf der clientseitigen Verarbeitung durch einen komplexen JavaScript- und CSS-Code. Die Organisation und Optimierung der Bereitstellung dieses Codes kann äußerst kompliziert sein.
To help deal with this issue, AEM provides Client-side Library Folders , which allow you to store your client-side code in the repository, organize it into categories and define when and how each category of code is to be served to the client. Das clientseitige Bibliotheksystem übernimmt dann das Herstellen der richtigen Links auf der endgültigen Webseite, um den korrekten Code zu laden.
Lesen Sie Verwendung clientseitiger HTML-Bibliotheken für weitere Informationen.

Konfigurieren des Bearbeitungsverhaltens

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 gilt dabei für die Touch-optimierte wie die klassische Benutzeroberfläche, wenn auch mit gewissen Unterschieden.
The edit behavior of a component is configured by adding a cq:editConfig node of type cq:EditConfig below the component node (of type cq:Component ) and by adding specific properties and child nodes.

Konfigurieren des Vorschauverhaltens

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.
In the touch-enabeld UI only the values EDIT and PREVIEW are used for the WCM Mode cookie.

Erstellen und Konfigurieren eines Dialogfelds

Dialogfelder werden verwendet, um dem Autor die Interaktion mit der Komponente zu ermöglichen. Using a dialog allows authors and/or administrators to edit content, configure the component or define design parameters (using a Design Dialog )

Coral- und Granite-Benutzeroberfläche

Die Coral-Benutzeroberfläche und die 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 .
Weitere Informationen zum Entwickeln von Komponenten mit Coral- und Granite-Ressourcentypen finden Sie unter: Erstellen von Experience Manager-Komponenten mit Coral/Granite-Ressourcentypen .
Ausführliche Informationen finden Sie hier:
Aufgrund der Art der Granite-Benutzeroberflächenkomponenten (und der Unterschiede zu den ExtJS-Widgets) gibt es einige Unterschiede zwischen der Interaktion zwischen Komponenten mit der Touch-optimierten Benutzeroberfläche und der klassischen Benutzeroberfläche .

Erstellen eines neuen Dialogfelds

Dialogfelder für die Touch-optimierte Benutzeroberfläche:
  • are named cq:dialog .
  • are defined as an nt:unstructured node with the sling:resourceType property set.
  • 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 das Framework der Granite-Benutzeroberfläche.
  • enthalten eine Knotenstruktur, die die Felder im Dialogfeld beschreibt.
    • these nodes are nt:unstructured with the required sling:resourceType property.
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 unter:
  • /libs/foundation/components/text/cq:dialog
  • /libs/foundation/components/download/cq:dialog
Wenn für eine Komponente kein Dialogfeld für die Touch-optimierte Benutzeroberfläche definiert wurde, wird das Dialogfeld für die klassische Benutzeroberfläche als Rückfall innerhalb einer Kompatibilitätsebene verwendet. Um ein solches Dialogfeld anzupassen, müssen Sie das Dialogfeld für die klassische Benutzeroberfläche anpassen. Siehe AEM-Komponenten für die klassische Benutzeroberfläche .

Anpassen von Dialogfeldern

Siehe:

Erstellen eines neuen Felds

Widgets für die Touch-optimierte Benutzeroberfläche sind als Granite-Benutzeroberflächenkomponenten implementiert.
Um ein neues Widget zur Verwendung in einem Komponentendialogfeld für die Touch-optimierte Benutzeroberfläche zu erstellen, müssen Sie eine neue-Granite Benutzeroberflächenfeldkomponente erstellen .
Vollständige Informationen zur Granite-Benutzeroberfläche finden Sie in der Dokumentation zur Granite-Benutzeroberfläche .
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.
Dies unterscheidet sich von der klassischen Benutzeroberfläche, bei der Widgets durch 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

Wenn Sie Stile und Verhalten für Ihre Komponente definieren möchten, können Sie eine dedizierte Client-Bibliothek erstellen, die Ihre benutzerdefinierten CSS/LESS- und JS-Einstellungen definiert.
To have your client library loaded solely for your component dialog (i.e. it will not be loaded for another component) you need to set the property extraClientlibs ** **of your dialog to the category name of the client library you have just created. 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 Ihre Client-Bibliothek klein und/oder Ihr Feld generisch ist und in anderen Dialogfeldern wiederverwendet werden kann.
Ein Beispiel finden Sie unter:
  • cqgems/customizingfield/components/colorpicker/clientlibs

Erweiterung eines Felds (Vererbung)

Abhängig von Ihren Anforderungen können Sie entweder:
  • Ein gegebenes Granite-Benutzeroberflächenfeld um Komponentenvererbung ( sling:resourceSuperType ) erweitern
  • Ein bestimmtes Widget aus der zugrunde liegenden Widget-Bibliothek (im Falle der Granite-Benutzeroberfläche ist dies die Coral-Benutzeroberfläche) erweitern, indem Sie der Widget-Bibliothek-API folgen (JS/CSS-Vererbung)

Zugriff auf Dialogfelder

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"]

Handhabung von Feldereignissen

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 zu haben.

Listener in einer benutzerdefinierten Client-Bibliothek

Um Logik in Ihr Feld zu injizieren, sollten Sie Folgendes beachten:
  1. Lassen Sie Ihr Feld mit einer bestimmten CSS-Klasse (dem Hook ) markieren.
  2. Definieren Sie in Ihrer Client-Bibliothek einen JS-Listener, der mit diesem CSS-Klassennamen verknüpft ist (dadurch wird sichergestellt, dass Ihre benutzerdefinierte Logik nur für Ihr Feld gilt und andere Felder desselben Typs nicht 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 ist dem Prozess sehr ähnlich, 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 Event-API.
Ein Beispiel finden Sie unter:
  • cqgems/customizingfield/components/clientlibs/customizingfield

Listener in der Inhaltsstruktur

In der klassischen Benutzeroberfläche mit ExtJS war es üblich, Listener für ein bestimmtes Widget in der Inhaltsstruktur zu haben. Das Gleiche gilt für die Touch-optimierte Benutzeroberfläche, da der JS-Listenercode (oder überhaupt kein Code) nicht mehr im Inhalt 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.

Feldüberprüfung

Pflichtfeld

Um ein bestimmtes Feld als obligatorisch zu kennzeichnen, legen Sie die folgende Eigenschaft für den 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

Feldüberprüfung (Granite-Benutzeroberfläche)

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
Beispiele finden Sie unter:
  • cqgems/customizingfield/components/clientlibs/customizingfield/js/validations.js
  • /libs/cq/gui/components/authoring/dialog/clientlibs/dialog/js/validations.js

Erstellen und Konfigurieren eines Design-Dialogfelds

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:
  • Node name: cq:design_dialog
  • Typ: nt:unstructured

Erstellen und Konfigurieren eines Editors für die Bearbeitung im Kontext

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. Zum Beispiel haben die Standardkomponenten Text und Titel beide einen Editor für die Bearbeitung im Kontext.
Ein Editor für die Bearbeitung im Kontext ist nicht für jeden Komponententyp notwendig/sinnvoll.

Anpassen der Komponentensymbolleiste

Die Komponentensymbolleiste bietet dem Benutzer Zugriff auf eine Reihe von Aktionen für die Komponente, z. B. Bearbeiten, Konfigurieren, Kopieren und Löschen.

Konfigurieren einer Komponente für die Verweisleiste (geliehen/verliehen)

Wenn Ihre neue Komponente auf Inhalte anderer Seiten verweist, können Sie sich überlegen, ob sie Auswirkungen auf die Abschnitte Geliehener Inhalt und Verliehener Inhalt der **Verweisleiste ** haben soll.
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
Bei der Arbeit mit AEM gibt es verschiedene Methoden, die Konfigurationseinstellungen für solche Dienste zu verwalten. Weitere Informationen und empfohlene Vorgehensweisen finden Sie unter Konfigurieren von OSGi .

Aktivieren und Hinzufügen Ihrer Komponente zum Absatzsystem

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 erfolgen durch:

Konfigurieren eines Absatzsystems, sodass beim Ziehen eines Assets eine Komponenteninstanz erstellt wird

AEM bietet die Möglichkeit, ein Absatzsystem auf Ihrer Seite zu konfigurieren, sodass eine Instanz Ihrer neuen Komponente automatisch erstellt wird, 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:
  1. Unter der Absatzdefinition Ihres Seitendesigns. Beispiel:
    • /etc/designs/<myApp>/page/par Erstellen Sie einen neuen Knoten:
    • Name: cq:authoring
    • Typ: nt:unstructured
  2. Erstellen Sie unter diesem einen neuen Knoten, der alle Zuordnungen zwischen Asset und Komponente enthält:
    • Name: assetToComponentMapping
    • Typ: nt:unstructured
  3. 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
      • Value: the group that the related asset belongs to; for example, media
    • assetMimetype :
      • Typ: String
      • Wert: der mime-Typ des zugehörigen Assets; zum Beispiel image/*
    • droptarget :
      • Typ: String
      • Value: the drop target; for example, image
    • resourceType :
      • Typ: String
      • Value: the related component resource; for example, foundation/components/image
    • type :
      • Typ: String
      • Value: the type, for example, Images
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 AUF GITHUB
Den Code dieser Seite finden Sie auf GitHub
The automatic creation of component instances can now be configured easily within the UI when using Core Components and Editable Templates. See Creating Page Templates for more information about defining which components are automatically associated with given media types.

Verwenden von AEM Brackets-Erweiterungen

Die AEM Brackets-Erweiterung bietet einen reibungslosen Arbeitsablauf, um AEM-Komponenten und Client-Bibliotheken zu bearbeiten. Sie basiert auf dem Code-Editor Brackets .
Die Erweiterung:
  • Erleichtert die Synchronisierung (kein Maven oder File Vault erforderlich), um die Effizienz der Entwickler zu erhöhen, und hilft Front-End-Entwicklern mit begrenztem AEM-Wissen, an Projekten teilzunehmen.
  • Provides some HTL support, the template language designed to simplify component development and increase security.
Brackets ist die empfohlene Vorgehensweise zum Erstellen von Komponenten. Es ersetzt die CRXDE Lite-Funktion „Komponente erstellen“, die für die klassische Benutzeroberfläche entwickelt wurde.

Migration von einer klassischen Komponente

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
  • Dialogfelder

Migrieren von cq:listener-Code

If you are migrating a project that was designed for the classic UI, then the cq:listener code (and component related clientlibs) might use functions that are specific to the classic UI (such as 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 auf die Touch-optimierte Benutzeroberfläche migriert wird, müssen Sie diesen Code ersetzen, um die für die Touch-optimierte Benutzeroberfläche relevanten Objekte und Funktionen zu verwenden.
Wenn Ihr Projekt jedoch während des Migrationszeitraums sowohl die klassische Benutzeroberfläche als auch die Touch-optimierte Benutzeroberfläche bedienen muss (das übliche Szenario), müssen Sie einen Schalter implementieren, um den separaten Code zu unterscheiden, der auf die entsprechenden Objekte verweist.
Dieser Schaltmechanismus kann implementiert werden als:
if (Granite.author) {
    // touch UI
} else {
    // classic UI
}

Dokumentation Ihrer Komponente

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.
The supported markdown is the same as that for content fragments .