AEM dispose d’une interface utilisateur tactile avec responsive design pour l’environnement de création conçu pour fonctionner sur les appareils tactiles et de bureau.
L’IU tactile est l’IU standard d’AEM. L’IU classique est devenue obsolète avec AEM 6.4.
L’interface utilisateur tactile se compose des éléments suivants :
Presque toutes les fonctionnalités d’AEM ont été adaptées à l’interface utilisateur tactile. Cependant, pour quelques fonctions, l’IU classique est rétablie. Pour plus d’informations, voir État des fonctionnalités de l’interface utilisateur tactile.
L’interface utilisateur tactile a été conçue par Adobe pour garantir une expérience utilisateur homogène entre plusieurs produits. Elle repose sur les éléments suivants :
Les principes de base dans l’IU tactile sont les suivants :
Pour une présentation plus détaillée de la structure de l’interface utilisateur tactile, reportez-vous à l’article Structure de l’interface utilisateur tactile d’AEM.
AEM utilise la plate-forme Granite qui inclut, entre autres, Java Content Repository.
Granite est la pile web ouverte d’Adobe. Elle fournit divers composants, parmi lesquels :
Granite est exécuté en tant que projet de développement ouvert dans Adobe : les contributions au code, les discussions et la résolution des problèmes proviennent de l’ensemble de l’entreprise.
Cependant, Granite n’est pas un projet Open Source. Il dépend très largement de plusieurs projets Open Source (Apache Sling, Felix, Jackrabbit et Lucene, en particulier), mais Adobe distingue clairement l’aspect public du contenu interne.
La plate-forme engineering de Granite fournit également une structure d’IU de base. Les principaux objectifs de cette plate-forme sont les suivants :
Ces objectifs sont conformes aux exigences suivantes :
GraniteUI.pdf
Obtenir le fichier
L’IU Granite :
La communication client-serveur au sein de l’IU Granite est constituée d’éléments hypertexte, et non d’objets. Il n’est donc pas nécessaire pour le client de comprendre la logique métier.
Dans ce cas, une extension du vocabulaire HTML est utilisée, de sorte que l’auteur puisse exprimer son intention de créer une application web interactive. Il s’agit d’une approche similaire à WAI-ARIA et microformats.
Il est essentiellement constitué d’un ensemble de schémas d’interaction (envoi d’un formulaire de manière asynchrone, par exemple) qui sont interprétés par des codes JS et CSS, et exécutés du côté client. Le rôle du côté client consiste à améliorer le balisage (fourni en tant que capacité hypermédia par le serveur) pour garantir l’interactivité.
Le côté client est indépendant de toute technologie serveur. Tant que le serveur fournit le balisage approprié, le côté client peut remplir son rôle.
Actuellement, les codes JS et CSS sont fournis en tant que clientlibs (bibliothèques clientes) Granite sous la catégorie suivante :
granite.ui.foundation and granite.ui.foundation.admin
Elles sont distribuées dans le cadre du module de contenu :
granite.ui.content
Il est formé par un ensemble de composants sling qui permettent à l’auteur de composer rapidement une application web. Le développeur élabore les composants et l’auteur les assemble pour former une application web. Le rôle du côté serveur consiste à attribuer la capacité hypermédia (balisage) au client.
Actuellement, les composants résident dans le référentiel Granite à l’adresse :
/libs/granite/ui/components/foundation
Il est distribué dans le cadre du module de contenu :
granite.ui.content
Il est aussi intéressant d’examiner les différences entre l’IU Granite et ExtJS (utilisé pour l’IU classique) :
ExtJS | IU Granite |
Appel de procédure à distance |
Transmissions de statuts |
Objets de transfert de données | Hypermédia |
Le client connaît les paramètres internes du serveur. | Le client ne connaît pas les informations internes. |
« Client lourd » | « Client léger » |
Bibliothèques clientes spécialisées | Bibliothèques client universelles |
Les composants de base de l’IU Granite fournissent les éléments nécessaires à la création d’une interface utilisateur. Ils comprennent, entre autres, les éléments suivants :
Les composants de base se trouvent à l’emplacement suivant :
/libs/granite/ui/components/foundation
Cette bibliothèque contient un composant IU Granite pour chaque élément Coral. Un composant est axé sur le contenu et sa configuration réside dans le référentiel. Cela permet de composer une application IU Granite sans écrire manuellement de balises HTML.
Objectif :
Mise en œuvre :
Cette bibliothèque de composants de base peut être utilisée ou étendue par d’autres bibliothèques.
Lors de la mise à niveau du code ExtJS afin d’utiliser l’IU Granite, la liste ci-dessous fournit un aperçu des types de nœud et xtypes ExtJS, accompagnés des types de ressources IU Granite équivalents.
ExtJS xtype | Type de ressource de l’IU Granite |
---|---|
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 |
Type de nœud | Type de ressource de l’IU Granite |
---|---|
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 |
Les composants d’administration de l’IU Granite dépendent des composants de base pour fournir les éléments génériques que toute application d’administration peut implémenter. Ils comprennent, entre autres, les éléments suivants :
Objectif :
Mise en œuvre :
CoralUI.pdf
Obtenir le fichier
L’interface utilisateur (IU) Coral est une implémentation du style visuel d’Adobe pour l’interface utilisateur tactile. Elle a été conçue par Adobe pour garantir une expérience utilisateur homogène entre plusieurs produits. Elle comprend tout ce dont vous avez besoin pour adopter le style visuel utilisé dans l’environnement de création.
L’IU Coral est une bibliothèque d’IU mise à la disposition des clients AEM pour créer des applications et des interfaces web dans les limites d’utilisation du produit définies par leur licence.
L’utilisation de l’IU Coral est autorisée uniquement dans les cas suivants :
Vous devez éviter d’utiliser l’IU Coral dans les cas suivants :
L’IU Coral est un ensemble de composantes de base destinées au développement d’applications web.
Conçu dès le début dans une optique de modularité, chaque module forme une couche distincte en fonction de son rôle principal. Bien que les couches aient été conçues pour une prise en charge mutuelle, elles peuvent, au besoin, être utilisées de manière indépendante. Cela permet d’implémenter l’expérience utilisateur de Coral dans n’importe quel environnement compatible HTML.
L’IU Coral n’exige pas l’utilisation d’un modèle, ni d’une plate-forme de développement spécifique. L’objectif principal de Coral est de fournir un balisage HTML5 net et unifié, indépendant de la méthode utilisée pour émettre les balises. Ce balisage peut être utilisé pour le rendu côté client ou serveur, les modèles, JSP, PHP ou encore les applications RIA Adobe Flash, pour ne citer que quelques exemples.
Les éléments HTML offrent une apparence commune pour tous les éléments d’interface de base (y compris la barre de navigation, les boutons, les menus, le rail, etc.).
Au niveau le plus bas, un élément HTML est une balise HTML avec un nom de classe dédié. Les éléments plus complexes peuvent être composés de plusieurs balises, imbriquées les unes dans les autres (d’une manière spécifique).
Le code CSS est utilisé pour définir l’apparence réelle. Pour qu’il soit possible de personnaliser facilement l’apparence (dans le cas d’une valorisation de marque, par exemple), les valeurs de style proprement dites sont déclarées en tant que variables qui sont étendues par le préprocesseur LESS lors de la phase d’exécution.
Objectif :
Mise en œuvre :
Par exemple, le balisage suivant :
<button class="btn btn-large btn-primary" type="button">Large button</button>
<button class="btn btn-large" type="button">Large button</button>
s’affiche sous la forme :
L’apparence est définie dans un fichier LESS et liée à un élément par un nom de classe dédié (l’extrait suivant a été raccourci dans un souci de concision) :
.btn {
font-size: @baseFontSize;
line-height: @baseLineHeight;
.buttonBackground(@btnBackground,
@btnBackgroundHighlight,
@grayDark, 0 1px 1px rgba(255,255,255,.75));
Les valeurs réelles sont définies dans un fichier de variables LESS (l’extrait suivant a été raccourci dans un souci de concision) :
@btnBackgroundHighlight: darken(@white, 10%);
@btnPrimaryBackgroundHighlight: spin(@btnPrimaryBackground, 20%);
@baseFontSize: 17px;
@baseFontFamily: @sansFontFamily;
Plusieurs des éléments HTML devront se comporter de façon dynamique ; en ouvrant et en fermant des menus contextuels, par exemple. Il s’agit du rôle des modules externes d’élément, qui exécutent ces tâches en manipulant le modèle DOM à l’aide de JavaScript.
Un module externe est soit :
DIV class=dialog
.DIV
ou LI
.Le comportement du module externe peut être personnalisé en utilisant l’une des méthodes suivantes :
data-*
dédiés liés au balisage HTMLBien que le développeur puisse choisir la méthode la mieux adaptée à chaque module externe, le principe de base consiste à utiliser les éléments suivants :
data-*
pour les options relatives à la mise en page HTML ; pour indiquer le nombre de colonnes, par exemple.Le même concept est utilisé pour implémenter la validation de formulaire. Pour un élément qui doit être validé, vous devez spécifier le formulaire de saisie requis sous la forme d’un attribut data-*
personnalisé. Cet attribut est ensuite utilisé comme option pour un module externe de validation.
La validation de formulaire native au format HTML5 doit être utilisée lorsque cela s’avère possible et/ou s’il y a une volonté de l’enrichir.
Objectif :
Mise en œuvre :
data-*
pour personnaliser le comportementExtrait de l’exemple de balisage (notez les options spécifiées sous la forme d’attributs data-*) :
<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>
Appel au module externe jQuery :
$(‘.cards’).cardlayout ();
Le résultat obtenu est le suivant :
Le module externe cardLayout
dispose les éléments UL
entre crochets sur leurs hauteurs respectives, en tenant également compte de la largeur du parent.
Un widget combine un ou plusieurs éléments de base avec un module externe JavaScript afin de former des éléments d’interface de « niveau supérieur ». Ils peuvent implémenter un comportement plus complexe, ainsi qu’une apparence plus complexe que celle présentée par un seul élément. Le sélecteur de balises et les widgets de rail constituent deux bons exemples.
Un widget peut se déclencher et écouter des événements personnalisés pour coopérer avec d’autres widgets sur la page. Certains widgets sont, en fait, des widgets jQuery natifs qui utilisent les éléments HTML Coral.
Objectif :
Mise en œuvre :
Voici un exemple de balisage :
<input type="text" name="tags" placeholder="Tags" class="tagManager"/>
Appel au module externe jQuery (avec options) :
$(".tagManager").tagsManager({
prefilled: ["Pisa", "Rome"] })
Le module externe émet des balises HTML (ce balisage utilise des éléments de base, lesquels peuvent, à leur tour, utiliser d’autres modules externes en interne) :
<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">
Le résultat obtenu est le suivant :
Cette bibliothèque rassemble des fonctions et/ou modules externes d’assistance JavaScript qui sont :
Il s’agit notamment de la gestion XSS et du bus d’événements.
Bien que les widgets et les modules externes d’éléments HTML puissent dépendre des fonctionnalités fournies par la bibliothèque Utility, cette dernière ne peut pas présenter de dépendance dure envers les éléments, ni envers les widgets proprement dits.
Objectif :
Mise en œuvre :