Tutoriel sur la construction d'applications Eclipse RCP basées sur Eclipse 4

Eclipse 4 introduit un ensemble de technologies visant à faciliter le développement de plug-ins. La version simultanée d'Eclipse dénommée Juno, sortie en juin 2012 a été basée sur Eclipse 4.2.

Eclipse 3.8 est sortie en même temps qu'Eclipse 4.2, mais la série Eclipse 3.x sera suspendue après la version 3.8, autrement dit il n'y aura pas de version 3.9. Eclipse 3.8 recevra des correctifs durant une année avec des versions révisées (service release).

Eclipse 4 a été l'opportunité de rationaliser le meilleur de l'API l'Eclipse 3.x et de fixer les insuffisances de développement d'Eclipse 3.x. Durant l'évolution d'Eclipse 3.x de sa version 3.0 à 3.8, de rudes expériences ont été vécues sur les difficultés et le manque de flexibilité de l'API.

Les développeurs d'Eclipse 3.x trouvent que la plupart des concepts qu'ils connaissent sont retransmis et on les retrouve dans Eclipse 4.

Les améliorations majeures d'Eclipse 4 par rapport à Eclipse 3.x sont les suivantes :

• l'application Eclipse est décrite par une structure bien définie appelée modèle d'application ;
• le modèle d'application peut être modifié durant le développement ou en cours d'exécution ;
• le modèle d'application est extensible ;
• Eclipse 4 supporte l'injection de dépendances ;
• les Widgets Eclipse peuvent être stylés par le biais de fichiers CSS externes, à la manière de ce qui se fait avec les pages Web  ;
• le modèle d'application est dissocié de son apparence, par exemple, différentes bibliothèques graphiques telles que SWT ou JavaFX, peuvent être utilisées pour le rendu du modèle.

Eclipse 4 fournit une couche de compatibilité qui permet aux plug-ins d'Eclipse 3.x de fonctionner sans qu'ils soient modifiés.

Les améliorations introduites par Eclipse 4 sont principalement concentrées sur le développement basé sur Eclipse. L'utilisateur d'Eclipse en tant qu'IDE, par exemple un développeur web ou Swing, ne profite qu'indirectement de ces améliorations, vu la simplicité avec laquelle s'écrivent les plugins et les outils Eclipse. Cela permet aux développeurs Eclipse de créer de meilleurs outils destinés aux utilisateurs de IDE.

Le projet de la plate-forme Eclipse fournit le cadre de base et les services sur lesquels se fondent toutes applications basées sur Eclipse. Il fournit également l'environnement d'exécution dans lequel les composants Eclipse sont chargés, intégrés et exécutés.

L'objectif principal du projet de la plate-forme est de permettre à d'autres développeurs de créer facilement des applications et des outils intégrés.

Eclipse e4 est le nom donné pour le projet d'incubateur de la plate-forme Eclipse. Celui-ci est utilisé pour des projets préparatoires relatifs à l'amélioration de la plate-forme. La nouvelle plate-forme Eclipse 4 a été développée à l'origine au sein de l'incubateur et le nom de l'incubateur est devenu synonyme de la nouvelle plate-forme Eclipse. Aujourd'hui, le terme e4 n'est que le nom du projet.

Le projet e4 comprend plusieurs évaluations de technologie. Certaines d'entre elles ont été portées vers le Framework de base d'Eclipse. Toutes les fonctionnalités décrites dans ce tutoriel font partie de la version officielle d'Eclipse 4 à l'exception du projet Eclipse e4 tooling.

Le sous-projet Eclipse e4 tooling fournit des outils de développement d'applications Eclipse 4. Ils sont très utiles, mais ils n'ont pas été ajoutés à la version finale d'Eclipse, car ils ne sont pas aussi accomplis que les autres composants.

Des projets tels que XWT, TM ou OpenSocial Gadgets, qui font également partie du projet e4 d'Eclipse, ne sont pas inclus dans la plate-forme de base standard d'Eclipse 4.2 et ne sont pas décrits dans le présent document.

Actuellement, l'interface de programmation d'application (APIApplication programming interface) pour Eclipse 4 est encore marquée comme provisoire, c'est-à-dire, que l'API peut être amenée à être modifiée à l'avenir.

Eclipse 4.2 gère déjà l'IDE Eclipse au complet, donc il est peu probable que des changements importants surviennent à l'avenir.

Il est donc relativement sûr de commencer à utiliser l'API dès maintenant, mais néanmoins vous devez être préparé à l'éventualité de faire quelques ajustements à vos applications.

Une application Eclipse est constituée de composants logiciels individuels. L'IDE Eclipse peut être considéré comme une application Eclipse spéciale destinée à supporter le développement de logiciels.

Les composantes de l'IDE Eclipse sont principalement les suivantes. Veuillez noter que le graphique ne représente que le concept, les relations ne sont pas d'une précision à 100 %.

OSGi est une spécification qui décrit une approche modulaire pour les applications Java. Equinox est une implémentation de l'OSGi et elle est utilisée par la plate-forme Eclipse. L'environnement d'exécution Equinox fournit l'environnement nécessaire pour exécuter une application Eclipse modulaire.

SWT est la bibliothèque de composants d'interface utilisateur standard utilisée par Eclipse. JFace fournit des API pratiques plus avancées qui s'appuient sur SWT. Le Workbench fournit le cadre pour l'application. Le Workbench est responsable de l'affichage des autres composants de l'interface utilisateur.

En plus de ces éléments de base, l'IDE Eclipse ajoute des composants qui sont aussi importants pour l'IDE, par exemple les outils de développement Java (JDTJava development tools) ou le support de contrôle de version (EGIT).

Eclipse 4 dispose d'un modèle de programmation différent de celui d'Eclipse 3.x. Eclipse 4 fournit une couche de compatibilité 3.x qui se charge de mapper l'API 3.x à l'API 4.0. Ceci permet aux composants basés sur Eclipse 3.x de s'exécuter sans modification sur Eclipse 4.

Les applications basées sur Eclipse qui ne sont pas essentiellement destinées à être utilisées comme outils de développement de logiciels sont appelées applications Eclipse RCP. Une application Eclipse 4 RCP utilise généralement les composants de base de la plate-forme Eclipse auxquels s'additionnent des composants supplémentaires spécifiques à l'application.

Le modèle de programmation d'OSGiOpen Services Gateway initiative (Equinox) vous permet de définir des composants logiciels dynamiques, à savoir les services OSGiOpen Services Gateway initiative, qui peuvent aussi faire partie d'une application basée sur Eclipse.

Une application Eclipse est constituée de plusieurs composants Eclipse. Un composant logiciel Eclipse est appelé un plug-in. Un composant logiciel dans OSGiOpen Services Gateway initiative est appelé un bundle. Les deux termes peuvent être utilisés indifféremment.

Ce tutoriel utilise les termes « application basée sur Eclipse », « application Eclipse », « application Eclipse 4 » et « application Eclipse RCP » indifféremment pour faire référence à une application qui est basée sur le Framework Eclipse 4.

Si un certain concept se réfère à Eclipse 3.x, il sera explicitement indiqué.

Un Plug-in Eclipse dispose des principaux fichiers de configuration suivants :

• MANIFEST.MF : contient les informations de configuration OSGiOpen Services Gateway initiative ;
• plugin.xml : contient des informations sur les mécanismes des extensions spécifiques d'Eclipse.

Un plug-in Eclipse définit son API à travers le fichier MANIFEST.MF, par exemple, les packages Java qui peuvent être utilisés par d'autres plug-ins et de leurs dépendances, par exemple les packages ou les plug-ins qui sont requis par le plug-in.

Le fichier plugin.xml offre la possibilité de définir les points d'extension et les extensions. Les points d'extension définissent les interfaces pour d'autres plug-ins afin de contribuer aux fonctionnalités. Les extensions contribuent aux fonctionnalités de ces interfaces. Ces fonctionnalités peuvent être du code et non basées sur du code.

Dans Eclipse 4, l'utilisation des extensions et des points d'extension est très limitée. Ils sont principalement utilisés pour définir des indications vers d'autres fichiers de configuration Eclipse 4.

Ce qui suit suppose que vous avez installé la version 1.6 de Java au minimum.

La description dans ce tutoriel est basée sur Eclipse version 4.3. Téléchargez la dernière version officielle d'Eclipse SDK disponible à partir du lien suivant.

Eclipse Project 4.x Stream DownloadsEclipse Project 4.x Stream Downloads

Le téléchargement est un fichier zip, qui est une archive compressée de plusieurs fichiers. La plupart des systèmes d'exploitation peuvent extraire les fichiers zip, dans leur gestionnaire de fichiers. Par exemple, si vous utilisez Windows 7 comme système d'exploitation, clic droit sur le fichier dans l'explorateur et sélectionner « extraire tout … » dans le menu contextuel. Si vous hésitez sur la façon de décompresser, recherchez dans Google comment décompresser un fichier sur … , En remplaçant « … » avec votre système d'exploitation.

Ne décompressez pas Eclipse dans un dossier avec un chemin qui contient des espaces, car cela pourrait entraîner des problèmes dans le fonctionnement d'Eclipse.

Après avoir extrait le fichier zip, double-cliquez sur eclipse.exe sous Windows ou le fichier eclipse sous Linux (ou l'icône de l'exécutable spécifique à votre plate-forme) pour lancer Eclipse.

Afin d'éviter tout conflit avec le travail existant, sélectionnez un répertoire vide comme workspace pour ce tutoriel.

Le téléchargement d'Eclipse SDK n'inclut pas le e4 tooling d'Eclipse, qui permet de créer des applications Eclipse 4 plus facilement. Ces outils fournissent des assistants pour créer des artefacts Eclipse 4 et l'éditeur spécialisé pour le modèle d'application.

L'auteur de ce document fournit une version récente des outils e4 pour l'Eclipse version 4.3 sous l'URL suivante.

http://download.vogella.com/kepler/e4tools

Vous pouvez installer les outils par le biais du menu Help ? Install New Software et en entrant l'URL ci-dessus.

Le site de mise à jour ci-dessus a été créé pour garantir un lien stable pour le lecteur de ce tutoriel. La même base de code est utilisée par Eclipse.org pour créer un site de mise à jour officiel pour Eclipse e4 tools.

Malheureusement, le lien de ce site de mise à jour change de temps en temps, mais il peut être trouvé sur le site suivant :

Eclipse.org e4tools siteEclipse.org e4tools site

Si vous cliquez sur une version « Build Name », vous trouverez également le lien du site de mise à jour. Les captures d'écran suivantes illustrent le cas d'un build particulier d'e4 tools. Veuillez noter que le site pourrait changer au fil du temps.

Le projet d'Eclipse 4 tooling fournit un assistant de génération de projet qui vous permet de créer une application RCP opérationnelle basée sur Eclipse 4.

Sélectionnez  File ? New ? Others ? Eclipse 4 ? Eclipse 4 Application Project 

Créez un projet nommé com.example.e4.rcp.wizard en utilisant les paramètres par défaut. Cela devrait être similaire aux captures d'écran suivantes.

Sélectionnez les options « Enable development mode for application model » et « Create sample content » dans la dernière page de l'assistant. L'option mode de développement ajoute la propriété clearPersistedState au fichier de configuration du product, pour s'assurer que les changements opérés dans la structure de votre application en phase de développement soient toujours visibles à l'exécution. Avec l'option « Create sample content », vous définissez si une application Eclipse RCP minimale doit être générée ou si certains éléments supplémentaires devraient être ajoutés à celle-ci, comme une vue avec du contenu à titre d'exemple.

L'assistant crée tous les fichiers nécessaires pour exécuter votre application. Le fichier essentiel pour lancer votre application est le fichier « .product », créé dans le dossier de votre projet.

Ouvrez votre fichier de configuration du product com.example.e4.rcp.wizard.product en double-cliquant dessus dans l'explorateur de packages.

Basculez sur l'onglet « Overview » et lancez votre product à l'aide du lien « Launch an Eclipse application ». Cela devrait démarrer l'application Eclipse générée.

Une configuration d'exécution dans Eclipse définit l'environnement général dans lequel l'exécution aura lieu. Par exemple, elle définit les arguments de la machine virtuelle Java (VM), les dépendances du plug-in (classpath) etc. Parfois, une configuration d'exécution est appelée configuration de démarrage.

Si vous démarrez votre application Eclipse, en utilisant le lien dans le fichier product, une configuration d'exécution sera automatiquement créée.

Vous pouvez utiliser la configuration d'exécution créée directement pour réexécuter votre application. Les changements dans le fichier de configuration du product ne seront pas considérés.

Vous pouvez mettre à jour la configuration d'exécution en démarrant à nouveau l'application à partir de la définition du product.

Pour voir et modifier votre configuration d'exécution, sélectionnez le fichier de configuration de votre product, faites un clic droit dessus et sélectionnez Run As ? Run Configuration…

Sur l'onglet principal « Main », dans le champ « Location », vous définissez l'emplacement où l'IDE Eclipse va créer tous les fichiers nécessaires pour démarrer votre application basée sur Eclipse.

La configuration d'exécution vous permet d'ajouter des paramètres supplémentaires pour votre application sur l'onglet « Arguments ». Par défaut, le paramètre -consoleLog est inclus. Cela va écrire les messages d'erreur de l'instance d'application en cours d'exécution dans la vue console de votre IDE Eclipse.

Le tableau ci-dessous énumère les paramètres d'exécution utiles

Les erreurs dans la configuration d'exécution des applications RCP sont fréquemment la source de problèmes.

Eclipse peut vérifier pour vous les dépendances manquantes automatiquement avant chaque démarrage. Dans l'onglet Plug-ins, cochez l'option « Validate plug-ins prior to launching ». Cela va vérifier si vous avez tous les plug-ins requis dans votre configuration d'exécution.

Si cette vérification mentionne que certains plug-ins sont manquants, essayez de cliquer sur le bouton « Add Required Plug-Ins ». Assurez-vous aussi d'ajouter toutes les dépendances dans votre product.

Ensuite, vous devez ajouter le plug-in manquant à vos features ou votre product (si le product n'est pas basé sur les features).

Le tableau ci-dessous liste les problèmes potentiels et leurs solutions.

La partie visuelle d'une application Eclipse se compose de perspectives, de parts (vues et éditeurs), menus, barres d'outils, etc. Une application Eclipse comprend également des composants non visuels, par exemple les Handlers, les commandes et les raccourcis clavier.

Eclipse 4 utilise une description abstraite, appelée modèle d'application, pour décrire la structure d'une application. Ce modèle d'application contient les éléments visuels ainsi que certains éléments non visuels de l'application Eclipse 4.

Chaque élément du modèle possède des attributs qui décrivent son état actuel, par exemple la taille et la position pour une fenêtre. Les éléments du modèle pourraient être dans un ordre hiérarchique, par exemple les vues et éditeurs peuvent être regroupés sous une perspective.

Le modèle d'application définit la structure de l'application, il ne décrit pas le contenu particulier des composants de l'interface utilisateur.

Par exemple, le modèle d'application décrit quelles sont les parts disponibles. Il décrit également les propriétés de celles-ci, par exemple si une part peut être fermée, son titre, ID, etc.

Mais il ne décrit pas le contenu de la part elle-même, par exemple, les labels, les champs texte et boutons qui la composent. Le contenu de la part est toujours défini avec du code source.

Si le modèle d'application était une maison, il décrirait les chambres disponibles (parts) et leurs dispositions (Perspectives, PastStacks, PartSashContainer), mais pas le mobilier dans les chambres. Cela est illustré par l'image ci-dessous.

Le modèle d'application est extensible. La base de ce modèle est généralement définie comme un fichier statique. Le nom par défaut de ce fichier est Application.e4xmi et l'emplacement par défaut est le répertoire principal de votre application plug-in.

Vous pouvez modifier le nom par défaut et l'emplacement par le point d'extension de org.eclipse.core.runtime.products. Avec le paramètre applicationXMI, vous spécifiez l'emplacement et le nom de fichier du modèle. Voir l'annexe pour une description détaillée de cette procédure.

Le fichier XMI est lu au lancement de l'application et le modèle d'application initial est construit à base de cette image.

Les éléments du modèle d'application peuvent faire référence à des classes Java par le biais d'identifiants de ressources uniformes (URI).

L'URI définit l'emplacement de la classe Java. La première partie de cet URI est le plug-in, la deuxième le package et la dernière la classe.

Par exemple, une description du modèle pour une part contient des attributs tels que des libellés, des infobulles et les URI des icônes. Il contient également un URI qui pointe vers une classe Java pour cet élément. Cette classe fournit le comportement de la part, à l'aide de l'exemple maison/chambres cité plus haut, la classe est chargée de définir les meubles et leurs agencements dans la pièce et la façon dont les objets interactifs se comportent.

Si les éléments du modèle sont activés, cette classe va s'instancier.

Les objets créés basés sur le modèle d'application sont appelés des « objets de modèle ».

Les URI suivent l'un des deux schémas, l'un pour l'identification des ressources et l'autre pour l'identification des classes. Le tableau suivant décrit ces deux schémas. L'exemple suppose que le bundle est appelé test.

Le projet Eclipse tooling fournit un éditeur qui rend plus facile la tâche de travailler sur un modèle d'application.

Pour ouvrir l'éditeur de modèle double-cliquez sur le fichier Application.e4xmi (clic droit sur le fichier et sélectionnez Open With ? Eclipse 4 model editor

L'éditeur de modèle dispose de plusieurs réglages de préférences accessibles depuis Window ? Preferences ? Model Editor. La capture d'écran ci-dessous montre la page des préférences.

Le modèle d'application est également disponible en mode exécution. L'application peut accéder au modèle et le modifier par l'intermédiaire d'une API bien définie.

Ajouter le plug-in org.eclipse.e4.tools.emf.liveeditor et ses dépendances à votre configuration d'exécution, pour rendre l'éditeur de modèle utilisable dans votre application.

Ensuite, vous pouvez ouvrir l'éditeur de modèle dans votre application en cours d'exécution avec la combinaison de touches Alt + Maj + F9. Ceci fonctionne également pour l'IDE 'Eclipse 4 lui-même.

Pour ouvrir l'éditeur directement dans votre application Eclipse 4, il faudrait au préalable configurer les raccourcis clavier dans votre application.

Vous pouvez modifier le modèle de votre application directement à l'exécution en utilisant l'éditeur de modèle. La plupart des changements sont immédiatement appliqués, par exemple si vous changez l'orientation d'une PartSashContainer. Votre interface utilisateur se mettra à jour automatiquement. Si vous modifiez le modèle de l'IDE Eclipse vous devez être prudent, car cela pourrait mettre l'instance de IDE eclipse en cours d'exécution dans un mauvais état.

Dans l'éditeur de modèle temps réel (live editor), vous pouvez sélectionner un élément de la part. Faites un clic droit dessus et sélectionnez Show Control pour voir la part en surbrillance.

La structure possible du modèle d'application est définie par un métamodèle créé avec l'Eclipse Modeling Framework (EMF). Un métamodèle décrit la structure d'un modèle de données, par exemple, il définit les propriétés que possède une part.

EMF est un Framework de modélisation très populaire destiné à un usage général. Il est à la base de plusieurs projets basés sur Eclipse. EMF permet de générer des classes Java à partir d'un métamodèle.

Eclipse EMF utilise un fichier .ecore pour définir le métamodèle.

Le métamodèle de l'application Eclipse 4 est stocké dans le plug-in org.eclipse.e4.ui.model.workbench qui se trouve dans le dossier du modèle. La définition du modèle de base peut être trouvée dans le fichier UIElements.ecore. Les classes du modèle d'Eclipse 4 sont générées sur la base de ce modèle.

Si vous voulez scruter ce modèle, vous pouvez installer EMF tools à l'aide du gestionnaire de mise à jour d'Eclipse et importer la définition du plug-in dans votre espace de travail. Pour importer un plug-in à partir de votre actuelle plate-forme prévue (par défaut c'est l'IDE 'Eclipse) dans votre espace de travail, utilisez la vue Plug-ins, cliquez droit sur un plug-in et sélectionnez Import As ? Source Project.

Le fichier Application.e4xmi, qui décrit le modèle d'application Eclipse, est une version persistante d'un modèle EMF.

Lors du démarrage, l'environnement d'exécution Eclipse crée le modèle d'application en se basant sur le fichier Application.e4xmi et instancie les classes mentionnées dans le modèle si nécessaire.

Le cycle de vie de chaque objet du modèle est donc contrôlé par l'environnement d'exécution d'Eclipse. Celui-ci instancie et détruit les objets du modèle.

L'onglet Supplementray dans l'éditeur de modèle permet de saisir des informations additionnelles sur un élément du modèle.

Tous les éléments du modèle nous donnent la possibilité de leur attribuer des tags. Ces tags peuvent être utilisés par la plateforme Eclipse pour sélectionner les éléments du modèle apparentés à l'aide du ModelService. Par défaut Eclipse utilise des tags prédéfinis pour déterminer l'état de certains éléments du modèle. Par exemple, les tags shellMaximized et shellMinimized dans une fenêtre sont utilisés par Eclipse afin de déterminer si la fenêtre doit être maximisée ou minimiserée.

La capture d'écran ci-dessous montre comment définir une fenêtre maximiser.

Un autre tag qui est fréquemment utilisé est NoAutoCollapse que vous pouvez ajouter à un conteneur PartStack. Avec cette option le PartStack ne va pas se réduire, même si vous supprimez toutes ses parts.

Les tags sont automatiquement rendus persistants par l'environnement d'exécution d'Eclipse entre les redémarrages de l'application et ils sont représentés comme une collection de chaînes.

Consultez l'annexe de ce tutoriel pour plus de tags

Les éléments du modèle peuvent aussi avoir un état persistant. Si vous retrouvez l'élément du modèle, vous pouvez avoir et définir son état persistant.

// modelObject est l'objet du model 
// retrouvé à l'aide de l'injection de dépendance (ex. an MPart)

// Avoir l'état avec la clé "yourKey"
String state = modelObject.getPersistedState().get(yourKey);

// sauvegarder l'état
modelObject.getPersistedState().put(yourKey, state) ;

Les données persistantes pour les éléments du modèle sont automatiquement restaurées par l'application Eclipse entre les redémarrages de celle-ci et permet de stocker les paires clés/valeurs sous forme de chaînes.

Chaque élément du modèle vous permet de lui définir un ID. Cet identifiant est utilisé par le Framework Eclipse pour identifier cet élément de modèle. Assurez-vous d'attribuer toujours un ID pour tous les éléments du modèle et que ces identifiants sont uniques.

Par conséquent, assurez-vous que tous vos éléments de modèle ont un ID qui leur est assigné.

Ce qui suit évoque les bonnes pratiques pour les conventions de nommage, qui sont également utilisées dans ce tutoriel.

Ouvrez le projet et vérifiez si des classes Java ont été créées. Vous ne devriez pas avoir de classes dans le dossier source (src).

Ouvrez le fichier MANIFEST.MF et basculez sur l'onglet Extensions. Confirmez que la liste des extensions est vide.

Créez un nouveau projet appelé com.example.e4.rcp.todo.product de type projet ? Général .

Faites un clic droit sur ce projet et sélectionnez New ? Product Configuration. Créez un fichier de configuration de product todo.product.

Appuyez sur le bouton New de l'onglet Overview de l'éditeur du product.

Entrez to-do comme nom, defining plug-in est votre plug-in et utilisez le nom product comme ID. Sélectionnez comme application la classe E4Application

Créez un nouveau projet feature appelé com.example.e4.rcp.todo.feature.

Inclure le plug-in com.example.e4.rcp.todo dans ce feature dans le fichier feature.xml.

Modifiez le fichier de configuration de votre product pour utiliser les features. Pour ce, ouvrez le fichier de configuration de votre product et sélectionnez l'option features sur l'onglet Overview dans l'éditeur du product.

Sélectionnez l'onglet Dependencies et ajoutez les features org.eclipse.e4.rcp et com.example.e4.rcp.todo.feature comme des dépendances avec le bouton Add.

Cliquez sur le bouton Add Required. Cela ajoutera aux dépendances les fetaures org.eclipse.emf.common et org.eclipse.emf.ecore.

Pour éviter les problèmes de dépendance avec les différentes versions du plug-in org.eclipse.e4.rcp, supprimez le numéro de version de vos features. Vous pouvez le faire avec le bouton Properties dans l'onglet Dependencies de l'éditeur du fichier de configuration du product.

Sélectionnez File ? New ? Other… ? Eclipse 4 ? Model ? New Application Model pour ouvrir l'assistant. Entrez votre application comme conteneur et le nom de fichier suggéré par l'assistant.

Cela va créer le fichier Application.e4xmi et l'ouvrir avec l'éditeur du modèle d'application.

Ajoutez une fenêtre à votre modèle d'application pour avoir un composant visuel.

Sélectionnez le nœud Windows, puis appuyez sur le bouton Add pour TrimmedWindow.

Entrez un ID, la position et la taille de la fenêtre et un libellé comme indiqué sur la capture d'écran ci-dessous.

Ouvrez le fichier product et basculez sur l'onglet Overview. Cliquez sur le lien Launch an Eclipse application dans la section Testing.

Vérifiez que votre application démarre. Elle devrait se présenter comme une fenêtre vide, qui peut être déplacée et fermée.

Dans les exercices à venir, vous allez utiliser les fonctionnalités des autres plug-ins Eclipse. Cela nécessite que vous définissiez une dépendance à ces plug-ins dans votre application. Les détails exacts de cette approche modulaire seront abordés dans un chapitre ultérieur.

Ouvrez votre fichier META-INF/MANIFEST.MF et sélectionnez l'onglet Dependencies. Utilisez le bouton Add dans la section Required Plug-ins pour ajouter les plug-ins suivants comme dépendances.

• org.eclipse.core.runtime
• org.eclipse.swt
• org.eclipse.e4.core.di
• org.eclipse.e4.ui.workbench
• org.eclipse.e4.ui.di
• org.eclipse.e4.core.di.extensions

Ajoutez également javax.annotation et javax.inject comme dépendances de packages.

Vous pouvez également ajouter la nature pde Plug-in Development Environment à votre projet dans lequel vous avez placé le fichier de configuration du product, si vous voulez être en mesure de démarrer votre product directement avec un clic droit sur le product et en sélectionnant Run As ? Eclipse Application

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
  <name>com.example.e4.rcp.todo.product</name>
  <comment></comment>
  <projects>
  </projects>
  <buildSpec>
    <buildCommand>
      <name>org.eclipse.pde.ManifestBuilder</name>
      <arguments>
      </arguments>
    </buildCommand>
    <buildCommand>
      <name>org.eclipse.pde.SchemaBuilder</name>
      <arguments>
      </arguments>
    </buildCommand>
  </buildSpec>
  <natures>
    <nature>org.eclipse.pde.PluginNature</nature>
  </natures>
</projectDescription>

Une application Eclipse consiste en une ou plusieurs fenêtres. Généralement, une application a une seule fenêtre, mais vous n'êtes pas limité à cela, par exemple, si vous souhaitez gérer un affichage multiple sur deux moniteurs.

Les parts sont des composants d'interface utilisateur qui vous permettent de naviguer et modifier les données. Les parts sont généralement divisées en vues (views) et éditeurs (editors).

La distinction entre les vues et les éditeurs n'est pas fondée sur des différences techniques, mais sur le concept d'utilisation et d'agencement qui est différent.

Une vue est généralement utilisée pour travailler sur un ensemble de données, qui pourraient être une structure hiérarchique. Si des données sont modifiées par la vue, ce changement est généralement appliqué directement à la structure de données. Une vue vous permet parfois d'ouvrir un éditeur pour les données sélectionnées.

L'exemple type d'une vue est l‘explorateur de package, qui vous permet de parcourir les fichiers des projets Eclipse. Si vous modifiez des données dans l'explorateur de packages, par exemple le changement du nom d'un fichier, cette opération se répercute directement sur le système de fichiers.

Les éditeurs sont usuellement utilisés pour modifier un seul élément de données, par exemple un fichier ou un objet de données. Pour appliquer les modifications apportées par l'éditeur à la structure de données, l'utilisateur doit explicitement sauvegarder le contenu de l'éditeur.

Les éditeurs et les vues peuvent être positionnés librement dans l'interface utilisateur.

Par exemple, l'éditeur de code Java est utilisé pour modifier les fichiers sources. Les modifications apportées au fichier source sont appliquées une fois que l'utilisateur sélectionne la commande Enregistrer. Un éditeur modifié est marqué d'un astérisque.

Une perspective est un conteneur visuel pour un ensemble de parts. Vous pouvez basculer entre différentes perspectives dans votre application Eclipse RCP avec le service EPartService.

Les parts peuvent être directement assignées à une fenêtre ou à une perspective. Si vous souhaitez regrouper et organiser les parts, vous pouvez utiliser PartStacks et PartSashContainers.

Les PartStacks contiennent une pile de parts dont une seule est visible à la fois, les parts peuvent être sélectionnées à l'aide d'onglets. Les PartSashContainer affichent tous ses enfants en même temps en mosaïque horizontale ou verticale.

La capture d'écran suivante montre une application Eclipse avec une disposition simple qui utilise deux PartSashContainers et quelques PartStacks.

Dans le niveau supérieur de cette disposition, il y a un PartSashContainer horizontal qui contient un autre PartSashContainer et quelques PartStacks. La structure est représentée dans le graphique suivant.

Cette section donne une description sommaire des étapes que vous allez faire dans ce tutoriel, qui consiste en la création d'une interface utilisateur modélisée de votre application Eclipse 4.

L'objectif est de créer l'interface utilisateur suivante.

Cela nécessite la création de plusieurs PartSashContainer et PartStacks. Chaque PartStacks contient actuellement une seule part.

Bien que ce ne soit pas un élément de modèle obligatoire, vous pouvez aussi ajouter une perspective à votre modèle d'application afin que vous puissiez facilement ajouter d'autres perspectives.

Ouvrez le fichier Application.e4xmi. Accédez à votre fenêtre to-do et sélectionnez le nœudControls. Ajoutez un PerspectiveStack. Appuyez sur le bouton Add pour créer un élément Perspective.

Entrez la valeur de To-Do dans le champ Label et com.example.e4.rcp.todo.perspective pour le champ ID.

Sélectionnez Controls en dessous de la perspective qui vient d'être créée et ajoutez un PartSashContainer. Changez son attribut Orientation à Horizontal.

Dans la liste déroulante du PartSashContainer, sectionnez PartStack et appuyez sur le bouton Add.

Sélectionnez à nouveau le PartSashContainer parent et ajoutez un autre PartSashContainer. Maintenant, ajoutez deux PartStacks au deuxième PartSashContainer.

Après ces changements, votre modèle d'application devrait ressembler à la capture d'écran ci-dessous.

Ajoutez un composant Part à chaque PartStack. Comme ID, utilisez le préfixe com.example.e4.rcp.todo.part suivi des suffixes énumérés dans le tableau suivant.

La capture d'écran ci-dessous montre les données d'une Part.

Démarrez votre product et assurez-vous que l'interface utilisateur ressemble à ce qui est prévu. Réaffectez vos Parts à d'autres PartStacks, si nécessaire. L'éditeur de modèle prend en charge le glisser-déplacer pour la réaffectation.

Notez que vous n'avez pas encore créé de classes Java pour votre application.

Vous allez maintenant créer des objets Java et les relier au modèle d'application.

Créez le package com.example.e4.rcp.todo.parts.

Créez trois classes Java appelées TodoOverviewPart, TodoDetailsPart et PlaygroundPart dans ce package. Ces classes n'étendent pas d'autres classes et n'implémentent aucune interface.

Le code suivant montre la classe TodoDetailsPart.

package com.example.e4.rcp.todo.parts;

public class TodoDetailsPart {
}

Ouvrez le fichier Application.e4xmi et connectez les classes avec les objets de modèle correspondants. Vous pouvez le faire via la propriété de la Class URI de l'élément de modèle Part.

Le tableau suivant donne un aperçu des éléments qui doivent être connectés.

L'éditeur de modèle d'Eclipse 4 vous permet de rechercher une classe existante via le bouton Find… . La liste initiale est vide, commencez à taper le nom d'une classe pour voir les résultats.

Exécutez votre application. Elle devrait démarrer, mais vous ne verrez aucune différence dans votre interface utilisateur.

Pour s'assurer que les objets du modèle ont été créés par le runtime d'Eclipse, créez un constructeur sans arguments pour l'une des classes et ajoutez une instruction System.out.println(). Vérifiez ensuite que le constructeur est appelé, une fois que vous avez lancé votre application.

Utilisez la propriété Container Data du modèle pour attribuer une largeur relative de 40 pour le conteneur de gauche et 60 à celui de droite.

En conséquence, le conteneur gauche devrait utiliser 40% de l'espace disponible.

Dans ce tutoriel vous allez afficher une carte Google dans le widget navigateur SWT.

Changez la classe PlaygroundPart de sorte que la part ressemble à la capture d'écran ci-dessous.

Finalement, votre classe Playground devrait ressembler au code suivant.

package com.example.e4.rcp.todo;

import java.io.UnsupportedEncodingException;
import java.net.URLEncoder;

import javax.annotation.PostConstruct;

import org.eclipse.e4.ui.di.Focus;
import org.eclipse.swt.SWT;
import org.eclipse.swt.browser.Browser;
import org.eclipse.swt.events.SelectionAdapter;
import org.eclipse.swt.events.SelectionEvent;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Text;

public class PlaygroundPart {
  private Text text;
  private Browser browser;

  @PostConstruct
  public void createControls(Composite parent) {
    parent.setLayout(new GridLayout(2, false));

    text = new Text(parent, SWT.BORDER);
    text.setMessage("Enter City");
    text.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false, 1, 1));

    Button button = new Button(parent, SWT.NONE);
    button.setText("Search");
    button.addSelectionListener(new SelectionAdapter() {
      @Override
      public void widgetSelected(SelectionEvent e) {
        String city = text.getText();
        if (city == null || city.length() == 0) {
          return;
        }
        try {
          browser.setUrl("http://maps.google.com/maps?q="
              + URLEncoder.encode(city, "UTF-8")
              + "&output=embed");
        } catch (UnsupportedEncodingException e1) {
          e1.printStackTrace();
        }
      }
    });

    browser = new Browser(parent, SWT.NONE);
    browser.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true, 2, 1));

  }

  @Focus
  public void onFocus() {
    text.setFocus();
  }
}

Le concept général de l'injection de dépendances est appelé inversion de contrôle. Une classe ne doit pas configurer ses dépendances, mais doit être configurée de l'extérieur.

L'injection de dépendances est un concept qui ne se limite pas à Java. Mais nous nous pencherons sur l'injection de dépendances d'un point de vue Java.

Une classe Java a une dépendance à une autre classe si elle utilise une instance de cette classe, par exemple, par l'appel du constructeur ou par l'appel d'une méthode statique. Par exemple, une classe qui accède à un service logger a une dépendance sur la classe de ce service.

Idéalement, les classes Java doivent être indépendantes, dans la mesure du possible, des autres classes Java. Cela augmente la possibilité de leur réutilisation et le pouvoir de les tester indépendamment des autres classes, par exemple pour les tests unitaires.

Si une classe Java instancie directement une autre classe à l'aide de l'opérateur new, elle ne peut pas être utilisée et testée de façon indépendante à partir de cette classe.

Pour découpler les classes Java, leurs dépendances doivent être définies de l'extérieur. Une classe Java doit tout simplement définir ses exigences, comme on peut le voir dans l'exemple suivant :

public class MyPart {
  
  @Inject private Logger logger;
  // DatabaseAccessClass voudrait appeler DB
  @Inject private DatabaseAccessClass dao;
  
  @Inject
  public void init(Composite parent) {
    logger.info("UI will start to build");
    Label label = new Label(parent, SWT.NONE);
    label.setText("Eclipse 4");
    Text text = new Text(parent, SWT.NONE);
    text.setText(dao.getNumber());
  }

}

Une autre classe peut lire ces dépendances et créer une instance de la classe, en injectant des objets dans la dépendance définie. Cela peut se faire avec la fonctionnalité de réflexion Java. Cette classe est généralement appelée le conteneur de dépendance et elle est une classe cadre (framework class).

De cette façon, la classe Java n'a aucune dépendance dure, c'est-à-dire qu'elle ne repose pas sur une instance d'une classe quelconque. Par exemple, si vous voulez tester une classe qui utilise un autre objet interrogeant directement une base de données, vous pouvez injecter un objet mock.

Les objets mock sont des objets qui agissent comme s'ils étaient des objets réels, mais ils ne font que simuler leurs comportements. Mock est un vieux mot anglais qui signifie « mimer » ou « imiter ».

Si l'injection de dépendances est utilisée, une classe Java peut être testée d'une manière isolée, ce qui est bon.

L'injection de dépendances peut se produire sur :

• le constructeur de la classe (injection de construction) ;
• une méthode (injection de méthode) ;
• un champ (injection de champ) .

L'injection de dépendances peut se produire sur les champs et méthodes statiques, ainsi que les non statiques.

Eclipse 4 supporte l'injection sur le constructeur, une méthode et sur les champs. Il utilise les annotations standard de Java @Inject et @Named, qui ont été définies dans la Java Specification Requests 330 (JSR330). En plus de ces annotations standard, Eclipse déclare l'annotation @Optional .

Le tableau suivant donne un aperçu des annotations d'injection de dépendances (DI).

Tableau 8. Annotation pour l'injection de dépendance

En plus de ces annotations de base, Eclipse contient plusieurs annotations à des fins spéciales, par exemple pour la propagation des événements ou le travail avec des préférences.

L'environnement Eclipse 4 crée des objets pour les classes Java désignés par le modèle d'application. Au cours de cette instanciation, l'environnement Eclipse parcourt la définition de classe à la recherche d'annotations.

Sur la base de ces annotations, le Framework Eclipse effectue l'injection. L'injection du constructeur est effectuée dans un premier temps et après l'injection des champs et de méthodes.

Les constructeurs sont appelés avant l'injection des champs. L'accès à un champ injecté dans le constructeur entraînera une exception levée par le Framework.

Le Framework Eclipse surveille également les valeurs injectées et si elles changent, il peut réinjecter les nouvelles valeurs. Cela signifie que les applications peuvent être dispensées d'avoir à installer (et supprimer) les listeners.

Par exemple, vous pouvez définir le fait que vous voulez injecter la sélection courante. Si la sélection change, le framework Eclipse va injecter la nouvelle valeur.

Nous avons vu la façon dont fonctionne l'injection de dépendances et quelles sont les annotations à utiliser pour définir le comportement des classes Java. Mais nous n'avons pas encore abordé la portée de l'injection, autrement dit, ce que vous pouvez injecter dans vos classes de modèle.

L'environnement Eclipse crée un contexte dans lequel les valeurs injectables peuvent être stockées. Ce contexte peut être modifié, par exemple l'application et le Framework peuvent ajouter des éléments au contexte.

Le contexte Eclipse contient :

• tous les objets associés au modèle d'application ;
• tous les autres objets qui ont été explicitement ajoutés au contexte ;
• Toutes les préférences - les paires clés / valeurs qui sont généralement utilisées pour configurer l'application ;
• Les Services OSGi - composants logiciels qui peuvent être consommés de façon dynamique.

Les applications peuvent définir aussi leurs propres fournisseurs d'injection.

Dans le cadre de ce tutoriel, tous les éléments du contexte seront appelés éléments de contexte.

Les objets peuvent être mis dans le contexte avec le nom de la classe ou par l'intermédiaire d'une chaîne. Si la clé est une chaîne, cette paire clé / valeur est appelée variable de contexte.

Les paires clé / valeur ou les variables de contexte peuvent être présentes à différents niveaux dans la hiérarchie du contexte.

Les variables de contexte et les paires clé/ valeur dans le contexte permettent de séparer l'état recherché de la source de l'état. Par exemple, dans l'IDE Eclipse beaucoup de composants utilisent l'éditeur actif pour gérer leurs vues, mais cela signifie que leurs vues sont couplées à l'éditeur actif. L'éditeur pourrait plutôt définir une variable de contexte de leur état et les vues réagiront aux changements des variables.

La plate-forme Eclipse met plusieurs paires clé / valeur et variables de contexte dans le contexte. Plusieurs clés de variables de contexte sont définies dans l'interface IserviceConstants.

Toutes les valeurs possibles pour l'injection de dépendances sont accessibles par l'intermédiaire du contexte.

Le contexte contient des objets Java qui peuvent être accessibles par le biais des clés. Celles-ci peuvent se présenter sous deux formes : des chaînes de caractères ou des objets de classes.

Si une chaîne de caractères est utilisée comme clé, la paire clé /valeur correspondante est appelée une variable de contexte.

L'accès au contexte fonctionne d'une manière similaire à l'accès à une map de structure de données Java.

Le contexte n'est pas une structure plane comme une map. Il est hiérarchique et peut également calculer dynamiquement des valeurs pour les clés recherchées.

Un contexte peut être local à un objet et peut avoir un contexte parent.

Les éléments de modèle qui implémentent l'interface MContext ont un contexte local. Ceux-ci sont pour le moment MApplication, MWindow, MPerspective, MPart et MpopupMenu.

Le contexte principal est créé par le framework Eclipse et tous les objets de contexte des éléments du modèle sont hiérarchiquement reliés à l'objet principal du contexte.

Les objets du modèle qui implémentent l'interface MContext ont leur propre contexte local. Par exemple, c'est le cas pour MWindow et MPart. Chaque contexte d'un élément du modèle contient une référence à l'objet modèle lui-même.

Par exemple, si une part demande un objet par une clé quelconque du contexte, Eclipse va d'abord rechercher cet objet dans le contexte local de la part. S‘il ne trouve pas la clé dans le contexte local, il va rechercher dans le contexte parent. Ce processus se poursuit jusqu'à ce que le contexte principal ait été atteint. À ce stade, le Framework devrait vérifier les services OSGi adéquats dans le registre OSGi.

Le graphique ci-dessous visualise la hiérarchie du contexte.

Le contexte est hiérarchique pour éviter les collisions entre les valeurs injectées et accroître l'isolement des classes en fonction de ce dont elles ont besoin. Par exemple, une part a besoin d'un objet composite unique pour créer ses interfaces utilisateur. Étant donné que les parts ont différents contextes locaux, leur @Inject obtient l'implémentation nécessaire dans le contexte actuel.

La recherche se passe de manière transparente pour l'appelant de l'injection.

L'interface de l'objet de contexte est l'interface IEclipseContext.

La plate-forme Eclipse utilise la classe OSGiContextStrategy à la recherche de services OSGi si le Framework Eclipse ne trouve pas la clé recherchée dans la hiérarchie des objets IEclipseContext.

Eclipse 4 dispose d'un Framework de rendu flexible. Pour chaque élément du modèle, le Framework détermine une classe de rendu qui est responsable de la création de l'objet Java associé à l'élément du modèle. Cette classe de rendu crée, si nécessaire, le contexte local de l'élément du modèle par l'intermédiaire de la classe EclipseContextFactory et relie ce contexte local à la hiérarchie de contexte.

Par exemple, la classe ContributedPartRenderer est chargée de créer les objets Java pour les parts du modèle. L'interface des parts est MPart.

ContributedPartRenderer crée un composite pour chaque part et injecte celui-ci dans le contexte local de la part.

Un autre exemple est la classe de WBWRenderer qui est responsable de la création des fenêtres. Cette classe met une instance de la IWindowCloseHandler et l'interface ISaveHandler dans le contexte de la fenêtre. Le premier est responsable du comportement de la fenêtre pendant la fermeture, l'autre pour la sauvegarde. Par exemple, le IWindowCloseHandler par défaut vous demandera si vous souhaitez enregistrer les parts qui indiquent qu'elles ont un contenu pouvant être sauvegardé via l'attribut de modèle MDirtyable. Vous pouvez modifier cette implémentation de IWindowCloseHandler par défaut via l'objet de modèle MWindow. Comme montré dans l'exemple suivant.

@Execute
public void execute(final Shell shell, EModelService service, 
  MWindow window) {
  IWindowCloseHandler handler = new IWindowCloseHandler() {
    @Override
    public boolean close(MWindow window) {
      return MessageDialog.openConfirm(shell, 
      "Close", 
      "You will loose data. Really close?");
    }
  };
window.getContext().set(IWindowCloseHandler.class, handler);
}

En général, chaque Framework définit une interface de programmation d'application (API).

Si vous utilisez un Framework, vous devez avoir une convention définissant quelles sont les méthodes appelées, à quel moment de l'exécution de votre programme. Par exemple, si une classe Java est chargée de traiter le clic d'un bouton de barre d'outils, le Framework doit savoir quelle est la méthode de cette classe qu'il devra appeler.

La manière «traditionnelle» de la définition d'une API se fait par héritage. Cette approche nécessite que vos classes étendent ou implémentent des classes et interfaces du Framework. C'est ainsi que Eclipse 3.x définit son API.

Le Framework définit par une classe abstraite quelles sont les méthodes qui doivent être implémentées. Dans cet exemple, la méthode pourrait s'appeler execute() et le Framework sait que cette méthode doit être appelée une fois si le bouton de la barre d'outils est cliqué.

Par exemple, dans Eclipse 3.x, la classe d'une vue va étendre la classe abstraite ViewPart. Cette classe définit la méthode createPartControl ().

Le Framework Eclipse 3.x sait que createPartControl () est responsable de la création de l'interface utilisateur et appelle cette méthode une fois la vue visible.

La définition d'API via l'héritage est un moyen simple de définir une API, mais il lie également les classes étroitement au Framework. Par exemple, tester la classe sans le Framework devient difficile. Il rend également difficile l'extension ou la mise à jour du Framework.

Eclipse ne fournit pas des classes du Framework que vous pouvez étendre. Pour identifier les méthodes qui devraient être appelées à un certain moment, la plate-forme Eclipse utilise des annotations pour identifier les méthodes qui devraient être appelées à un moment donné.

Ces annotations sont appelées des annotations de comportement.

Les annotations de comportement sont utilisées pour indiquer que certaines méthodes devraient être appelées lors d'événements donnés. Les tableaux qui suivent énumèrent les annotations de comportement utilisables pour les parts.

Tableau 9. Annotations du cycle de vie d'une part

Les annotations @PostConstruct et @PreDestroy sont incluses dans le package javax.inject.

Eclipse définit également d'autres annotations pour les autres composants. Le tableau suivant en présente quelques-une, mais vous avez aussi des annotations pour les commandes qui sont couvertes dans le chapitre commandes.

Tableau 10. Autres annotations de comportement

@Persiste, @PersistState et @Focus font partie du package org.eclipse.e4.ui.di.

Dans le tutoriel suivant, nous allons développer nos classes afin d'utiliser l'injection de dépendances.

Changez la classe TodoOverviewPart par ce qui suit:

package com.example.e4.rcp.todo.parts;

import javax.inject.Inject;

import org.eclipse.swt.widgets.Composite;

public class TodoOverviewPart {
  
  @Inject 
  public TodoOverviewPart(Composite parent) {
    
  // En supposant que l'injection de dépendance fonctionne
  // le parent ne sera jamais null
  System.out.println("Woh! Got Composite via DI.");
  
  // A-t-il un gestionnaire de mise en page?
  System.out.println("Layout: " + parent.getLayout().getClass());
  }
}

Exécutez votre application et vérifiez dans la console de votre IDE Eclipse pour voir si le paramètre Composite a été injecté. Notez la classe Layout pour laquelle le composite est assigné, si elle n'est pas nulle.

Il est possible de créer l'interface utilisateur d'une part dans le constructeur, mais l'injection pour les champs et méthodes ne se fait pas à ce niveau.

Par conséquent, il est recommandé que l'interface utilisateur soit créée dans une méthode @PostConstruct.

Créer l'interface utilisateur dans une méthode annotée avec @PostConstruct exige que les méthodes @Inject sachent que l'interface utilisateur n'a pas encore été créée.

Ajoutez la méthode suivante à vos classes TodoOverviewPart, TodoDetailsPart et PlaygroundPart.

// Declare a field label, required for @Focus
Label label;

@PostContruct
public void createControls(Composite parent) {
  label = new Label(parent,SWT.NONE);
  label.setText("A text....");
}

Retirez tous les constructeurs de vos classes.

Implémentez une méthode @Focus pour chaque part. La définition du focus sur l'un des contrôles SWT est obligatoire dans Eclipse 4.2. Cela devient optionnel dans Eclipse 4.3.

@Focus
private void setFocus() {
  label.setFocus();
}

Exécutez votre application et vérifiez que la méthode @PostConstruct a été appelée. Utilisez soit le débogage ou une instruction System.out.println (). Chaque part doit mettre le focus sur l'un de ses contrôles, sinon certains services ne fonctionneront pas. C'est pourquoi nous avons ajouté SWT Label pour être le contrôle qui recevra le focus. Même si le champ Label ne peut pas prendre le focus, il déclenche l'événement SWT.ACTIVATE, ce qui est suffisant pour que les services Eclipse fonctionnent correctement.

Si SWT vous est familier, ajoutez d'autres contrôles sur votre interface utilisateur.

Le modèle d'application Eclipse peut comporter des commandes et des handlers.

Une commande dans Eclipse est une description déclarative d'une action abstraite qui peut être exécutée, par exemple enregistrer, modifier ou copier. Une commande est indépendante de ses détails d'implémentation.

Le comportement d'une commande est défini par un handler. Le handler définit une classe par son attribut contributionURI. Cet attribut est affiché en étant Class URI dans l'éditeur de modèle.

Le handler peut être global à l'application, ou porté sur une fenêtre ou une part. Cela signifie que vous pouvez définir par exemple un handler de copie global pour votre application, mais aussi définir des handlers de copie spécifiques pour certaines parts. Eclipse utilise le plus détaillé.

Les annotations de comportement pour les classes de handler sont décrites dans le tableau suivant.

Tableau 11. Autres annotations de comportement

Cette classe utilise l'annotation @Execute pour définir quelle méthode est appelée une fois le gestionnaire est exécuté. L'annotation @CanExecute définit la méthode qui évalue si le gestionnaire est actuellement actif. Si le gestionnaire doit toujours s'exécuter, il n'est pas nécessaire d'implémenter une méthode @CanExecute.

package com.example.e4.rcp.todo.handlers;

// Imports statements cut out
// ..

public class ExitHandler {
  @Execute
  public void execute(IWorkbench workbench) {
    workbench.close();
  }

  // Default to true if not implemented
  @CanExecute
  public boolean canExecute() {
    // TODO ajouter ici quelques tests logiques
    return true;
  }

}

@CanExecute est appelée par le Framework lorsque l'événement SWT.SHOW se produit. Cet événement est par exemple déclenché si une nouvelle part est affichée. Également, si vous ajoutez des éléments à la barre d'outils, un minuteur est automatiquement initié par le Framework Eclipse qui, au moment de la rédaction de ce document, s'exécute toutes les 400 millisecondes. Ce temporisateur vérifie le @CanExecute pour activer ou désactiver les éléments de la barre d'outils connexes.

Dans la classe du handler, vous pouvez déterminer l'ID de la commande si celle-ci a été déclenchée par le biais de l'interface utilisateur. La résolution de l'ID est impossible, si elle a été déclenchée par le service de commande. Le code suivant montre comment obtenir l'ID de commande.

@Execute
public void execute(MHandledItem item) {
  MCommand command = item.getCommand();
  // Afficher l'ID de la commande
  System.out.println(command.getElementId());
}

Si vous êtes familier Eclipse 3.x, vous êtes probablement la recherche des commandes prédéfinies que vous pouvez réutiliser. La plate-forme Eclipse 4 essaie d'être aussi légère que possible.

Eclipse 4 ne comprend aucune des commandes standard. Vous devez définir toutes vos commandes.

Vous pouvez ajouter des menus et barres d'outils dans le modèle d'application pour la fenêtre et les parts. Le menu et les éléments de barre d'outils contiennent des références aux commandes. Si une commande est sélectionnée, l'environnement d'exécution déterminera les handlers de commande associés.

Pour les cas simples, vous pouvez également utiliser « Direct MenuItem » ou un « Direct ToolItem », qui vous permettent de définir une classe qui sera exécutée directement. Ceci est utile si vous voulez juste répondre à un clic utilisateur sur un élément de menu ou de la barre d'outils.

Utilisation des commandes avec handler vous donne plus de flexibilité. Par exemple, vous pouvez avoir différents gestionnaires pour différents périmètres (applications ou vues) et vous pouvez définir des raccourcis clavier pour les commandes associées aux handlers.

Les barres d'outils dans l'application sont encapsulées dans le modèle d'application avec l'élément de modèle trimbar. Le trimbar peut être défini pour une fenêtre. Via son attribut, vous définissez si le trimbar doit être placé dans la bordure supérieure, gauche, droite ou en bas de la fenêtre.

La commande associée est affectée à l'élément de menu ou de barre d'outils. Les menus et les barres d'outils permettent l'ajout de séparateurs. Les menus peuvent avoir des sous-menus.

Pour rendre les menus plus accessibles, le libellé du menu peut faire usage d'un moyen mnémotechnique. Une mnémonique apparaît comme une lettre soulignée dans le menu lorsque l'utilisateur maintient la touche Alt enfoncée et il sert comme un moyen pour naviguer facilement à travers les menus par le biais du clavier. Définir des mnémoniques est aussi simple que précéder la lettre destinée à être le mnémonique avec un & dans la définition du libellé. Par exemple, le libellé &Enregistrer apparaît comme Enregistrer avec le E souligné lorsque la touche Alt est enfoncée.

Chaque commande ne peut avoir qu'un seul handler valide pour une portée donnée. Le modèle d'application vous permet de définir un handler pour l'application, pour une fenêtre ou une part.

Si vous définissez plus d'un handler pour une commande, Eclipse va sélectionner le gestionnaire le plus spécifique à l'élément de modèle.

Par exemple, si vous définissez un handler pour la commande « Copier » pour votre fenêtre et si vous définissez un autre handler « Copier » pour votre part, le runtime sélectionne les handlers les plus proches de l'élément de modèle.

Une fois le handler sélectionné, @CanExecute est appelé, ainsi le handler peut déterminer s'il peut exécuter la commande dans un contexte donné. Si elle retourne false, il permettra de désactiver tous les menus et éléments de barre d'outils qui sont associés avec cette commande.

La documentation java de @Execute définit que dans un handler, une seule méthode est autorisée à être annotée avec @Execute.

Une bonne convention est de commencer l'ID avec le plus haut niveau du nom du package de votre projet et de n'utiliser que des minuscules.

Les ID des commandes et handler devraient refléter leur relation. Par exemple, si vous implémentez une commande avec l'ID com.example.contacts.commands.show, vous devez utiliser comme ID com.example.contacts.handler.show pour le handler. Si vous avez plus d'un handler à définir, ajoutez un suffixe décrivant son but, par exemple, com.example.contacts.handler.show.details.

Dans le cas où vous implémentez des commandes couramment utilisées, par exemple, enregistrer, copier, vous devez utiliser les ID existants de la plate-forme, comme certaines contributions d'Eclipse, excepté les ID qui suivent. Une liste plus complète d'ID de commande est disponible dans org.eclipse.ui.IWorkbenchCommandConstants.

Tableau 12. ID par défaut pour les commandes fréquemment utilisées

Un menu dans une part peut être défini comme un menu de vue. Veuillez noter que vous pouvez définir qu'un seul menu au maximum comme menu de vue.

Pour ajouter un élément menu de vue, sélectionnez l'entrée des menus sous notre part, sélectionnez ViewMenu et appuyez sur le bouton Add.

Vous pouvez également définir un menu contextuel pour les contrôles SWT. Pour cela, vous définissez un menu contextuel pour votre part dans le modèle d'application.

Vous pouvez ensuite l'assigner via la classe EMenuService avec le registerContextMenu (contrôle, ID) à un contrôle SWT. Le paramètre id de la méthode de registerContextMenu doit être l'ID de votre élément menu contextuel du modèle.

Le code suivant montre un exemple pour l'enregistrement.

package com.example.e4.rcp.todo.parts;

import javax.annotation.PostConstruct;

import org.eclipse.e4.ui.workbench.swt.modeling.EMenuService;
import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Text;

public class TodoDetailsPart {

  @PostConstruct
  public void createUi(Composite parent, EMenuService service) {
    final Text text = new Text(parent, SWT.BORDER);
    text.setText("Hello");
    // soyez certain d'utiliser le bon ID 
    // de votre modèle d'application
    service.registerContextMenu(text, 
        "com.example.e4.rcp.todo.popupmenu.table");
  }
}

Si vous utilisez un Viewer Jface, vous avez à utiliser des contrôles SWT.

package com.example.e4.rcp.todo.parts;

import javax.annotation.PostConstruct;

import org.eclipse.e4.ui.workbench.swt.modeling.EMenuService;
import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Text;

public class TodoDetailsPart {

  @PostConstruct
  public void createUi(Composite parent, EMenuService service) {
    // encore du code...
    TableViewer viewer = new TableViewer(parent, SWT.FULLSELECTION | SWT.MULTI);
    
    // encore du code
    
    /enregistrer le menu contextuel dans votre table
    menuService.registerContextMenu(viewer.getTable(), 
        "com.example.e4.rcp.todo.popupmenu.table");
  }
}

Si vous souhaitez mettre en œuvre cet exemple, vous devez également avoir une dépendance au plugin org.eclipse.e4.ui.workbench.swt dans votre application.

Vous pouvez également passer des paramètres aux commandes.

Pour définir une commande qui accepte un paramètre, sélectionnez votre commande et appuyez sur le bouton Ajouter dans la section Paramètres.

L'ID est l'identifiant que vous pouvez utiliser pour obtenir le paramètre via l'annotation @Named.

L'obtention du paramètre via l'annotation @Named dans votre handler est illustrée dans l'exemple de code suivant.

package com.example.e4.rcp.todo.handlers;

import javax.inject.Named;

import org.eclipse.e4.core.di.annotations.CanExecute;
import org.eclipse.e4.core.di.annotations.Execute;

public class TestHandler {
  @Execute
  public void execute(@Named("com.example.e4.rcp.todo" +
      ".commandparameter.input") String param) {
    System.out.println(param);
  }


}

Dans votre menu ou barre d'outils, le champ Name doit être égal à ID donné dans le paramètre que vous avez défini dans votre commande. La donnée du champ Value est passée à la commande.

La visibilité des menus, barres d'outils et leurs entrées peut être restreinte par les Core expressions. Vous pouvez ajouter l'attribut correspondant dans le modèle d'application de l'ID défini par le point d'extension org.eclipse.core.expressions.definitions dans le fichier plugin.xml.

Pour ajouter ce point d'extension à votre application, ouvrez le fichier plugin.xml et sélectionnez l'onglet Dependencies dans l'éditeur. Ajoutez le plug-in org.eclipse.core.expressions dans la section Required Plug-ins.

Ensuite, sélectionnez l'onglet Extensions, appuyez sur le bouton Add et ajoutez l'extension org.eclipse.core.expressions.definitions. Vous définissez un ID par lequel la Core expression peut être désignée dans le modèle d'application.

Avec un clic droit sur l'extension, vous pouvez commencer à construire votre expression.

Vous pouvez attribuer cette Core expression pour votre élément de menu dans le modèle d'application. La capture d'écran ci-dessous montre cela pour l'élément de menu Test.

L'exemple suivant peut être utilisé pour restreindre la visibilité d'un élément de menu en fonction du type de la sélection en cours. Vous pourrez ensuite apprendre à configurer la sélection en cours. Veuillez noter que la variable de sélection est actuellement appelée org.eclipse.ui.selection. Dans Eclipse 3.x cette variable s'appelait Selection.

<extension
      point="org.eclipse.core.expressions.definitions">
  <definition
            id="com.example.e4.rcp.todo.selectionset">
      <with variable="org.eclipse.ui.selection">
    <iterate ifEmpty="false" operator="or">
      <instanceof value="com.example.e4.rcp.todo.model.Todo">
      </instanceof>
    </iterate>
      </with>
  </definition>
</extension>

Cette expression peut être utilisée pour limiter la visibilité des éléments de modèle.

Cette approche est similaire à la définition des Core expressions dans Eclipse 3.x.

Les valeurs disponibles pour Eclipse 3.x sont documentées dans le Wiki Eclipse sous le lien suivant: Core Expressions et contenues dans l'interface ISources. Eclipse 4 n'appuie pas toujours les mêmes variables, mais le wiki pourrait toujours être utile.

Vous pouvez également placer des valeurs dans IEclipseContext de votre application et les utiliser pour votre évaluation de visibilité.

Plus tard, vous en apprendrez plus sur la modification d'IEclipseContext, mais le code suivant est un exemple d'un handler qui met la valeur de la clé myactivePartId dans le contexte.

@Execute
public void execute(IEclipseContext context) {
// mettre une valeur exemple dans le context  context.set("myactivePartId", 
  "com.example.e4.rcp.ui.parts.todooverview");
}

L'exemple suivant montre une core expression qui est évaluée à vrai si une clé myactivePartId avec la valeur com.example.e4.rcp.ui.parts.todooverview est trouvée dans le contexte.

Cette core expression peut être assignée à un élément de menu et de contrôler sa visibilité.

<extension
         point="org.eclipse.core.expressions.definitions">
      <definition
            id="com.example.e4.rcp.todo.todooverviewselected">
         <with
               variable="myactivePartId">
            <equals
                  value="com.example.e4.rcp.ui.parts.todooverview">
            </equals>
         </with>
      </definition>
   </extension>

Vous allez maintenant définir des commandes et des gestionnaires pour votre application. Nous allons définir nos gestionnaires pour l'ensemble de l'application.

Ouvrez le fichier Application.e4xmi et sélectionnez Commands.

Avec le bouton Add, vous pouvez créer de nouvelles commandes. Le nom et l'ID sont les champs les plus importants. Créez les commandes suivantes.

Tableau 13. Les Commandes

Créez le package com.example.e4.rcp.todo.handlers pour vos classes de traitement.

Toutes les classes de handler mettront en œuvre la méthode execute ().

package com.example.e4.rcp.todo.handlers;

import org.eclipse.e4.core.di.annotations.CanExecute;
import org.eclipse.e4.core.di.annotations.Execute;

public class SaveAllHandler {
  @Execute
  public void execute() {
    System.out.println("Called");
  }
}

En utilisant le modèle ci-dessus pour toutes les classes, créez les classes suivantes :

• SaveAllHandler
• ExitHandler
• NewTodoHandler
• RemoveTodoHandler
• TestHandler

Sélectionnez l'élément Handlers dans le modèle de votre application et créez les gestionnaires du tableau ci-dessous pour vos commandes. Pour la définition des gestionnaires, l'ID, la commande et la classe sont des informations pertinentes.

Utilisez le préfixe de com.example.e4.rcp.todo.handlers pour tous les ID des gestionnaires.

Tableau 14. Les handlers

L'éditeur de modèle d'application montre à la fois le nom et l'ID de la commande. L'URI de la classe suit le schéma bundleclass :// le tableau définit uniquement le nom de la classe pour le rendre plus lisible. Par exemple, pour le gestionnaire de sauvegarde cela ressemble à ce qui suit :

bundleclass://com.example.e4.rcp.todo/[CONTINUE...]
com.example.e4.rcp.todo.handlers.SaveAllHandler

Vous allez maintenant ajouter un menu à votre modèle d'application.

Sélectionnez le fichier Application.e4xmi. Pour ajouter un menu à une fenêtre, sélectionnez votre entrée TrimmedWindow dans le modèle et cochez l'option Main Menu.

Attribuez l'ID org.eclipse.ui.main.menu à votre menu principal.

Ajoutez deux menus, l'un avec le nom Fichier et l'autre avec le nom Edition dans l'attribut label.

Également, définissez l'ID org.eclipse.ui.file.menu pour le menu Fichier et com.example.e4.rcp.todo.menu.edit comme ID pour le menu Edition.

Ajoutez un HandledMenuItem au menu Fichier. Cet élément doit pointer sur la commande Enregistrer via l'attribut Command.

Ajoutez un séparateur après l'élément de menu Enregistrer et ajoutez après une entrée pour la commande exit.

Ajoutez toutes les autres commandes dans le menu Edition.

Sélectionnez le nœud TrimBars sous votre entrée Window et appuyez sur le bouton Add. L'attribut latéral doit être réglé sur Top, de sorte que toutes les barres attribuées à ce TrimBar apparaissent en haut de l'application.

Ajoutez une barre d'outils pour votre TrimBar. Ajoutez un ToolItem Handled à cette barre d'outils, qui pointe sur la commande org.eclipse.ui.file.saveAll.

Définissez le Label pour cette entrée pour Enregistrer.

Pour tester si votre handler fonctionne, modifiez la classe de votre ExitHandler, de sorte qu'il va fermer votre application.

package com.example.e4.rcp.todo.handler;

import org.eclipse.e4.core.di.annotations.Execute;
import org.eclipse.e4.ui.workbench.IWorkbench;

public class ExitHandler {
  @Execute
  public void execute(IWorkbench workbench) {
    workbench.close();
  }
}

Modifiez votre classe SaveAllHandler, de sorte que System.out.println écrit le message suivant sur la console: « SaveAllHandler est appelé »

Il est également possible de définir des combinaisons de touches (raccourcis clavier) pour votre application Eclipse. Cela nécessite deux étapes. D'abord, vous devez entrer des valeurs pour le nœud BindingContext de votre modèle d'application.

Ensuite, vous devez saisir les combinaisons de touches pour le BindingContextappropriée dans le nœud BindingTable de votre modèle d'application. Une BindingTable est toujours assignée à un BindingContext spécifique. Le BindingContext peut avoir plusieurs BindingTables qui lui sont assignées.

Les BindingContexts sont définis de façon hiérarchique, de sorte que les raccourcis clavier dans les BindingContexts enfants dominent sur les raccourcis clavier similaires dans le BindingContext parent.

Le BindingContext est définie par son ID. Le BindingContext peut s'assigner à une fenêtre ou une part dans le modèle d'application. Cela définit les raccourcis clavier applicables pour la fenêtre ou la part

Eclipse JFace utilise des identifiants de BindingContext prédéfinis qui sont définis dans la classe org.eclipse.jface.contexts.IContextID. JFace distinction entre les raccourcis applicables sur les boites de dialogues, les fenêtres ou sur les deux.

Ce qui suit donne un aperçu des ID pris en charge et la validité des raccourcis clavier définis par référence à cet ID de contexte.

Tableau 15. Les valeurs BindingContext par défaut

Par exemple, Ctrl + C (Copier) serait défini dans dialogAndWindows, car il est applicable partout, mais F5 (Rafraîchir) ne peut être défini que pour une fenêtre et non pas pour une boite de dialogue.

Le nœud BindingTable dans le modèle d'application vous permet de définir des raccourcis pour un BindingContext spécifique.

Pour définir un raccourci, vous allez créer un nouveau nœud pour le BindingTable et définir une référence pour l'ID du contexte.

Dans votre raccourci clavier, vous définissez la séquence de touches et la commande associée à ce raccourci.

Les touches Control ne sont pas les mêmes pour les différentes plates-formes, comme ça peut être le cas pour un Mac et un système Linux. Par exemple, vous pouvez utiliser la touche Ctrl, mais ce serait figé. Il est préférable d'utiliser les metakeys M1-M4.

Tableau 16.Correspondance des touches

Ces valeurs sont définies dans la classe SWTKeyLookup.

Vous pouvez attribuer un BindingContext spécifique pour être actif lorsqu‘une part est activée.

S'il y a plusieurs combinaisons de touches définies, la classe ContextSet est chargée de déterminer celle par défaut. ContextSet utilise la hiérarchie BindingContext pour déterminer l'ordre de recherche. Le BindingContext est plus spécifique en fonction du nombre d'ancêtres qui sont entre celui-ci et le BindingContext racine (le nombre de niveaux qu'il y a). Le BindingContext le plus spécifique est considéré comme étant le premier et le BindingContext racine est considéré comme le dernier.

Vous pouvez également utiliser le service EContextService qui vous permet d'activer et de désactiver explicitement un BindingContext à l'aide des méthodes activateContext () et deactivateContext ().

La mise en œuvre des raccourcis exige que toutes les parts implémentent @Focus. Eclipse exige qu'un contrôle détienne le focus.

Comme le modèle est interactif, vous pouvez le changer durant l'exécution. Par exemple, vous pouvez modifier la taille de la fenêtre active, ajouter des parts à votre application ou supprimer des éléments de menu.

Pour ajouter de nouveaux éléments au modèle de votre l'application, vous pouvez utiliser le ModelService ou récupérer des éléments existants injectés.

Vous pouvez également obtenir les éléments de modèle injectés et changer leurs attributs.

Pour créer de nouveaux objets de modèle, vous pouvez utiliser la classe MBasicFactory.INSTANCE. Il s'agit d'une fabrique utilisée pour créer de nouveaux objets de modèle via des méthodes typées create*(). Par exemple, vous pouvez créer une nouvelle fenêtre lors de l'exécution, comme indiqué dans le code suivant.

// Cérer une nouvelle fenêtre et définir sa taille
MWindow window = MBasicFactory.INSTANCE.createTrimmedWindow();
window.setWidth(200);
window.setHeight(300);

// Ajouter la nouvelle fenêtre à l'application
application.getChildren().add(window);

Par exemple, le code suivant ajoute une nouvelle part à la fenêtre active.

package testing.handlers;

import org.eclipse.e4.core.di.annotations.Execute;
import org.eclipse.e4.ui.model.[CONTINUE...]
    .application.descriptor.basic.MPartDescriptor;
import org.eclipse.e4.ui.model.application.ui.basic.MBasicFactory;
import org.eclipse.e4.ui.model.application.ui.basic.MPart;
import org.eclipse.e4.ui.model.application.ui.basic.MWindow;

public class AddPartHandler {
  @Execute
  public void execute(MWindow window) {
    MPart part = MBasicFactory.INSTANCE.createPart();
    part.setElementId("mynewid");
    part.setLabel("A new Part");
    part.setContributionURI("bundleclass://com.example." +
        "e4.rcp.todo/com.example.e4.rcp.todo.parts.TodoOverviewPart");
    window.getChildren().add(part);
  }
}

Eclipse 4 essaie de garder le Framework aussi léger que possible. L'objet addon du modèle peut être ajouté globalement sur le modèle d'application et peut améliorer l'application avec une fonctionnalité supplémentaire. Les addons sont des objets Java normaux.

Les Addons utilisent la convention bundleclass://URI dans le modèle d'application pour se référer aux objets Java.

Avoir ces addons enregistrés leur permet d'être améliorés ou remplacés par l'équipe de la plate-forme Eclipse ou par une mise en œuvre spécifique du client en cas de besoin.

Pour le moment, les addons standard suivants sont utiles pour les applications Eclipse. Leurs noms de classe donnent une indication de leurs fonctionnalités. Consultez leur Javadoc pour avoir une brève description de leurs utilités.

• CommandServiceAddon
• ContextServiceAddon
• BindingServiceAddon
• CommandProcessingAddon
• ContextProcessingAddon
• BindingProcessingAddon

Des addons supplémentaires sont disponibles, par exemple pour le support du glisser-déplacer des Parts dans votre application.

Pour gérer le glisser-déplacer pour les parts, vous avez besoin d'ajouter le plug-in org.eclipse.e4.ui.workbench.addons.swt dans le fichier de configuration de votre product. Ensuite, vous pouvez utiliser DnDAddon et CleanupAddon à partir de ce bundle comme addon dans votre modèle d'application. Ce plug-in contient aussi le MinMax addon qui ajoute les fonctionnalités minimiser et maximiser à votre application.

Le plug-in org.eclipse.e4.ui.workbench.addons.swt fait participer ces plug-ins à votre modèle d'application via des processeurs, par exemple, une classe Java qui modifie le modèle d'application. Si vous supprimez le plug-in de votre product alors ces addons ne seront plus disponibles.

Les Addon sont créés avant que le moteur de rendu ne rende le modèle et après la création de la fonction EventAdmin.

Cela permet aux addons de modifier l'interface utilisateur produite par le moteur de rendu. Par exemple, l'addon min/max change le conteneur d'onglets créé pour MPartStacks pour avoir des boutons min/max dans le coin.

Les services d'EventAdmin fournissent les notifications sur les événements Eclipse, par exemple, si une part est activée. l'Addon peut aussi s'abonner à des événements de la plate-forme Eclipse.

Pour accéder à un contexte existant, vous pouvez utiliser l'injection de dépendances, si l'objet en question est géré par le runtime Eclipse, par exemple, si vous utilisez un objet de modèle.

package com.example.e4.rcp.todo.handlers;

import org.eclipse.e4.core.contexts.IEclipseContext;
import org.eclipse.e4.core.di.annotations.Execute;

public class ShowMapHandler {
  @Execute
  public void execute(IEclipseContext context) {
    // Ajoute des objets au contexte local de ce handler
    // ...
  }

Alternativement, si votre objet de modèle étend MContext vous pouvez utiliser ID pour obtenir l'objet de modèle injecté et utiliser la méthode getContext () pour accéder à son contexte. Par exemple MPart, MWindow, MApplication et MPerspective étendent Mcontext.

package com.example.e4.rcp.todo.parts;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

import org.eclipse.e4.core.contexts.IEclipseContext;
import org.eclipse.e4.ui.model.application.ui.basic.MPart;
import org.eclipse.swt.widgets.Composite;

// Récupération du contexte de l'application
// avec l'objetMApplication

public class TodoDetailsPart {
  
  @PostConstruct
  public void createControls(Composite parent, 
    MApplication application) {
    IEclipseContext context = application.getContext();
    // Ajoute ou accède à l'objet depuis et vers le contexte d'application 
    // ...
  }

}

Si vous êtes à l'extérieur de l'objet de modèle, vous pouvez toujours accéder au contexte OSGi comme ce qui suit :

public Object start() {
  // Récupérer les informations du bundle
  Bundle bundle = FrameworkUtil.getBundle(getClass());
  BundleContext bundleContext = bundle.getBundleContext();
  IEclipseContext eclipseCtx =   
      EclipseContextFactory.getServiceContext(bundleContext);

  // remplir le contexte avec des informations en utilisant set(String,Object)
  // ....
  
  // instanciation de la classe 
  ContextInjectionFactory.make(MyPart.class, eclipseCtx);
}

Vous pouvez ajouter des objets au contexte à travers des services OSGi. Ils sont automatiquement disponibles dans le contexte. Mais ils sont globaux au Framework. Ils ne peuvent pas accéder au modèle du Workbench ou de son contexte.

Vous pouvez ajouter des paires clé / valeur directement à IEclipseContext, par exemple un objet todo sous la clé active. L'ajout d'objets dans un contexte peut être fait par la méthode set () sur IEclipseContext. L'exemple suivant crée un nouveau contexte avec la méthode de fabrique EclipseContextFactory.create() et lui ajoute quelques objets.

@Inject
public void addingContext(IEclipseContext context) {
  // Nous avons besoin d'ajouter un objet au contexte

  // Création de l'instance de la classe
  IEclipseContext myContext = EclipseContextFactory.create();

  // Ajout de quelques valeurs
  myContext.set("mykey1", "Hello1");
  myContext.set("mykey2", "Hello2");

  // Ajout de la relation au parent
  myContext.setParent(context);

  // Alternativement vous pouvez aussi 
  // établir une relation parent/enfant 
  // avec l'appel de la méthode  
  // context.createChild()
  
}

Une variable de contexte peut être déclarée comme étant modifiable par l'appel de la méthode declareModifiable(key).

@Inject
public void addingContext(IEclipseContext context) {
  // Ajout de quelques valeurs
  context.set("mykey1", "Hello1");
  context.set("mykey2", "Hello2");
  
  // Marquer la valeur nommée comme étant modifiable 
  // par les descendants de ce contexte. Si la valeur n'existe pas
  // dans ce contexte, une valeur null est ajoutée à ce nom.
  context.declareModifiable("mykey1");

}

Les variables de contexte modifiables sont ajoutées à des niveaux particuliers de la hiérarchie IEclipseContext et peuvent également être modifiées à l'aide de la méthode modify() plutôt que la méthode set() d'IEclipseContext.

La méthode modify() recherche dans la chaîne pour trouver le contexte définissant la variable. Si aucun contexte de la chaîne parente ne contient la valeur définie pour le nom, la valeur sera définie dans ce contexte. Si la clé existe déjà dans ce contexte, modify() exige que la clé soit définie comme étant modifiable avec la méthode declareModifiable(). Sinon, la méthode lève une exception.

Vous pouvez ajouter des paires clés/valeurs et des variables de contexte à différents niveaux de la hiérarchie du contexte pour alimenter votre application avec différents objets.

Vous pouvez ajouter des addons au modèle d'application. Ces addons contiennent une référence à des classes Java, qui peuvent étendre le contexte ou d'interagir avec d'autres services de la plate-forme Eclipse, par exemple le EventAdmin.

Par exemple, vous pouvez enregistrer un addon de modèle pour ajouter quelques valeurs dans le contexte.

Le code suivant montre un exemple d'implémentation de l'addon.

package com.example.e4.rcp.todo.addons;

import javax.annotation.PostConstruct;

import org.eclipse.e4.core.contexts.IEclipseContext;

public class MyModelAddon {
  @PostConstruct
  public void init(IEclipseContext context) {
    context.set("test1", "Hello");
  }
}

IEclipseContext vous permet d'enregistrer un objet de type RunAndTrack avec la méthode runAndTrack().

Un RunAndTrack est essentiellement un Runnable qui a accès au contexte. Si le runnable accède à n'importe quelle valeur dans ce contexte, au cours de son exécution, le runnable sera exécuté à nouveau si une de ces valeurs change.

La méthode runAndTrack() permet à un client de garder un état externe synchronisé avec une ou plusieurs valeurs de ce contexte.

Le runnable n'a pas besoin d'être explicitement désinscrit dans le contexte lorsqu'il n'est plus concerné par le suivi des modifications. Si aucune invocation ultérieure de ce runnable n'a eu accès à une des valeurs de ce contexte, il est automatiquement désinscrit du suivi des modifications dans ce contexte.

Si le Framework de l'injection de dépendances d'Eclipse ne trouve pas un objet dans le contexte actuel, il interroge les fonctions de contexte définies pour voir si une classe a été enregistrée pour la créer.

Les fonctions de contexte implémentent l'interface IContextFunction ou étendent la classe abstraite ContextFuntion et vous permettent de créer un objet par instanciation paresseuse (par nécessité).

Dans Eclipse 4, vous avez a étendre la classe ContextFunction afin de recevoir IEclipseContext comme entrée de la méthode compute().

Les fonctions de contexte sont apportées comme services OSGi. Elle implémente l'interface IContextFunction du package org.eclipse.e4.core.contexts. L'environnement Eclipse 4 ajoute les fonctions de contexte par défaut au contexte de l'application.

Par le biais de la propriété service.context.key, elles définissent leur clé avec laquelle elles sont ajoutées au contexte.

L'utilisation de l'injection de dépendances pour vos propres objets Java a deux approches. D'abord, vous voulez que le conteneur de dépendance d'Eclipse crée vos propres objets et ensuite les injecte dans vos objets de modèle. Deuxièmement, vous voulez créer des objets qui déclarent leurs dépendances avec @Inject et vous voulez créer via l'injection de dépendance.

Les deux approches sont décrites ici.

Si vous voulez que le framework Eclipse crée vos objets pour vous, annotez-les avec @Creatable. De cette façon, vous demandez au conteneur ID Eclipse qu'il crée une nouvelle instance de cet objet s'il ne trouve pas une autre instance dans le contexte.

Le conteneur de l'Injection de Dépendance d'Eclipse va utiliser le constructeur de cette classe ayant le plus grand nombre de paramètres pour lesquels le conteneur de l'injection de dépendance Eclipse peut trouver des valeurs dans le contexte Eclipse. Vous pouvez également utiliser @Inject sur le constructeur pour indiquer à Eclipse qu'il devrait essayer d'exécuter l'injection de dépendance aussi pour ce constructeur.

Par exemple, supposons que vous ayez le modèle de domaine suivant.

@Creatable
class Todo {
 @Inject
 public Todo(Dependent depend, YourOSGiService service) {
     // placeholder
 }
}
 
@Creatable
class Dependent {
 public Dependent() {
 // placeholder
 }
}

Si aucun constructeur approprié n'est trouvé, le Framework Eclipse va lever une exception.

En supposant que vous ayez défini le service YourOSGiService dans votre application, vous pouvez obtenir une instance de votre modèle de données Todo injecté dans la part.

// Injection de champ
@Inject Todo todo

L'utilisation de l'injection de dépendances ne se limite pas aux objets créés par le runtime Eclipse. Vous pouvez utiliser @Inject dans une classe Java et utiliser le Framework d'injection de dépendance pour créer votre classe.

// instanciation de la classe
ContextInjectionFactory.make(MyJavaObject.class, context);

La méthode ContextInjectionFactory.make () crée l'objet. Vous pouvez aussi le mettre dans le contexte. Si vous voulez récupérer l'objet du contexte, vous pouvez utiliser la clé que vous avez spécifiée.

Pour cela, vous pouvez soit utiliser un contexte existant tel que décrit dans la dernière section ou un nouveau contexte. Utiliser un nouveau contexte est préférable afin d'éviter les collisions de clés et d'isoler vos modifications dans un contexte local.

IEclipseContext context = EclipseContextFactory.create();

// Ajoute vos objets Java au contexte
context.set(MyDataObject.class.getName(), data);
context.set(MoreStuff.class, moreData);

L'application peut utiliser le contexte Eclipse pour fournir des fonctionnalités, de la communication et modifier le comportement d'Eclipse. Vous avez plusieurs options pour contribuer au contexte : services OSGi, les fonctions de contexte, les éléments de contexte, les variables de contexte et addons du modèle.

Le mode de programmation d'Eclipse 4 rend relativement facile d'utilisation des services OSGi, par rapport à Eclipse 3.x. Les services OSGi sont des singletons et n'ont pas accès au contexte d'application Eclipse. Les services OSGi sont une bonne approche pour les services d'infrastructure qui sont des singletons.

Les fonctions de contexte sont des services OSGi qui sont généralement stockés au niveau de l'application et ils ont accès au contexte d'application Eclipse. Si cela est nécessaire, ils peuvent être utilisés à la place des services OSGi typiques.

Les éléments de contexte sont utiles, si des valeurs doivent être stockées à de certains endroits de la hiérarchie du contexte Eclipse. Remplacer les implémentations de la plate-forme Eclipse est également un bon motif d'utilisation des éléments de contexte, par exemple, pour modifier le handler par défaut qui ferme une fenêtre.

Les fonctions de contexte et les variables de contexte sont utiles dans les situations où les variables doivent changer et sont différentes pour les différents niveaux de la hiérarchie du contexte Eclipse.

Les addons du modèle vous permettent de faire participer des objets Java dans le contexte de l'application. L'avantage des addons du modèle est qu'ils font partie du modèle de l'application. Par conséquent, ils sont des éléments très visibles. Un addon de modèle peut s'inscrire lui-même aux événements ou contribuer à nouveau au contexte Eclipse.

Pour la communication portée sur l'interface utilisateur, il est recommandé d'utiliser des variables de contexte ou le service EventAdmin pour communiquer l'état.

Le service EventAdmin est un bon choix, s‘il n'y pas de périmètre associé dans la communication. Les points forts d'EventAdmin sont que des listeners arbitraires peuvent écouter les événements et que le mécanisme de publication/abonnement est relativement simple.

Si votre modèle d'application est essentiellement statique, vous devez le définir statiquement, de même que ce modèle statique vous offre une bonne visibilité de votre application durant le développement.

Si nécessaire, ajoutez un comportement dynamique. Ces parts dynamiques peuvent être évaluées à l'exécution avec l'éditeur de modèle temps réel.

Le modèle de programmation d'Eclipse 4 a réduit le recours aux points d'extension, mais ils restent toujours utiles dans certains cas.

Si vous avez plusieurs plug-ins qui doivent prendre part à une API définie, vous pouvez toujours définir et utiliser vos propres points d'extension.

Les plug-ins Eclipse déclarent explicitement leur API avec leurs packages exportés. Publiez uniquement les packages censés être utilisés par d'autres plug-ins. De cette façon, vous pouvez par la suite modifier votre API interne sans affecter les autres plug-ins. Évitez d'exporter des packages juste pour des tests.

OSGi permet de définir des dépendances par le biais de plug-ins ou de packages.

Les dépendances à base de packages expriment une dépendance d'API, car ils vous permettent d'échanger l'implémentation de plug-in. La dépendance à base de plug-ins implique une dépendance sur une implémentation.

Utilisez les dépendances de package à chaque fois que vous avez l'intention d'échanger la mise en œuvre du plug-in.

Les dépendances de package ajoutent de la complexité a la configuration habituelle, vous avez plus de packages que de plug-ins.

Par conséquent, utiliser la dépendance de plug-in, s'il n'y a qu'une seule implémentation de plug-in et un échange de ce plug-in, est peu probable dans un avenir proche.