Documentation Technique : SoCQ GUI

Transcription

1 Documentation Technique : SoCQ GUI Julien Deflaux 1 er août

2 TABLE DES MATIÈRES 2 Table des matières 1 Présentation du SoCQ GUI Présentation Découpage du GUI en projets Modèle-Vue-Contrôleur avec GEF MVC : Modèle-Vue-Contrôleur GEF : Graphical Editing Framework Modèles Modèle? La classe Node? Description de la structure des modèles Vues Contrôleurs Commandes GEF CreateContent Plugin Eclipse RCP : SoCQ GUI WorkBench Eclipse Le projet à l instant initial MANIFEST.MF, plugin.xml : configuration du projet L éditeur La vue Outline Le menu et la barre d outils Le menu contextuel La feuille de propriétés Editeur de requêtes SWT vs Swing Points clés de l éditeur de requêtes Etat d avancement Gestion des tuples Eléments à développer Plugin nécessaires au fonctionnement du GUI

3 1 PRÉSENTATION DU SOCQ GUI 3 1 Présentation du SoCQ GUI 1.1 Présentation Le projet SoCQ (Service-oriented Continuous Query) vise à gérer des services dans un cadre de requêtes continues. Les informations détaillées sur ce projet ne seront pas abordées ici, et seules certaines notions pouvant être utiles seront abordées. Ce document ne permet donc que de décrire les choix techniques faits, uniquement pour la partie interface homme machine du moteur. L application GUI (Graphic User Interface) du moteur SoCQ a été développée dans le but de représenter les tables et les requêtes manipulées par le moteur. Il a donc été choisi de représenter les éléments de ce modèle en utilisant l abstraction Modèle-Vue-Contrôleur (MVC). Ce qui signifie qu à chaque modèle correspond une visualisation graphique, le lien entre les deux étant effectué par le contrôleur. L application doit aussi gérer les requêtes de l utilisateur. Pour cela, il faut utiliser le parseur de requêtes SoCQ. La documentation du parseur et de la grammaire font l objet d un autre document. Dans ce document le parseur sera utilisé et intégré au GUI, et non décrit. Il en va de même pour la grammaire du langage SoCQ, basée sur le SQL. Pour utiliser le concept MVC, il a été choisi de développer l application en JAVA sous forme de plugin Eclipse RCP (Rich Client Platform). Le choix du JAVA a été fait pour pouvoir utiliser le framework fourni par Eclipse RCP. En effet, Eclipse dès sa création en 2001 avait pour but de créer un socle pour la création d environnements de développement. Avec la création du projet Eclipse RCP en 2004, l objectif était de fournir un Framework de développement pour tous types d applications clientes. Contrairement aux applications légères qui trouvent vite leurs limites, l application riche étant basée sur le moteur d Eclipse permet de fournir des outils très complets au développeur et à l utilisateur, notamment pour ce qui concerne la qualité des GUI, la réactivité, la portabilité et l installation de l application sur différents postes et types de systèmes d exploitation. 1.2 Découpage du GUI en projets Pour plus de compréhension et pour faciliter la maintenance du GUI, il a été découpé en plusieurs sous projets. La notion de projets est liée directement à Eclipse. En fait, le GUI est découpé principalement en 3 projets :

4 2 MODÈLE-VUE-CONTRÔLEUR AVEC GEF 4 BaseData : Contient la classe Data, nécessaire pour manipuler les types des Attributs, et la classe Tuple qui correspond à la classe représentant les tuples dans le GUI. ExtendedData : Contient le parseur, les types de données à représenter ( Table, BindingPattern, Schema et Attribute) et les modèles Query correspondant au modèle renvoyé par une requête Select From Where. GUI : contient l ensemble du projet décrit dans ce document. Il utilise chacun des deux autres projets et c est aussi lui qui contient l application qui est exécutée en tant que plugin. L utilisation de l ensemble des tutoriels très complets sur la création d un plugin RCP utilisant GEF fournit par Jean Charles MAMMANA [1], peut être une aide fort utile comme point de départ. 2 Modèle-Vue-Contrôleur avec GEF Pour comprendre la structure utilisée dans le GUI il convient de lire les deux parties suivantes pour bien comprendre le concept de Modèle-Vue- Contrôleur et pour comprendre ce qu est GEF. 2.1 MVC : Modèle-Vue-Contrôleur Le concept de Modèle-Vue-Contrôleur est basé sur une notion assez simple pour manipuler et représenter n importe quel type de données. En outre il est utilisé ici pour représenter les tables, les SchemaSoCQ, les attributs et les BindingPatterns, qui chacun vont correspondre à un modèle particulier. L affichage de ces modèles est géré de manière indépendante. Ensuite pour faire le lien entre le contenu du modèle et son affichage on utilise la notion de contrôleurs. Les contrôleurs permettent de répercuter les changement du modèle sur son affichage ( sa vue ) et vice-versa. Schématiquement la Figure1 montre le lien entre les différentes composantes du concept MVC. 2.2 GEF : Graphical Editing Framework Pour implémenter ce concept de Modèle-Vue-Contrôleur, Eclipse fournit un outil nommé GEF (Graphical Editing Framework). GEF fournit principalement : Des vues génériques (Figure)qui permettent d implémenter des vues pour chaque modèles. Celles-ci peuvent être intégrées facilement au plugin Eclipse. Des contrôleurs génériques (EditPart) permettants de faire le lien entre le modèle et la vue.

5 2 MODÈLE-VUE-CONTRÔLEUR AVEC GEF 5 Figure 1 Model-View-Controler En ce qui concerne les modèles il n y a pas à proprement parler de classes génériques proposées par GEF. Ça correspond plus à une structure de données à utiliser. Cette structure est expliquée et détaillée dans la section 2.3. On pourra se référer au tutoriel d Eclipse sur l utilisation de GEF pour créer une application de gestion de Tables UML [6]. 2.3 Modèles Tous les modèles utilisés par le GUI sont présents dans le package : fr.cnrs.liris.socq.gui.model Modèle? Les modèles sont indépendants de GEF, ce qui permet donc de représenter à peu près ce que l on veut. La condition est que certaines primitives doivent être définies pour assurer la cohérence du modèle vis-à-vis des requis de GEF pour les vues à afficher et les contrôleurs. Dans le cadre du GUI, les modèles héritent tous d une classe de base nommée Node qui contient ces opérations primitives liées à l utilisation de GEF La classe Node? La classe dont dérive tous les modèles est la classe Node représentée sur la Figure2 avec uniquement ses attributs publics, qui nous intéressent ici. La classe Node permet de représenter chacun des éléments de la hiérarchie de modèles, hiérarchie de type arbre. Les attributs children et parent représentent respectivement le tableau de fils de l instance en cours et le Node parent. Chaque Node possède un name, qui sera le nom affiché par la vue. De plus un attribut de type Rectangle permet de stocker la position de la vue. Cet attribut s éloigne du concept de modèle au sens MVC, car le modèle devrait être parfaitement indépendant de son affichage. Mais dans

6 2 MODÈLE-VUE-CONTRÔLEUR AVEC GEF 6 Figure 2 Classe Node notre contexte pour gérer le placement des Tables et des BindingPatterns, il est nécessaire de gérer leurs positions. Remarque : Une évolution du GUI pourrait être de supprimer cet attribut layout pour que la manipulation des modèles soit parfaitement indépendantes de leurs représentations. GEF fournis un outil de Layout ( voir section 2.4 ) pour générer un placement automatique des objets à partir d un algorithme basé sur la notion de graphes, mais complexe à mettre en oeuvre. Les attributs listeners et propertysource sont nécessaires dans la section 3.1 pour la gestion des feuilles de propriété Eclipse. Les méthodes de la classes Node ne seront pas commentées ici, mais dans le code directement. Chaque modèle hérite donc de la classe Node Description de la structure des modèles Les modèles initiaux à représenter sont les tables, schema, binding patterns, et attributes, comme définis dans le package : fr.cnrs.liris.socq.model.extended.data. Les modèles correspondants à chacun de ces "modèles initiaux" sont sufixés de "Model". Ainsi on retrouve par exemple la classe TableModel qui correspond au modèle initial Table. Deux choix se sont présentés pour représenter ces "Model" : Faire hériter chacun de ces Model de son modèle initial et lui faire implémenter une Interface Node correspondant à ce que pourrait être une Interface de la classe Node décrite précédemment. Faire hériter chacun des Model de la classe Node, et encapsuler son modèle initial. A première vue le premier choix peut sembler le mieux adapté, car il évite de créer en mémoire des doublons d une même instance. De plus il parait

7 2 MODÈLE-VUE-CONTRÔLEUR AVEC GEF 7 aussi plus simple à manipuler car la modification du Model ne doit pas être répercutée sur son Model initial présent en attribut. Cependant le choix a été porté sur la deuxième structure, car il s avère plus simple à gérer et seuls les classes AttributeModel et TableModel encapsulent leurs modèles initiaux. De plus, cela rend cohérend le fait que la TableModel contient un attribut concernant sa description des données et un attribut concernant sa liste de tuples. Les concepts de DDL et DML Statements sont bien distincts. Remarque : La classe SchemeModel est le modèle qui contient l ensemble des Tables à afficher. Chacune de ces tables est un élément fils (cf classe Node) du scheme. Elle correspond à ce que pourrait être un modèle du Schema de Base de données. Remarque : La classe Compartment contenue dans ce package, hérite elle aussi de la classe Node et permet d ajouter un étage dans la hiérarchie des modèles. Elle n a pas d autre utilité. 2.4 Vues Toutes les vues utilisées par le GUI sont présentes dans le package : fr.cnrs.liris.socq.gui.figure Les vues sont issues d une librairie utilisée par GEF, nommée Draw2D. Cette librairie fournit des gestionnaires de figures et de calques (notion de hiérarchie). On pourra se référer au tutoriel de Daniel Lee concernant l utilisation des vues [3]. Elle permet uniquement de gérer l affichage de modèles et non leur édition. Elle fournit notamment de quoi gérer l affichage de modèles si ceux-ci sont établis sous forme hiérarchique. Cette notion de représentation hiérarchique est donc ici très utile pour représenter par exemple les tables qui contiennent un Schema, qui contient lui-même des attributs. Chaque vue hérite de la classe Figure fournie par GEF. GEF fournit différentes façon de gérer les couches (Layout) à afficher. A chaque figure est associé un layout. Les différents layouts utilisés par le GUI sont : XYLayout permettant de gérer manuellement la position de la figure en cours. Cette classe est la classe de base des layout. ToolbarLayout permet de gérer les éléments pères qui ont besoin d afficher les sous-élèments qu ils contiennent. Ce type de layout est utilisé pour les TableFigure et BindingPatternFigure. Il est entre autre possible de définir l alignement et le positionnement des éléments fils affichés. Ceci étant géré à l affichage, il ne faut donc pas instancier les éléments fils en leur précisant une position (cf. section2.7)

8 2 MODÈLE-VUE-CONTRÔLEUR AVEC GEF 8 A chaque figure peuvent être associés des composants de GEF, comme par exemple les Label permettant d afficher du texte. 2.5 Contrôleurs Tous les contrôleurs utilisés par le GUI sont présents dans le package : fr.cnrs.liris.socq.gui.editpart Les contrôleurs permettent de faire le lien entre les vues et les modèles. C est-à-dire que dans le programme seuls sont manipulés les modèles. Il faut donc pouvoir mettre à jour l affichage de ces modèles lors d éventuelles modifications. Par exemple, on change le nom d une table pour une quelconque raison, il faut que la vue correspondante à cette table soit mise elle aussi à jour. Un des points important concernant les contrôleurs est qu à chaque modèle sont associées des parties éditables qui sont susceptibles d être modifiées et donc mises à jour. GEF fournit une classe nommée EditPart servant à représenter les contrôleurs et donc à faire le lien entre ces parties éditables du modèle et leur affichage. Le GUI travaille avec des modèles qui sont destinés à être affichés. Il utilise donc comme super classe pour chacun de ses EditPart la classe GraphicalEditPart qui sert à gérer les contrôleurs dont le modèle correspond obligatoirement à une visualisation. Pour propager les changements chaque EditPart du GUI agit comme un récepteur et chaque modèle comme un émetteur d événements. AppAbstractEditPart est la classe dont hérite chacun des EditPart de ce package. Cette superclasse hérite de la classe AbstractGraphicalEditPart fournie par GEF et implémente PropertyChangeListener pour la gestion des listeners. Les Listeners permettent de capter les changements du modèle via la méthode propertychange et de rafrachir l affichage de ces modèles via la méthode refreshvisuals. La sélection : Lorsqu une figure est sélectionnée, GEF manipule son Edit- Part. Donc si on sélectionne un élément graphique, ce qui sera compris comme étant sélectionné par GEF est l EditPart. Cette remarque est utile pour la section 3.6 sur la gestion des Handler. De plus la méthode getcontentpane quand elle est implémentée permet de définir où seront ajoutés les nouveaux éléments graphiques ( à l intérieur de quels composants graphiques). Ce qui est pratique pour les TableFigure et BindingPatternFigure pour placer les éléments dans le CompartmentFigure de leur figure respective. L intérêt de placer les éléments fils dans ce

9 2 MODÈLE-VUE-CONTRÔLEUR AVEC GEF 9 CompartmentFigure et non directement comme fils de ces Figures est que sinon les éléments fils sont affichés au dessus du titre, or on veut que le titre soit au dessus. Remarque : La classe SchemaPart implémente la méthode getdragtracker, issue de AbstractGraphicalEditPart dont elle hérite, qui permet de redéfinir quel EditPart est renvoyé lorsqu un SchemaPart est sélectionné. Il faut en effet renvoyer la TablePart quand on clique sur un Schema, sinon le seul moyen de sélectionner une table serais de cliquer sur le cadre bleu de la table, ce qui n est pas évident quand il n est pas visible! 2.6 Commandes GEF Toutes les commandes GEF utilisées par le GUI sont présentes dans le package : fr.cnrs.liris.socq.gui.commands.gef GEF propose d utiliser des commandes pour gérer ses modèles. Mais que sont des commandes GEF? Lors d une interaction entre l utilisateur et une des vues représentant un modèle, chaque interaction est interprétée par GEF comme une requête de classe Request. Ces requêtes sont interceptables par le contrôleur correspondant au modèle. Lors de l interception d une de ces requêtes on peut associer une Commande GEF à un type de requête. Par exemple lors du double clic sur une table on souhaite qu une action soit exécutée. Cette action correspond à la commande GEF. Une autre façon d utiliser les commandes est d associer au modèle un rôle qui sera interprété par GEF et en fonction du rôle sera associé une politique d édition EditPolicy au modèle via le contrôleur. Par exemple si l utilisateur veut bouger une vue correspondant à un modèle, il faut associer à l EditPart une politique d édition de layout via la méthode createeditpolicies. Une fois la figure déplacée, il faut de plus transmettre les changements au modèle. C est ce que se charge de faire l Edit- Policy en exécutant la commande GEF approprié au modèle sélectionné qui permettra de capter les changements de la vue et de les transmettre au modèle. Les classes correspondant aux EditPolicies sont dans le package : fr.cnrs.liris.socq.editpolicies 2.7 CreateContent La classe CreateContent est présente dans le package fr.cnrs.liris.socq.gui. Ses méthodes permettent de générer des modèles à partir d une requête. Une description détaillée de cette classe serait trop fastidieuse, il vaut mieux

10 3 PLUGIN ECLIPSE RCP : SOCQ GUI 10 s en référer au code directement. 3 Plugin Eclipse RCP : SoCQ GUI Eclipse RCP permet de développer des plugins qui viendront s ajouter aux plugins existant d Eclipse [2]. Un plugin Eclipse est basé sur le moteur d Eclipse et a par conséquent besoin de celui-ci. Une application Eclipse RCP est différente d un plugin RCP dans le sens où, elle peut être exécutée sans qu il n y ai une instance visible d Eclipse. Ce qui peut permettre de créer un stand-alone, indépendant d Eclipse, ou tout du moins, qui se lance sans que l utilisateur sache qu il lance le moteur d Eclipse. Cette notion de plugin sous Eclipse est très importante, car le noyau d Eclipse est construit sous forme d imbrication de plugins. Pour avoir une aide dans la création de plugins utilisant GEF on pourra se référer au document fourni par IBM [2]. 3.1 WorkBench Eclipse Le WorkBench d Eclipse est la partie visible du framework proposé par Eclipse RCP (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 application cliente et peut se concentrer sur les choses vraiment spécifiques à son application. Les principales notions proposées par le WorkBench sont : Les Vues : elles permettent de visualiser le modèle en temps Réel. Dans le cadre du GUI il y a 2 vue de définies : la vue Outline où l on retrouve la hiérarchie des Tables et la mini-vue qui permet d avoir une représentation réduite de l ensemble des Tables. Les Editeurs : Ils permettent de modifier en temps réel un modèle. Dans le cadre du GUI il s agit d un éditeur graphique basé sur GEF. Les Feuilles de propriétés : Il s agit de la feuille de propriété qui permettent de modifier chacun des attributs ainsi que certaines propriétés des tables. Les Perspectives : Il s agit de la disposition de l ensemble du workbench. Dans le cadre du GUI il y a par exemple la feuille de propriété qui est affichée dans le cadre inférieur gauche.

11 3 PLUGIN ECLIPSE RCP : SOCQ GUI 11 Les Points d extensions : Pour créer un plugin et lui faire utiliser une partie du moteur d Eclipse, il faut définir des points d extension. Les points d extension permettent simplement d étendre et redéfinir certaines fonctionnalités d Eclipse au plugin. Par exemple le plugin qui gère la barre de menu 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 Le projet à l instant initial Lors de la création d un projet plugin RCP, certaines classes sont générées automatiquement par Eclipse. La structure des fichiers est représenté par la figure3. Figure 3 Structure initiale d un projet plugin Les différents points importants à repérer sont les suivants : le fichier plugin.xml qui contient les informations de configuration du plugin, le package fr.cnrs.liris.socq.gui qui contient les classes vitales à l exécution du plugin. Le fichier MANIFEST.MF contient lui aussi des informations liées au plugin(dépendances, version...) et le fichier build.properties contient les informations de compilation. 3.3 MANIFEST.MF, plugin.xml : configuration du projet Eclipse propose un éditeur pour modifier les fichiers plugin.xml et MA- NIFEST.MF ensembles et de manière visuelle[5]. Cet éditeur est représenté sur la figure 4.

12 3 PLUGIN ECLIPSE RCP : SOCQ GUI 12 Figure 4 Editeur Eclipse de plugin.xml

13 3 PLUGIN ECLIPSE RCP : SOCQ GUI 13 Overview : L onglet Overview permet de définir quelques informations générales du projet, tel que son nom sa version, et son ID. L ID permet d identifier l application lorsqu elle est exécutée. En effet, elle sera lancée en tant que nouveau plugin d Eclipse, et ce même si elle s exécute dans une nouvelle fenêtre, il faut donc qu Eclipse puisse identifier sans ambiguïté cette application. Il est alors important d utiliser, dans les différentes classes le nécessitant, un ID unique pour éviter les conflits. La Classe Activator est générée automatiquement et permet de lancer le plugin lorsqu il est sous OSGi. Normalement il n y a rien à modifier. Dependencies : Permet de définir quels plugins sont requis pour que le GUI soit exécuté. Il faut notamment les plugins GEF, ExtendedData(pour le parseur) et BaseData(pour la gestion des types) Runtime : Permet de définir quels packages du plugin sont visibles par les autres plugins. Extensions : Permet de définir les points d extensions que le plugin étend. C est dans cet onglet qu est géré la perspective, l éditeur, les menus, et les handlers de déclenchement de commandes GEF. Chacun de ces points est un point d extension du WorkBench Eclipse, il faut donc définir sous forme XML(l éditeur est la pour simplifier la tâche) comment utiliser ces points d extension. Le point d extension Menu, permet de définir les différents menus : contextuel (popup), de la barre de menu (toolbar), et du menu déroulant (menu). La compréhension du fonctionnement pour rajouter une action à un de ces menu est intuitive. Ce qu il faut savoir c est à quelle commande de l extension commande est associée une action du menu. Le point d extension Commande permet donc d associer à chacune des actions du menu une commande définit dans ce point d extension. Chaque commande est ensuite implémentée par un handler( et non une commande au sens GEF ) présent dans le package fr.cnrs.liris.socq.commands. Chaque Handler va être déclenché lors de son activation, lors de l utilisation du menu, et celui ci va ensuite déclencher les commandes GEF associées à sa fonction. Par exemple le Handler LoadFileHandler va lancer la commande GEF LoadCommand du package fr.cnrs.liris.socq.commands.gef. Remarque : Il est donc très facile d ajouter/modifier/supprimer une action au GUI à l aide de ces points d extensions, sans aller toucher au code.

14 3 PLUGIN ECLIPSE RCP : SOCQ GUI 14 Extension Points : Permet de définir quels points d extensions le plugin offre d étendre aux autres plugins. Build : Permet de définir quels fichiers joindre à l archive lors de la compilation. Cette fonction est intéressante si on souhaite exporter l application et qu il faut par exemple inclure les icônes à l archive exportée. Les onglets restants permettent de voir le contenu des fichiers édités dans les onglets précédents. 3.4 L éditeur Il est contenu dans le package : fr.cnrs.liris.socq.gui Il est composé de 2 classes : SoCQEditorInput et SoCQGraphicalEditor. SoCQEditorInput permet de faire le lien entre le Worbench Eclipse et l éditeur personnalisé de l application GUI. Il n y a rien a modifier à l intérieur en règle générale. SoCQGraphicalEditor permet de gérer tout l affichage graphique de l éditeur. Cette classe possède un attribut ID qui permet d identifier l éditeur SoCQ, pour préciser au WorkBench quel éditeur choisir. Cet ID est utilisé pour la configuration du plugin dans la section 3.3. L éditeur permet de modifier le SchemeModel représentant l ensemble des tables. Il contient donc un attribut SchemeModel représentant ce modèle à gérer. La méthode initializegraphicalviewer est appelée au lancement de l éditeur et permet de créer son contenu, initialement vide, à l aide de la Classe CreateContent. La méthode configuregraphicalviewer est aussi appelée au lancement de l éditeur, et permet de configurer les menus et zoom, et de lui associer les EditPart SoCQ définis dans la classe EditPartFactory ( cf Section 2 ). Lors d une modification de l Editeur, le fait que celui-ci ai été modifié est sauvegardé dans le booléen dirty. Lorsque l application doit se fermer( appel de dispose() ), il y un appel à la méthode isdirty() pour vérifier si l éditeur a été modifié et si c est le cas, il y a un appel à la méthode dosave. Il convient donc de modifier cet attribut lors des modifications du SchemeModel.

15 3 PLUGIN ECLIPSE RCP : SOCQ GUI 15 La gestion du zoom ( les commandes ) est faite dans la méthode configuregraphicalviewer. Cependant il y a aussi une miniature dans la vue Outline de l ensemble de l éditeur. Cette miniature est créée dans une class embedded à SoCQGraphicalEditor qui s occupe de gérer la vue Outline. 3.5 La vue Outline Cette vue est définie dans la classe Outline, class embedded à SoCQ- GraphicalEditor du package fr.cnrs.liris.socq.gui. Il s agit d implémenter la vue qui définie la représentation hiérarchique des modèles, ainsi que la vue miniature de l ensemble de l éditeur. Remarque : La classe Outline aurait pu faire l objet d une classe séparée, mais dans ce cas il aurait fallu pouvoir capter les répercutions d un changement du modèle présent dans l éditeur. C est tout à fait possible en mettant en place des listeners, comme c est le cas pour les EditPart qui répercutent les changements du modèle sur la vue, mais cela complique le code pour un élément non significatif. La classe Outline crée le TreeViewer ( nécessaire à l affichage du Scheme- Model de l éditeur sous forme d arbre hiérarchique )dans sa méthode createcontrol. Toutes les classes relatives au TreeViewer sont dans le package : fr.cnrs.liris.socq.gui.editpart.tree Il faut remarquer que le TreeViewer a besoin de la Factory AppTreeEditPartFactory, qui permet d associer en fonction du modèle à représenter la TreeEditPart correspondante et définie dans le package cité ci dessus. Chacun des modèles a sa propre TreeEditPart dans ce package. TreeEditPart est une classe générique offerte par GEF et permettant de faire le lien entre le modèle et sa représentation sous forme d arbre. Principalement 3 méthodes sont utilisées : refreshvisuals permet de mettre à jour le nom et l icône du modèle dans l affichage du TreeViewer. propertychange permet de capter les changements du modèles et de les répercuter sur son affichage, tout comme dans la section Modèle- Vue-Contrôleur 2 page 4. performrequest Lie une commande GEF en fonction de la requête effectuée par l utilisateur sur la TreeView. Remarque : La classe SchemaTreeEditPart implémente getmodelchildren pour permettre de ne pas afficher le Compartment AttributeList dans l arbre hiérarchique représentant les modèles. On gagne ainsi un niveau dans la représentation hiérarchique.

16 3 PLUGIN ECLIPSE RCP : SOCQ GUI Le menu et la barre d outils La gestion de l affichage du menu déroulant ainsi que la de la barre d outils est définie dans le fichier plugin.xml. Pour une explication sur son fonctionnement, se reporter à la section 3.3 page 11. Chacune des actions du menu est associée à un Handler[4] présent dans le package fr.cnrs.liris.socq.commands Le lien entre le Handler, les commandes GEF et le reste du programme est illustré sur la figure5 [4]. Figure 5 Lien entre les différentes extensions d Eclipse Le Handler permet de lancer excecute() lorsqu il est sollicité. Lors du lancement de cette méthode, on peut capter quel élément sont sélectionnés dans l éditeur, et ainsi choisir d effectuer ou non l action sur ce modèle. Remarque : Une évolution pourrait consister à implémenter les méthodes isenable() et ishandled() des Handlers pour autoriser dynamiquement ou non l action dans les menus. La difficulté vient en général du fait qu autoriser ces actions est lié au modèle sélectionné dans l éditeur et que pour capter celui ci on a besoin d un Event, non présent en paramètre d entrée de ces méthodes. Une façon de procéder pourrait être d émettre des évènements dans l éditeur lui même lorsqu il y a des modifications.

17 3 PLUGIN ECLIPSE RCP : SOCQ GUI 17 Le package fr.cnrs.liris.socq.gui.actions permet de définir à la main de façon "oldschool" les menu. Cependant il a été nécessaire pour faciliter l insertion du bouton Delete et des choix du Zoom. Il faut définir chacune des commandes à utiliser dans le menu, gérer leur affichage, etc...chose que le fichier plugin.xml permet de simplifier depuis la version 3.3 d Eclipse (cf. section 3.3 page 11). 3.7 Le menu contextuel La gestion de l affichage du menu contextuel est définie dans le fichier plugin.xml. Pour une explication sur son fonctionnement, se reporter à la section 3.3 page 11. La partie description de l affichage étant définie dans ce fichier, il faut aussi préciser où on veut l insérer. Pour cela il faut l ajouter dans l éditeur, c est-à-dire dans le fichier SoCQGraphicalEditor (cf section 3.4 page 14). Il est ajouté dans la méthode configuregraphicalviewer. 3.8 La feuille de propriétés L entière gestion de la feuille de propriété s effectue dans la classe Node- PropertySource du package fr.cnrs.liris.socq.gui.model. Comme les autres outils fournis par le WorkBench, la feuille de propriété est un point d extension dans le fichier plugin.xml ( cf section 3.3). La feuille de propriété se gère principalement au travers de 3 méthodes : getpropertydescriptors() permet de définir quel type d objet issue de org.eclipse.ui.views.properties sera utilisé pour une propriété d un élément sélectionné dans l éditeur. On peut par exemple crée des PropertyDescriptor ( classe de base pour visualiser la valeur sans qu elle soit éditable), des TextPropertyDescriptor ( pour visualiser et permettre de modifier la valeur), des ComboBoxPropertyDescriptor ( pour afficher la valeur et permettre la sélection dans un menu déroulant). Le choix se fait en fonction du type de l objet. Chaque PropertyDescriptor est créé avec un flag qui permet d identifier le type de propriété à utiliser et modifier. getpropertyvalue() qui permet de récupérer la valeur d un élément et de la mettre dans son PropertyDescriptor. setpropertyvalue qui permet de répercuter les changements de la valeur sur le modèle.

18 4 EDITEUR DE REQUÊTES 18 4 Editeur de requêtes L éditeur de requête est définie dans le package : fr.cnrs.liris.socq.commands.dialog Il permet d étier des requêtes et de voir le résultat du parseur ( vérification syntaxique et sémantique ) à la volée. Comme il s agit d une nouvelle fenêtre, il a été fait le choix d utiliser Free SWTDesigner de Instantiations 1,logiciel à licence libre permettant de gérer la disposition des éléments graphique de nouvelles fenêtres. 4.1 SWT vs Swing Pour gère l affichage de nouvelles fenêtres, en java "natif", il convient d utiliser la librairie Swing. Cependant le choix a été fait d utiliser SWT, librairie proposée par Eclipse et crée par IBM. Swing : permet de gérer l affichage de nouvelles fenêtre en émulant des fenêtres. Ce qui a plusieurs conséquences. Sous n importe quel système d exploitation, la fenêtre aura le même rendu. Il s ensuit principalement une perte de rapidité, liée à l émulation et une interface finalement mal appropriée pour chaque système d exploitation. L avantage est que son utilisation peu paraître plus simple et l interface reste identique quelque-soit le système d exploitation. SWT : Face aux lacune de la librairie Swing, IBM a décidé de développer sa propre librairie, nommée SWT. Celle ci est utilisable et est la librairie qui permet de gérer l affichage d Eclipse (car ne l oublions pas Eclipse est écrit en JAVA). Les avantages sont multiples, il n est plus question d émulation système, chaque fenêtre est appelée avec une API système. A cela plusieurs avantages, sous chaque système, l utilisateur retrouve l interface à laquelle il était habitué, il n y a plus de perte de rapidité lié à l émulation. Au final l utilisation de SWT n est pas forcément bien plus compliquée que celle de Swing. Donc pour le développement de ce plugin, il y avait tout intérêt à développer avec SWT. 4.2 Points clés de l éditeur de requêtes La gestion de la vérification :L éditeur de requêtes s occupe simplement de vérifier la syntaxe et la sémantique d une String. Il ne crée pas les objets correspondants. Ces objets sont créés par la classe CreateContent (cf. section 2.7 page 9). Cet éditeur permet juste de récupérer la String une fois celle ci correctement vérifiée. 1.

19 5 ETAT D AVANCEMENT 19 La gestion visuelle : Il est recommandé d utiliser le plugin SWTDesigner pour modifier et visualiser simplement la fenêtre. Le redimensionnement est géré à l aide d un listener qui capte les changements de taille de la fenêtre et qui répercute ce changement sur tous ses contenus que chacun va répercuter en chaîne sur leurs contenus. Le parseur est présent en attribut de la classe pour éviter de le créer a chaque touche tapée. Pour capter l appui d une touche, il faut placer un listener sur la modification du texte du querytext. les cases à cocher permettent d activer ou pas les différents types de vérification. Chaque case correspond à un booléen qui est consulté lorsque le listener d écoute de frappe capte une modification du texte de la requête. La vérification sémentique est effectuée en donnant au parseur l ensemble des Tables présentent dans l éditeur SoCQ. L ensemble de ces tables est donc mis en paramètre du constructeur de la fenêtre. De plus si une nouvelle table est crée dans la requête et qu ensuite on choisi de faire une requête sur cette table, la vérification sémantique incluera cette Table, mais cela sera lié au fonctionnement du parseur ( cf. Doc Parseur). L utilisation des listeners est apportée par la librairie SWT. 5 Etat d avancement Cette section décrit succintement les différents points concernant le GUI qui ne sont pas totalement terminés et qui méritent d être approfondis. 5.1 Gestion des tuples Actuellement, le GUI peut gérer les tuples. A savoir : Insertion de tuples dans une table à l aide des requêtes de DML Statement. Visualisier/Ajouter/Modifier/Supprimer les tuples à l aide d une nouvelle boite de dialogue, dans le même style que la boite de saisie de requête à la volée (Voir classe TableViewer du package fr.cnrs.liris.socq.commands.dialog). Les différents points techniques concernant cette gestion de tuples ne sont pas expliqué ici en détail, le code est suffisant pour la compréhension du TableViewer. Il faut juste savoir que les tuples sont représentés pour chaque TableModel par un vecteur de Tuple. Il est possible d accéder à cette boite via le handler AddTupleHandler. Limites et points à développer pour la gestion de tuples :

20 5 ETAT D AVANCEMENT 20 Les tuples "vides" sont remplacés par des chaines de charactère vide. Cette limitation pourra peut être géner quand il faudra insérer les tuples dans le moteur SoCQ. Gérer dans le TupleViewer la suppresion de tous les tuples. Gérer dans le Tupleviewer le non ajout de tuples Virtual. Dans la méthode verifycurrenttext du Table Viewer, ajouter une vérification sur le type des tuples. Lorsqu on crée un nouveau tuple via le bouton adéquat dans le Table- Viewer, il faudrait faire afficher la nouvelle ligne en surbrillance pour pouvoir la remarquer. 5.2 Eléments à développer Certains points méritant d être approfondis ont été abordés dans ce document au travers des Remarque. Voici en complément différentes limitations actuelles du GUI et des points à développer : Gérer le chargement/sauvegarde vers le moteur SoCQ. Gérer la suppresion de tuples via les requêtes(cf Doc Parseur). Rajouter des propriétés, ou en rendre certaiens éditables pour différents modèles ( comme par exemple les BindingPatterns ). Gérer les menus pour pour qu il ne soient actifs que quand on peut les excécuter. Ajouter la possibilité de mettre des commentaires dans les fichiers de Sauvegarde : dans la classe LoadCommand, la méthode lecture permet de lire ligne par ligne le fichier. Rajouter un test si la ligne commence par alors l ignorer. La gestion des connections entre modèles est ébauchée dans le ConectionModel et ConnectionPart, il faudrait développer la rendre fonctionnelle. 5.3 Plugin nécessaires au fonctionnement du GUI GEF[6] : Nécessaire pour utiliser le GUI. Une explication est donnée à l adresse FAQ#Download_and_Install ou directement sur le site GEF http: // SWT Designer de Instanciation : Necessaire pour modifier les boites de dialogue, index.html

21 RÉFÉRENCES 21 Références [1] Jean Charles MAMMANA alias Psykokwak. 13 tutoriels gef, http: // [2] eclipsetotale.com. Présentation d eclipse rcp (rich client platform), [3] Daniel Lee IBM. Draw2d - display a uml diagram, eclipse.org/articles/article-gef-draw2d/gef-draw2d.html. [4] David Kyle. New menu contribution extension, new-menu-contribution-extension.html. [5] Lars Vogel. Configuration du plugin - eclipse rcp with eclipse ganymede, [6] Phil Zoio. Gef - building a database schema diagram editor, gef-schema-editor.html.