|
(publié le 31/03/2006)
Présentation d'Eclipse RCP (Rich Client Platform)
Lors de sa création en 2001, le but du projet
Eclipse était de fournir un socle pour la création d'environnements
de développement.
Avec le lancement d'Eclipse RCP en 2004, l'objectif
du projet Eclipse a été étendu en prenant en compte
l'utilisation du framework Eclipse pour tous les types d'applications
clientes. Cette évolution a été demandée par
une partie de la communauté des utilisateurs d'Eclipse qui avait
commencé à réutiliser des portions d'Eclipse pour
le développement d'applications clientes (cf ci-contre).
Historiquement Eclipse RCP est née comme une version allégée
du framework Eclipse dont auraient été otés les modules
couvrant les besoins propres à la création d'un environnement
de développement. Techniquement, Eclipse RCP est la base sur laquelle
sont construits tous les projets Eclipse notamment l'environnement de
développement Java. Cette base est conçue comme un framework
utilisable pour des développements d'applications clientes dîtes
riches.
La notion d'applications riches
Bien que les applications intranet de types 'client léger'
se soient rapidement développées en entreprise il est maintenant
acquis qu'elles ne peuvent couvrir 100% des besoins. Certaines applications
ont des contraintes d'ergonomie, de rapidité, de complexité
ou encore d'intégration aux outils bureautiques que le client léger
ne peut satisfaire. Le terme 'applications riches', apparu pendant les
années 90 pour marquer l'évolution par rapport aux applications
accessibles par des terminaux passifs, regroupe actuellement deux grandes
familles technologiques :
 les
applications internet riches (RIA : Rich Internet Applications), qui
s'appuient sur l'utilisation d'un navigateur côté client
et exploitent soit les fonctionnalités évoluées des
navigateurs (DHTML comme dans la plupart des utilisations d'AJAX) soit
des extensions répandues (Flash, Java...). Les applications AJAX
se placent dans cette catégorie et sont une évolution concluante
dans le cadre d'internet (par exemple : GoogleMaps, GoogleMail, YahooMail
beta,...) mais leur généralisation en entreprise paraît
délicate (productivité, maintenabilité du JavaScript
et du DHTML, portabilité entre les navigateurs) et les limites
liées aux navigateurs continuent d'exister (notamment les problèmes
d'intégration avec les autres applications et le manque de performances
pour les interfaces graphiques complexes).
les
applications riches basées sur un socle applicatif à
installer sur le poste utilisateur, Eclipse RCP appartient à cette
catégorie qui est une évolution des architectures client/serveur
(1ére et 2ème génération) des années
90. Eclipse RCP apporte des solutions aux deux problèmes principaux
de ces architectures : la difficulté de distribution de l'application
sur les postes utilisateurs et la forte dépendanceà des
technologies propriétaires. Ces applications n'atteignent pas la
facilité de distribution du client léger, mais d'une part
des solutions sont proposées pour atténuer les problématiques
de l'installation initiale et de la gestion mises à jours, et d'autre
part ces applications proposent des avantages évidents pour l'utilisateur
: réactivé, richesse et qualité des interfaces graphiques,
souplesse avec la possibilité de fonctionner en mode déconnecté,
intégration poussée avec les autres applications installées
sur le poste.
Pourquoi Eclipse RCP ?
Deux raisons principales ont amené des utilisateurs
d'Eclipse à le considérer comme socle pour des applications
clientes :
la qualité
d'Eclipse. L'environnement de développement Eclipse s'est notamment
imposé par sa fiabilité et la qualité de ses interfaces
graphiques. L'utilisation massive de l'environnement de développement
Eclipse par la communauté des développeurs Java ainsi que
son utilisation comme base de produits commerciaux (WebSphere Studio,
SAP NetWeaver Studio...) ont permis d'éprouver le framework Eclipse.
la disponibilité
en open-source du framework Eclipse.
D'autres raisons ont renforcé l'adoptation d'Eclipse dans cette
optique d'applications riches :
- la culture 'framework' des principaux
contributeurs d'Eclipse dont le but initial était de fournir
un framework pour faire des environnements de développement.
Cette culture se traduit notamment par des efforts particuliers sur
la conception, sur la définition d'API stables et sur la documentation
du code. La caractéristique essentielle de la plate-forme Eclipse
est sa capacité à permettre la création d'applications
modulaires et extensibles.
- le choix du langage Java qui d'une part
offre la possibilité d'utiliser de nombreuses librairies (souvent
en open-source) et d'autre part permet d'assurer une cohérence
entre partie cliente et partie serveur (sachant que les serveurs d'applications
Java sont très présents en entreprise).
- la portabilité des applications
sur les principaux systèmes d'exploitation rencontrés
sur les postes clients (Windows, MacOS et Linux). Les principaux Unix
sont aussi supportés.
- la réactivité de la fondation
Eclipse qui a su répondre aux attentes de la communauté
en proposant Eclipse RCP et un outillage associé.
Des exemples d'applications basées sur Eclipse
RCP sont disponibles sur le site Eclipse :
- liste
d'applications open-source basées sur Eclipse RCP.
- liste
d'applications commerciales basées sur Eclipse RCP.
La fondation Eclipse propose aussi plusieurs
études de cas téléchargables au format PDF.
 |
|
Exemple d'applications Eclipse RCP
|
|
 Le cadre
graphique d'Eclipse RCP
SWT : Standard Widget Toolkit
Au moment de la conception d'Eclipse, en 1999, les équipes
d'IBM ont fait le constat que les librairies graphiques Java, AWT et Swing,
ne permettaient pas de produire des interfaces graphiques très
réactives et parfaitement intégrées au système
d'exploitation (NB : depuis Swing a beaucoup progressé en qualité).
Ayant jugé que ces deux caractéristiques étaient
essentielles pour un environnement de développement, ils ont fait
le choix d'implémenter leur propre librairie graphique : SWT.
Grâce à SWT, Eclipse a pu, dès sa première
version, offrir une interface graphique qui, notamment sur Windows, n'était
pas différenciable de celles des autres applications. A noter que
tous les composants graphiques Windows ont un équivalent SWT et
que SWT propose quelques composants spécifiques (cf. liste
des composants SWT)
L'aspect natif de SWT offre d'autres avantages :
- support des boîtes de dialogues standards
de chaque système d'exploitation (ouverture d'un fichier, impression
d'un document, ...).
- possibilité d'utiliser le composant SWT
Browser capable d'afficher des pages HTML en faisant appel au navigateur
le plus courant de chaque système d'exploitation (Internet Explorer
pour Windows, Mozilla/Firefox pour Linux ou Safari pour MacOS). Dans
le cadre d'applications Eclipse RCP, ce composant peut s'avérer
intéressant pour faire coopérer applications de types
'client riche' et 'client léger'.
- support de OLE/COM sur Windows, ce qui
permet une 'intégration étroite avec les applications
Windows.
Le développeur d'application Eclipse RCP choisira
généralement d'utiliser SWT pour bénéficier
de la même qualité graphique que l'environnement de développement
Eclipse. Mais il est intéressant de noter que SWT offre une solution
technique qui permet de mélanger composants Swing et SWT (cf. exemple
de code intégrant un composant JTable dans un composant SWT).
Le développement d'une application SWT est assez similaire à
celui des applications AWT et Swing : on y retrouve notamment la notion
de 'layout' et le même principe de gestion des évènements.
La librairie SWT s'interfaçant avec les composants
natifs, elle est constituée d'une partie de code Java commune à
tous les systèmes d'exploitation et d'une partie native propre
à chaque système d'exploitation. Sur Windows cette partie
native, composée de trois fichiers DLL, fait à peu près
400Ko, son déploiement est complètement transparent car
ces DLL sont intégrées dans un des fichiers JAR d'Eclipse.
JFace
JFace vient compléter SWT en proposant les fonctionnalités
suivantes :
Le support
du modèle MVC (Modèle-Vue-Controleur) via la notion
de 'Viewer'. Les 'Viewers' JFace encapsulent des composants SWT et gèrent
le lien entre ces composants graphiques et des objets contenant les données
à afficher.
La notion
de 'commandes' qui permet une gestion configurable des raccourcis
clavier ainsi que la gestion du 'Undo/Redo'.
Des boîtes
de dialogues personnalisées. SWT encapsule les boîtes
de dialogue standards des systèmes d'exploitation, JFace propose
des boîtes de dialogue complémentaires et simples d'utilisation.
JFace propose notamment une boîte de dialogue avec barre de progression
et une autre pour développer des assistants (Le developpeur
implémente avec du code SWT le contenu de chaque page de l'assistant
et JFace gère le reste de l'aspect graphique notamment les boutons
de navigation entre les pages de l'assistant).
|
Exemple d'assistant JFace
|
|
Le 'workbench' Eclipse
L'apport le plus visible du framework Eclipse RCP et
le cadre graphique proposé : le 'workbench'. Son utilisation reste
optionnelle mais il est généralement une des raisons principales
du choix d'Eclipse RCP. En effet en réutilisant les éléments
du workbench (notions de vues, pages de préférences, boîtes
de dialogues de types assistants, construction des menus par déclaration
dans un fichier XML...) le développeur se voit offrir une solution
de qualité couvrant les besoins de base d'une applications clientes
et peut se concentrer sur les choses vraiment spécifiques à
son application.
Les principales notions proposées par le workbench
sont :
Les
vues
Les vues sont des sous-fenêtres de la fenêtre
principale du workbench. Les vues contiennent des composants SWT, le développeur
a donc une complète liberté sur le contenu de chaque vue.
Le workbench gère l'affichage des vues et permet à l'utilisateur
de l'application de les manipuler.
Les caractéristiques de chaque vue sont configurables par le développeur
(affichage d'une barre de titre, possibilité de fermer la vue,
de la déplacer, de l'empiler, de la réduire, ...) Dans le
cadre de l'environnement de développement Eclipse les vues sont
essentiellement utilisées pour afficher des informations mais dans
le cadre d'une application Eclipse RCP les vues peuvent aussi être
utilisées pour faire de la saisie (il n'y a pas de contrainte technique
sur les composants graphiques utilisable dans une vue).
Les
éditeurs
La notion d'éditeur est naturellement centrale
dans l'environnement de développement Eclipse, c'est le cas notamment
de l'éditeur de code Java. Dans une application Eclipse RCP, l'utilisation
d'éditeurs est intéressante mais reste facultative (la notion
de vue peut s'avérer suffisante). On peut distinguer trois principaux
types d'éditeurs : les éditeurs de texte (comme l'éditeur
de code Java), les éditeurs de type formulaire de saisie
plus courants dans le cadre des applications Eclipse RCP et les éditeurs
graphiques (par exemple affichant des diagrammes).
Les
perspectives
Le workbench est basé sur un principe de fenêtre
unique découpée en sous-fenêtres (les vues et
les éditeurs) auxquelles s'ajoutent généralement
une barre de menu, une barre de boutons et une zone de status. La notion
de perspective permet de proposer un agancement particulier de vues et
optionnellement d'une zone d'édition.
Dans le cadre de l'environnement de développement Eclipse, les
perspectives permettent d'organiser la fenêtre en fonction des tâches
de l'utilisateur (Développement Java, Déboguage, ...). Une
application Eclipse RCP peut utiliser le même principe, elle peut
aussi ne pas exposer la notion de perspective à l'utilisateur (l'affichage
de la barre de boutons de navigation entre les perspectives est paramétrable).
De la même façon, le principe de fenêtre unique n'est
pas une obligation pour une application RCP car le framework Eclipse n'empêche
en rien l'ouverture de plusieurs fenêtres.
Exemple : utilisation de la barre de perspective
dans une application Eclipse RCP (projet SchoolClipse)
Les
pages de préférences
Le stockage de paramétrages propres à l'utilisateur
est un besoin courant. La fenêtre de gestion des préférences
d'Eclipse est réutilisable dans une application RCP. Le développeur
utilise SWT pour implémenter chaque page et bénéficie
de la gestion par Eclipse de la navigation dans l'arbre des pages, du
filtrage de cette arbre et du stockage des informations sur le disque.
La base
du framework Eclipse : la notion de plugin
Le principal objectif des concepteurs d'Eclipse était
de proposer un framework modulaire et extensible. A la base
du framework Eclipse se trouve donc un 'micro-noyau' responsable de la
gestion du cycle de vie des modules (découverte, chargement, mise
à jour, déchargement…). Ces modules sont appelés
'plugins'. Le framework Eclipse est lui même entièrement
découpés en plugins. C'est aussi le cas de toutes les applications
basées sur Eclipse RCP.
Les plugins coopérent de deux façons :
par
dépendance : un plugin peut utiliser les classes Java d'un
autre plugin (sous conditions).
par
extension : un plugin peut enrichir un autre plugin en déclarant
une extension. La déclaration d'une extension se fait en XML.
Chaque plugin peut prévoir des 'points d'extension' sur
lequels d'autres plugins viendront se brancher en définissant des
extensions. Par exemple le plugin qui gère la barre de menu
du workbench prévoit un point d'extension qui permet à d'autres
plugins de venir enrichir le menu.
La notion d'extension est centrale dans le framework Eclipse. Dans le
cadre d'une application Eclipse RCP c'est le moyen utilisé pour
déclarer des vues, des éditeurs, des pages de préférences,
des assistants...
Chaque plugin est composé de ses propres classes Java et surtout
de deux fichiers de configurations :
Le
fichier MANIFEST.MF qui contient les informations permettant au micro-noyau
de gérer le plugin (nom, version, liste de plugins pré-requis,...).
Le format de ce fichier est décrit dans le cadre du consortium
OSGi. La fondation Eclipse
participe à ce consortium et le micro-noyau d'Eclipse est une implémentation
conforme aux spécifications OSGi depuis Eclipse 3.
Le
fichier plugin.xml qui permet d'utiliser les notions d'extension et
de point d'extension. Ce fichier est propre au framework Eclipse et n'est
donc pas décrit dans le cadre d'OSGi.
Les applications basées sur Eclipse RCP bénéficient
directement de l'extensibilité de la plateforme et deviennent elles-mêmes
extensibles de deux façons :
l'application
peut être étendue simplement par l'ajout de nouveaux plugins
qui complètent notamment l'interface graphique (ajout de menus,
de pages de préférences, d'assistants...).
l'application
peut exploiter la notion de point d'extension en proposant ses propres
points d'extension sur lesquels viendront se brancher des plugins complémentaires.
Les outils
pour le développement des applications Eclipse RCP
Le PDE : Plugin Development Environment
Le développement d'une application Eclipse RCP
se fait en grande partie en utilisant l'outillage Java standard d'Eclipse
(Editeur de code, débogueur...). Toutefois certaines tâches
sont propres au développement de plugins ou d'applications Eclipse
RCP, pour simplifier ces tâches Eclipse intègre des outils
spécifiques regroupés sous le terme PDE (Plugin Development
Environment). Les principales fonctionnalités proposées
par le PDE sont :
un assistant
de création de plugin.
un éditeur
pour les fichiers de configuration de plugin. Cet éditeur permet
notamment de configurer les dépendances entre plugins et il propose
une assistance pour la déclaration d'extensions et de points d'extension.
un assistant
pour l'exécution et le déboguage des plugins
et des applications RCP.
des assistants
pour l'export des plugins et des applications Eclipse RCP. Dans
le cas des applications Eclipse RCP l'assistant d'export utilise les informations
saisies dans un éditeur appelé 'éditeur de produit'.
En utilisant cet éditeur le développeur va pouvoir préciser
des points de détails qui permettent de donner un caractère
professionnel à l'application, ce sont notamment le nom de l'exécutable
à générer, l'icône de l'exécutable,
l'icône de la fenêtre principale du workbench, l'image à
afficher pendant le lancement, l'image et le texte apparaissant dans le
fenêtre 'A propos de ...'.
Le Visual Editor
Une partie des développements d'une application
Eclipse RCP consiste à créer des interfaces graphiques en
utilisant les librairies SWT et JFace. Pour faciliter ce travail, la fondation
Eclipse propose un constructeur d'interfaces graphiques : le Visual
Editor. Cet outil est développé dans le cadre d'un
sous-projet particulier. La version actuelle du Visual Editor permet
de construire des interfaces graphiques SWT et prend en compte les notions
de vues et d'éditeurs utilisées dans les applications Eclipse
RCP.
Les autres
composants utilisables dans une application Eclipse RCP
Afin de limiter la taille du framework Eclipse RCP (6Mo),
les fonctionnalités intégrées de base dans Eclipse
RCP sont le micro-noyau gérant les plugins et la notion de workbench.
Cependant tous les composants disponibles sous la forme de plugins Eclipse
sont utilisables dans une application Eclipse RCP. C'est notamment le
cas des plugins qui composent l'environnement de développement
Eclipse mais aussi ceux développés dans le cadre de sous-projets
Eclipse ou de d'autres projets open-source.
Parmi les composants souvent utilisées dans les
applications Eclipse RCP on peut noter :
La
gestion de l'aide. Ce composant provient de l'environnement de développement
Eclipse. A partir de fichiers d'aide écrits en HTML et d'une table
des matières décrites en XML les fonctionnalités
suivantes sont proposées : affichage de l'aide dans une fenêtre
séparées ou dans une vue du workbench, recherche dans l'aide,
gestion d'un index et gestion de l'aide contextuelle (chaque composant
SWT peut être associé à une section de l'aide).
La
gestion des mises à jour. Ce composant provient de l'environnement
de développement Eclipse, il permet le téléchargement
et l'installation de nouveaux plugins ou la mise à jour des plugins
déjà installés. Il est utilisable par une interface
graphique proposée à l'utilisateur de l'application ou par
programmation (dans ce cas le développeur de l'application Eclipse
RCP choisi quand déclencher des mises à jour).
D'autres composants répondent à des besoins
plus spécifiques :
Le composant
'Ressources' qui provient de l'environnement de développement.
Ce composant propose notamment la vue 'navigateur' qui permet à
l'utilisateur de manipuler un ensemble de projets composés de répertoires
et de fichiers.
Le composant
'Editeur de texte' qui provient aussi de l'environnement de développement
et qui peut servir de base à tout éditeur de fichiers au
format texte. Il propose notamment les mécanismes de formattage,
d'assistance à la saisie, de coloration et de gestion des annotations.
GEF
(Graphical Editing Framework). Proposé dans le cadre d'un
sous-projet particulier, ce composant est un framework pour développer
des éditeurs graphiques (affichage et manipulation de formes et
de textes en deux dimensions)
Conclusion
Avec Eclipse RCP la fondation Eclipse propose un socle
open-source solide pour la création d'applications clientes. Les
applications basées sur Eclipse RCP bénéficient directement
de la modularité et de l'extensibilité de ce socle. Sur
le plan visuel, la notion de Worbench ainsi que les librairies SWT et
JFace permettent la création d'interfaces graphiques de qualité.
Lancé en 2004, Eclipse RCP s'annonçait comme un projet prometteur,
Les premiers retours d'expérience montrent qu'Eclipse RCP est une
solution utilisable dès aujourd'hui. La feuille de route de la
fondation Eclipse pour 2006 consacre Eclipse RCP comme étant un
des objectifs majeurs de la fondation.
Plus d'informations :
- La page d'Eclipse
RCP.
- Les
news d'EclipseTotale concernant Eclipse RCP.
|
Consulter l'actualité du projet Eclipse
