Adobe Experience Manager (AEM) verfügt über eine Touch-optimierte Benutzeroberfläche mit responsives 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:
Fast alle AEM Funktionen wurden auf die Touch-optimierte Benutzeroberfläche portiert. In einigen wenigen Fällen wird die Funktionalität jedoch auf die klassische Benutzeroberfläche zurückgesetzt. Siehe Funktionsstatus der Touch-optimierten Benutzeroberfläche für weitere Informationen.
Die Touch-optimierte Benutzeroberfläche wurde von Adobe entwickelt, um die Konsistenz des Benutzererlebnisses über mehrere Produkte hinweg zu gewährleisten. Er basiert auf:
Die Grundprinzipien der Touch-optimierten Benutzeroberfläche sind:
Einen weiteren Überblick über die Struktur der Touch-optimierten Benutzeroberfläche finden Sie unter Struktur der AEM Touch-optimierten Benutzeroberfläche.
AEM verwendet die Granite-Plattform als Basis und die Granite-Plattform umfasst unter anderem das Java™ Content Repository.
Granite ist der Open-Web-Stack der Adobe und bietet verschiedene Komponenten wie:
Granite wird als offenes Entwicklungsprojekt in Adobe ausgeführt: Beiträge zum Code, Diskussionen und Themen werden aus dem gesamten Unternehmen übernommen.
Granite ist jedoch not ein Open-Source-Projekt. Es basiert in hohem Maße auf mehreren Open-Source-Projekten (insbesondere Apache Sling, Felix, Jackrabbit und Lucene), aber die Adobe zeichnet eine klare Linie zwischen dem, was öffentlich und intern ist.
Die Granite-Engineering-Plattform bietet außerdem ein Framework für die Foundation-Benutzeroberfläche. Die wichtigsten Ziele sind:
Diese erfüllen die Anforderungen:
GraniteUI.pdf
Datei abrufen
Die Granite-Benutzeroberfläche:
Die Client-Server-Kommunikation in der Granite-Benutzeroberfläche besteht aus Hypertext, nicht aus Objekten. Daher ist es nicht erforderlich, dass der Client die Geschäftslogik versteht
Dabei wird eine Erweiterung des HTML-Vokabulars verwendet, vorausgesetzt der Autor kann seine Absicht zum Erstellen einer interaktiven Webanwendung zum Ausdruck bringen. Dies ist ein ähnlicher Ansatz wie WAI-ARIA und Mikroformate.
Sie besteht in erster Linie aus einer Sammlung von Interaktionsmustern (z. B. asynchrones Senden eines Formulars), die von JS- und CSS-Codes interpretiert werden und clientseitig ausgeführt werden. Die Rolle der Client-Seite besteht darin, das Markup für Interaktivität zu verbessern (das vom Server als Hypermedia-Angebot angegeben wird).
Die Client-Seite ist unabhängig von jeder Server-Technologie. Solange der Server das entsprechende Markup bereitstellt, kann die Client-Seite seine Rolle erfüllen.
Derzeit werden die JS- und CSS-Codes als Granite bereitgestellt clientlibs unter der Kategorie:
granite.ui.foundation and granite.ui.foundation.admin
Die Bereitstellung erfolgt im Rahmen des Inhaltspakets:
granite.ui.content
Dies wird durch eine Sammlung von Sling-Komponenten gebildet, die es dem Autor ermöglichen, zusammensetzen eine schnelle Webapp. Der Entwickler entwickelt Komponenten, der Autor stellt die Komponenten zu einer Webanwendung zusammen. Die Rolle der Server-Seite besteht darin, dem Client das Hypermedia-Angebot (Markup) zu geben.
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 |
Staatliche Ü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 |
Die Foundation-Komponenten der Granite-Benutzeroberfläche stellen die grundlegenden Bausteine bereit, die zum Erstellen einer beliebigen Benutzeroberfläche erforderlich sind. Dazu gehören unter anderem:
Die Foundation-Komponenten finden Sie unter:
/libs/granite/ui/components/foundation
Diese Bibliothek enthält eine Granite-UI-Komponente für jedes Coral-Element. Eine Komponente ist inhaltsgesteuert, wobei sich ihre Konfiguration im Repository befindet. 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.
Bei der Aktualisierung von ExtJS-Code zur Verwendung der Granite-Benutzeroberfläche bietet die folgende Liste einen praktischen Überblick über ExtJS-xtypes und Knotentypen mit den entsprechenden Granite-UI-Ressourcentypen.
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 auf den Foundation-Komponenten aufbauen, um allgemeine Bausteine bereitzustellen, die von jeder Administration-Anwendung implementiert werden können. Dazu gehören unter anderem:
Zweck:
Implementierung:
CoralUI.pdf
Datei abrufen
Die Coral-Benutzeroberfläche (CUI) ist eine Implementierung des visuellen Stils der Adobe für die Touch-optimierte Benutzeroberfläche, die eine konsistente Benutzererfahrung über mehrere Produkte hinweg bietet. Die Coral-Benutzeroberfläche bietet alles, was Sie benötigen, um den visuellen Stil der Authoring-Umgebung zu übernehmen.
Die Coral-Benutzeroberfläche ist eine UI-Bibliothek, die AEM Kunden zum Erstellen von Anwendungen und Webschnittstellen innerhalb der Grenzen ihrer lizenzierten Nutzung des Produkts zur Verfügung gestellt wird.
Die Nutzung der Coral-Benutzeroberfläche ist nur unter folgenden Bedingungen bzw. für folgende Zwecke zulässig:
Die Verwendung 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. Obwohl die Ebenen so konzipiert wurden, dass sie sich gegenseitig unterstützen, können sie bei Bedarf auch unabhängig voneinander verwendet werden. Dies ermöglicht die Implementierung des Coral-Benutzererlebnisses in jeder HTML-fähigen Umgebung.
In der Coral-Benutzeroberfläche ist es nicht erforderlich, ein bestimmtes Entwicklungsmodell und/oder eine bestimmte Plattform zu verwenden. Hauptziel von Coral ist die Bereitstellung eines einheitlichen und sauberen HTML5-Markups, unabhängig von der eigentlichen Methode, mit der dieses Markup ausgegeben 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.
Die HTML-Elemente bieten ein einheitliches Erscheinungsbild für alle Elemente der grundlegenden Benutzeroberfläche (einschließlich Navigationsleiste, Schaltfläche, Menü, Leiste usw.).
Grundsätzlich 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 das Erscheinungsbild einfach anzupassen (z. B. beim Branding), werden tatsächliche Stilwerte als Variablen deklariert, die durch die WENIGER Präprozessor während der Laufzeit.
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 HTML-Elemente müssen eine gewisse Dynamik aufweisen, z. B. das Öffnen und Schließen von Popup-Menüs. Dies ist die Rolle der Element-Plug-ins, die solche Aufgaben durch Manipulation des DOM mit JavaScript ausführen.
Ein Plug-in ist entweder:
DIV class=dialog
erwartet.DIV
- oder LI
-Elementen bereitgestellt.Das Plug-in-Verhalten kann mit Parametern angepasst werden, indem Sie:
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. So legen Sie beispielsweise die Anzahl der Spalten festDasselbe Konzept wird für die Implementierung der Formularüberprüfung verwendet. 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 ();
Dies zeigt Folgendes:
Die cardLayout
-Plug-in legt die im UL
-Elemente basierend auf ihren jeweiligen Höhen und unter Berücksichtigung der Breite des Elternteils.
Ein Widget kombiniert ein oder mehrere grundlegende Elemente mit einem JavaScript-Plug-in, um UI-Elemente auf "höherer Ebene"zu bilden. Dadurch können komplexere Verhaltensweisen sowie ein komplexeres Erscheinungsbild implementiert werden, als ein einzelnes Element liefern könnte. 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. Einige Widgets sind native jQuery-Widgets, die die Coral-HTML-Elemente verwenden.
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 (dieses Markup verwendet grundlegende Elemente, die intern andere Plug-ins verwenden können):
<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">
Dies zeigt Folgendes:
Diese Bibliothek ist eine Sammlung von JavaScript-Helper-Plug-ins und/oder Funktionen, die:
Dazu gehören die XSS-Handhabung und der Ereignisbus.
Die HTML-Element-Plug-ins und Widgets können zwar auf Funktionen der Dienstprogrammbibliothek beruhen, die Dienstprogrammbibliothek kann jedoch keine feste Abhängigkeit von den Elementen und Widgets selbst aufweisen.
Zweck:
Implementierung: