AEM bietet eine Touch-optimierte Benutzeroberfläche mit responsivem Design für die Autorenumgebung, die sowohl für Touch- als auch für Desktop-Geräte entwickelt wurde.
Die Touch-optimierte Benutzeroberfläche ist die standardmäßige Benutzeroberfläche von AEM. Die klassische Benutzeroberfläche ist seit AEM 6.4 veraltet.
Die Touch-optimierte Benutzeroberfläche umfasst Folgendes:
Nahezu für die gesamte AEM-Funktionalität wurde eine Portierung zur Touch-optimierten Benutzeroberfläche durchgeführt. In einigen wenigen Fällen wird aber die Funktionalität der klassischen Benutzeroberfläche genutzt. Weitere Informationen erhalten Sie unter Status der Funktionen der Touch-optimierten Benutzeroberfläche.
Die Touch-optimierte Benutzeroberfläche wurde von Adobe entworfen, um produktübergreifend die Einheitlichkeit des Anwendererlebnisses sicherzustellen. Sie basiert auf den folgenden Komponenten:
Die Grundprinzipien der Touch-optimierten Benutzeroberfläche lauten:
Einen weiteren Überblick über die Struktur der Touch-optimierten Benutzeroberfläche finden Sie im Artikel Struktur der Touch-optimierten Benutzeroberfläche von AEM.
Für AEM wird die Granite-Plattform als Basis genutzt. Sie enthält unter anderem das Java-Content-Repository.
Granite ist der Open-Web-Stapel von Adobe mit verschiedenen Komponenten, z. B.:
Granite wird als offenes Entwicklungsprojekt in Adobe ausgeführt: Beiträge zum Code, zu Diskussionen und zu Problemen kommen aus dem gesamten Unternehmen.
Granite ist aber kein Open-Source-Projekt. Es basiert in hohem Maße auf mehreren Open-Source-Projekten (vor allem Apache Sling, Felix, Jackrabbit und Lucene), aber Adobe achtet genau darauf, was öffentlich und was intern ist.
Mit der Granite-Engineering-Plattform wird auch ein UI-Framework als Grundlage bereitgestellt. Hiermit soll vor allem Folgendes erreicht werden:
Hierfür werden die folgenden Anforderungen erfüllt:
GraniteUI.pdf
Datei abrufen
Die Granite-Benutzeroberfläche:
Die Client/Server-Kommunikation der Granite-Benutzeroberfläche besteht aus Hypertext und nicht aus Objekten. Es ist also nicht erforderlich, dass der Client die Geschäftslogik versteht.
Hierfür wird eine Erweiterung des HTML-Vokabulars verwendet, die bereitgestellt wird, damit der Autor seine Absicht zur Erstellung einer interaktiven Web-App erklären kann. Dies ist ein ähnlicher Ansatz wie WAI-ARIA und Microformats.
Er umfasst hauptsächlich eine Sammlung mit Interaktionsmustern (z. B. asynchrone Übermittlung eines Formulars), die anhand von JS- und CSS-Code implementiert und auf Clientseite ausgeführt werden. Die Rolle der Clientseite besteht darin, das Markup zu erweitern (als Hypermedia-Affordanz des Servers bereitgestellt), um Interaktivität zu erzielen.
Die Clientseite ist unabhängig von der Servertechnologie. Solange der Server das entsprechende Markup bereitstellt, kann die Clientseite ihre Rolle erfüllen.
Derzeit wird der JS- und CSS-Code als Granite-clientlibs-Element unter der folgenden Kategorie bereitgestellt:
granite.ui.foundation and granite.ui.foundation.admin
Die Bereitstellung erfolgt im Rahmen des Inhaltspakets:
granite.ui.content
Besteht aus einer Sammlung von Sling-Komponenten, die dem Autor das schnelle Verfassen einer Web-App ermöglichen. Der Entwickler entwickelt Komponenten und der Autor stellt die Komponenten zu einer Web-App zusammen. Die Rolle der Serverseite besteht darin, die Hypermedia-Affordanz (Markup) für den Client bereitzustellen.
Derzeit befinden sich die Komponenten im Granite-Repository unter:
/libs/granite/ui/components/foundation
Dies wird als Teil des Inhaltspakets bereitgestellt:
granite.ui.content
Die Unterschiede zwischen der Granite-Benutzeroberfläche und ExtJS (für die klassische Benutzeroberfläche verwendet) sind ebenfalls interessant:
ExtJS | Granite-Benutzeroberfläche |
Remote-Prozessaufruf |
Statusübergänge |
Datenübertragungsobjekte | Hypermedia |
Client kennt die Server-Interna | Der Client kennt keine Interna |
„FAT-Client“ | „Thin-Client“ |
Spezialisierte Client-Bibliotheken | Universelle Client-Bibliotheken |
Mit den Granite-Benutzeroberflächen-Foundation-Komponenten werden die grundlegenden Bausteine bereitgestellt, die für die Erstellung einer Benutzeroberfläche benötigt werden. Dies sind beispielsweise:
Sie finden die Foundation-Komponenten unter:
/libs/granite/ui/components/foundation
Diese Bibliothek enthält eine Granite-Benutzeroberflächen-Komponente für jedes Coral-Element. Eine Komponente ist inhaltsorientiert und die zugehörige Konfiguration befindet sich im Repository. Dies ermöglicht die Erstellung einer Granite-Benutzeroberflächen-Anwendung, ohne dass manuell HTML-Markup geschrieben werden muss.
Zweck:
Implementierung:
Diese Bibliothek mit Foundation-Komponenten kann von anderen Bibliotheken verwendet oder erweitert werden.
Die folgende Liste enthält eine nützliche Übersicht über ExtJS-xtype- und -Knotentypen mit den entsprechenden Granite-Benutzeroberflächen-Ressourcentypen für die Aktualisierung von ExtJS-Code zur Verwendung der Granite-Benutzeroberfläche.
ExtJS xtype | Ressourcentyp der Granite-Benutzeroberfläche |
---|---|
button |
granite/ui/components/foundation/form/button |
checkbox |
granite/ui/components/foundation/form/checkbox |
componentstyles |
cq/gui/components/authoring/dialog/componentstyles |
cqinclude |
granite/ui/components/foundation/include |
datetime |
granite/ui/components/foundation/form/datepicker |
dialogfieldset |
granite/ui/components/foundation/form/fieldset |
hidden |
granite/ui/components/foundation/form/hidden |
html5smartfile, html5smartimage |
granite/ui/components/foundation/form/fileupload |
multifield |
granite/ui/components/foundation/form/multifield |
numberfield |
granite/ui/components/foundation/form/numberfield |
pathfield, paragraphreference |
granite/ui/components/foundation/form/pathbrowser |
selection |
granite/ui/components/foundation/form/select |
sizefield |
cq/gui/components/authoring/dialog/sizefield |
tags |
granite/ui/components/foundation/form/autocomplete``cq/gui/components/common/datasources/tags |
textarea |
granite/ui/components/foundation/form/textarea |
textfield |
granite/ui/components/foundation/form/textfield |
Knotentyp | Ressourcentyp der Granite-Benutzeroberfläche |
---|---|
cq:WidgetCollection |
granite/ui/components/foundation/container |
cq:TabPanel |
granite/ui/components/foundation/container``granite/ui/components/foundation/layouts/tabs |
cq:panel |
granite/ui/components/foundation/container |
Die Verwaltungskomponenten der Granite-Benutzeroberfläche stellen die Foundation-Komponenten für die Bereitstellung von generischen Bausteinen dar, die von allen Verwaltungsanwendungen implementiert werden können. Dies sind beispielsweise:
Zweck:
Implementierung:
CoralUI.pdf
Datei abrufen
Die Coral-Benutzeroberfläche (CUI) ist eine Implementierung des visuellen Stils von Adobe für die Touch-optimierte Benutzeroberfläche. Sie wurde entworfen, um produktübergreifend die Einheitlichkeit des Anwendererlebnisses sicherzustellen. Mit der Coral-Benutzeroberfläche werden alle Elemente bereitgestellt, die Sie zur Übernahme des visuellen Stils der Autorenumgebung benötigen.
Die Coral-Benutzeroberfläche ist eine Benutzeroberflächenbibliothek, die für AEM-Kunden erhältlich ist, um Anwendungen und Web-Oberflächen innerhalb der Lizenzgrenzen des Produkts zu erstellen.
Die Nutzung der Coral-Benutzeroberfläche ist nur unter folgenden Bedingungen bzw. für folgende Zwecke zulässig:
Die Nutzung der Coral-Benutzeroberfläche sollte in folgenden Fällen vermieden werden:
Die Coral-Benutzeroberfläche ist eine Sammlung von Bausteinen für die Entwicklung von Web-Anwendungen.
Sie ist vollständig modular konzipiert und jedes Modul stellt basierend auf seiner primäre Rolle eine eigene Ebene dar. Die Ebenen sind so konzipiert, dass sie sich gegenseitig unterstützen, aber sie können bei Bedarf auch unabhängig voneinander verwendet werden. Dies ermöglicht es, das Coral-Anwendererlebnis in allen HTML-fähigen Umgebungen zu implementieren.
Für die Coral-Benutzeroberfläche muss kein bestimmtes Entwicklungsmodell bzw. keine bestimmte Plattform verwendet werden. Hauptziel von Coral ist es, einheitlichen und sauberen HTML5-Markup-Code bereitzustellen, und zwar unabhängig von der eigentlichen Methode, die zum Ausgeben des Markup-Codes verwendet wird. Er kann für Client- oder Server-seitiges Rendering, Vorlagen, JSP, PHP oder auch Adobe Flash-RIA-Anwendungen verwendet werden, um nur einige zu nennen.
Über die HTML-Elemente wird ein einheitliches Erscheinungsbild für alle Basiselemente der Benutzeroberfläche (z. B. Navigationsleiste, Schaltfläche, Menü, Leiste usw.) erzielt.
Auf der einfachsten Ebene ist ein HTML-Element ein HTML-Tag mit einem dedizierten Klassennamen. Komplexere Elemente können aus mehreren Tags zusammengestellt werden, die ineinander geschachtelt sind (auf spezifische Weise).
Das CSS wird verwendet, um das eigentliche Erscheinungsbild bereitzustellen. Um eine einfache Anpassung des Erscheinungsbilds (z. B. für Branding-Fälle) zu ermöglichen, werden die Formatierungswerte als Variablen deklariert, die zur Laufzeit vom LESS-Prozessor vorab verarbeitet werden.
Zweck:
Implementierung:
Beispiel für verwendeten Markup-Code:
<button class="btn btn-large btn-primary" type="button">Large button</button>
<button class="btn btn-large" type="button">Large button</button>
Darstellung:
Das Erscheinungsbild wird in LESS definiert und es besteht eine Bindung an ein Element nach dem dedizierten Klassennamen (der folgende Auszug wurde gekürzt):
.btn {
font-size: @baseFontSize;
line-height: @baseLineHeight;
.buttonBackground(@btnBackground,
@btnBackgroundHighlight,
@grayDark, 0 1px 1px rgba(255,255,255,.75));
Die tatsächlichen Werte werden in einer LESS-Variablendatei definiert (der folgende Auszug wurde gekürzt):
@btnBackgroundHighlight: darken(@white, 10%);
@btnPrimaryBackgroundHighlight: spin(@btnPrimaryBackground, 20%);
@baseFontSize: 17px;
@baseFontFamily: @sansFontFamily;
Viele der HTML-Elemente müssen ein bestimmtes dynamisches Verhalten aufweisen, z. B. das Öffnen und Schließen von Popup-Menüs. Dies ist die Rolle der Element-Plug-ins, mit denen diese Aufgaben erreicht werden, indem das DOM per JavaScript geändert wird.
Für ein Plug-in gilt einer der folgenden Fälle:
DIV class=dialog
erwartet.DIV
- oder LI
-Elementen bereitgestellt.Das Plug-in-Verhalten kann auf folgende Arten mit Parametern angepasst werden:
data-*
-Attributen, die an den HTML-Markup-Code gebunden sindEntwickler können für jedes Plug-in den besten Ansatz wählen, aber die Faustregel lautet:
data-*
-Attribute für Optionen, die sich auf das HTML-Layout beziehen. Beispielsweise zum Angeben der Anzahl von Spalten.Dasselbe Konzept wird auch verwendet, um die Formularvalidierung zu implementieren. Für ein Element, das validiert werden soll, müssen Sie das erforderliche Eingabeformular als benutzerdefiniertes data-*
-Attribut angeben. Dieses Attribut wird dann als Option für ein Validierungs-Plug-in verwendet.
Die HTML5-native Formularvalidierung sollte nach Möglichkeit immer verwendet und erweitert werden.
Zweck:
Implementierung:
data-*
-Attributen zum Anpassen des VerhaltensEin Auszug aus Markup-Beispiel-Code (beachten Sie die als Daten-*-Attribute angegebenen Optionen):
<ul data-column-width="220" data-layout="card" class="cards">
<li class="item">
<div class="thumbnail">
<img href="/a.html" src="/a.thumb.319.319..png">
<div class="caption">
<h4>Toolbar</h4>
<p><small>toolbar</small><br></p>
</div>
</div>
</li>
<li class="item">
<div class="thumbnail">
<img href="/a.html" src="/a.thumb.319.319..png">
<div class="caption">
<h4>Toolbar</h4>
<p><small>toolbar</small><br></p>
</div>
</div>
</li>
Aufruf des jQuery-Plug-ins:
$(‘.cards’).cardlayout ();
Anzeige als:
Mit dem cardLayout
-Plug-in wird das Layout für die eingebundenen UL
-Elemente basierend auf der entsprechenden Höhe erstellt und außerdem wird die Breite des übergeordneten Elements berücksichtigt.
In einem Widget werden ein oder mehrere grundlegende Elemente mit einem JavaScript-Plug-in kombiniert, um UI-Elemente auf höherer Ebene zu erhalten. Hiermit können ein komplexeres Verhalten und außerdem ein komplexeres Erscheinungsbild als mit einem einzelnen Element implementiert werden. Gute Beispiele hierfür sind die Tag-Auswahl oder Leisten-Widgets.
Ein Widget kann benutzerdefinierte Ereignisse sowohl auslösen als auch darauf lauschen, um eine Kooperation mit anderen Widgets der Seite zu ermöglichen. Bei einigen Widgets handelt es sich eigentlich um native jQuery-Widgets, für die die Coral-HTML-Elemente verwendet werden.
Zweck:
Implementierung:
Beispiel-Markup:
<input type="text" name="tags" placeholder="Tags" class="tagManager"/>
Aufruf des jQuery-Plug-ins (mit Optionen):
$(".tagManager").tagsManager({
prefilled: ["Pisa", "Rome"] })
Das Plug-in gibt HTML-Markup aus (hierfür werden grundlegende Elemente verwendet, die ggf. intern andere Plug-ins nutzen):
<span>Pisa</code>
<a title="Removing tag" tagidtoremove="0"
id="myRemover_0" class="myTagRemover" href="#">x</a></code>
<span id="myTag_1" class="myTag"><span>Rome</code>
<a title="Removing tag" tagidtoremove="1"
id="myRemover_1" class="myTagRemover" href="#">x</a></code>
<input type="text" data-original-title="" class="input-medium tagManager"
placeholder="Tags" name="tags" data-provide="typeahead" data-items="6"
autocomplete="off">
Anzeige als:
Diese Bibliothek ist eine Sammlung mit JavaScript-Hilfs-Plug-ins bzw. -Funktionen, für die Folgendes gilt:
Hierzu gehören auch die XSS-Verarbeitung und der „Event Bus“.
Die HTML-Element-Plug-ins und -Widgets können zwar auf Funktionalität basieren, die über die Dienstprogrammbibliothek bereitgestellt wird, aber die Dienstprogrammbibliothek kann keine feste Abhängigkeit von den Elementen oder Widgets selbst aufweisen.
Zweck:
Implementierung: