Un article de azerr    6 Commentaires

A l’étape du billet précédant [step16] nous avons finalisé la palette d’outils GEF qui permet de créer des states, des actions et des connections entre actions et states.

Dans ce billet je souhaitais dans un premier temps expliquer comment mettre en place la fonctionnalité « suppression de state, actions, connections » dans la page GEF Graphics, à l’aide de la touche « Suppr » ou à l’aide d’une action d’un menu contextuel. Je me suis inspiré des exemples GEF qui sont basés sur un EditorPart simple (une seule page GEF) pour intégrer cette fonctionnalité de delete dans notre editor multi page de workflow (MultiPageEditorPart) et je me suis rendu compte que nous ne pouvions pas encore mettre en place cette fonctionnalité de delete avant d’avoir régler le problème de sélection des EditPart GEF (pour ensuite les supprimer avec l’action delete). La selection d’EditPart GEF ne fonctionne pas dans notre cas car :

1. le code générée par EMF concernant la sélection d’items (ISelectionProvider) dans l’editor multi page WorkflowEditor obstrue la selection d’un item provenant d’une autre page non générée par EMF (qui n’utilise pas ViewerPane EMF). Par exemple, dans le cas de notre editor GEF la selection d’un EditPart GEF est obstruée. Pour plus d’informations sur ce sujet, voir la section GEF GraphicalViewer – ISelectionProvider.
2. nous sommes dans un contexte de multi page et que l’editor GEF org.eclipse.gef.ui.parts.GraphicalEditor ne fonctionne pas dans un multi page concernant le sujet de la selection d’EditPart. Nous réglerons ce problème dans le prochain billet.

Pour mettre en évidence le premier problème, mettez un point d’arrêt dans la méthode GraphicalEditor#selectionChanged(IWorkbenchPart part, ISelection selection), sélectionnez un state, action de la page GEF Graphics et vous pourrez constater que cette méthode n’est jamais appelé :

Nous expliquerons dans le prochain billet l’importance de ce code qui réagit à la selection des EditPart GEF, et qui permet de gérer les actions de delete des EditPart GEF sélectionné.

Pour expliquer le 2ème problème, il faut que le premier soit résolu et mettez ensuite un point d’arrêt à la fin de la méthode GraphicalEditor#selectionChanged(IWorkbenchPart part, ISelection selection) ( appel de updateActions) et vous pourrez constater que le point d’arrêt ne s’arrête jamais.

Pour résoudre le premier problème, je me suis appuyé sur l’excellent article Integrating EMF and GMF Generated Editors qui explique pas à pas comment intégrer un editor GEF généré par Graphical Modeling Framework (GMF) dans un multi page editor généré par EMF.

A la fin de ce billet, lorsque nous sélectionnerons un state, action, connection, cette sélection s’affichera dans la barre de statut (ce qui à ce stade ne fonctionne pas).

Vous pouvez télécharger le projet org.example.workflow_step17.zip présenté dans ce billet.

EMF – MultiPageEditorPart

EMF est capable de générer à partir d’un genmodel, un editor multi page MultiPageEditorPart constitué de plusieurs pages capable de mettre à jour un modèle EMF. Un MultiPageEditorPart est un EditorPart constitué de plusieurs pages qui peuvent être :

• un Control SWT qui peut être ajouté au multi page editor via la méthode MultiPageEditorPart#addPage(Control control). Les pages générées par EMF sont basées sur un org.eclipse.emf.common.ui.ViewerPane qui construit en interne un Control SWT (accéssible via la méthode ViewerPane#getControl()) et qui est ajouté à l’editor multi page.
• un EditorPart (ex : notre EditorPart GEF) qui peut être ajouté au multi page editor via la méthode MultiPageEditorPart#addPage(IEditorPart editor, IEditorInput input)

Notre éditor multi page WorkflowEditor en est un exemple d’editor multi page générée par EMF. Dans l’introduction de ce billet nous avons évoqué le problème de selection d’items. Pour regler ce problème nous devons effectuer des modifications du code générée par EMF qui va suivre les étapes décrites dans l’article Integrating EMF and GMF Generated Editors. Le lien Integrating EMF / GMF editors article – comments est un commentaire effectué sur cet article qui est aussi très intéressant de lire.

L’idée générale des modifications à effectuer dans le code générée par EMF est :

• d’utiliser un MultiPageSelectionProvider au lieu de l’implémentation de ISelectionProvider générée par EMF (le WorkflowEditor lui même).
• Le MultiPageSelectionProvider impose le fait d’avoir des EditorPart, ce qui implique de transformer les ViewerPane EMF en EditorPart.

Dans ce billet je vais suivre les mêmes étapes que l’article Integrating EMF and GMF Generated Editors :

• Dissecting the EMF Editor qui permettra d’utiliser des EditorPart au lieu des ViewerPane.
• Selection Handling qui permettra d’utiliser un MultiPageSelectionProvider au lieu des WorkflowEditor qui implémente ISelectionProvider.
• Combining the Editors qui corrigera le problème de la synchronisation de la page Selection avec la Outline.

Dissecting the EMF Editor

Ici nous allons effectuer la même chose que ce qui est expliqué dans la section Dissecting the EMF Editor de l’article GMF. L’idée est de ne plus utiliser les ViewerPane EMF mais d’utiliser les EditorPart. En effet nous souhaitons utiliser un MultiPageSelectionProvider dans notre editor, ce qui implique que chacune des pages doivent être des EditorPart (et pas des Control SWT). Le code MultiPageSelectionProvider#getSelection()

montre que ce ISelectionProvider fonctionne qu’avec des IEditorPart.

Nous allons transformer uniquement la page Selection basée sur un ViewerPane en EditorPart. Les autres pages n’existeront plus dans notre editor. Mais nous allons quand même créer une classe de base (basé sur EditorPart) qui gère la plupart des problèmetque du ViewerPane, si jamais vous souhaitez ajouter les autres pages dans votre cas (je vous conseille de regarder l’article qui explique comment faire). Cette classe de base est identique (presque) à TopicmapEditorPart expliqué dans l’article.

Créer la classe org.example.workflow.presentation.parts.AbstractWorkflowEditorPart comme suit :

Créer la classe org.example.workflow.presentation.parts.SelectionEditorPart comme suit :

Cette classe gère la même chose que la page Selection basé sur un ViewerPane.

Dans la classe WorkflowEditor, définissez un champs selectionEditorPart

private SelectionEditorPart selectionEditorPart;

Dans la méthode WorkflowEditor#createPages() supprimez tout le code qui utilise les ViewerPane et remplacez le par le code suivant :

Nous pouvons maintenant supprimer les méthodes WorkflowEditor#setCurrentViewerPane(ViewerPane viewerPane) et WorkflowEditor#setFocus(). La ré-implementation de WorkflowEditor#isDirty() peut être aussi enlevée.

Selection Handling

A cette étape si vous relancez le plugin et que vous sélectionnez un state, action dans le Treeview de la page Selection, la vue Properties n’est pas rafraîchit correctement. La selection d’items ne fonctionnent plus. Ici nous allons effectuer la même chose que ce qui est expliqué dans la section Selection Handling de l’article GMF. L’idée est d’utiliser un MultiPageSelectionProvider en tant que ISelectionProvider au lieu du WorkflowEditor lui même (qui implémente ISelectionProvider).

Dans la classe WorkflowEditor, ajoutez le champs de type org.eclipse.ui.part.MultiPageSelectionProvider :

private MultiPageSelectionProvider selectionProvider;

Modifiez le constructueur de WorkflowEditor comme suit :

Ce code permet d’instancier le MultiPageSelectionProvider. Un listener est branché dessus pour détecter les changement de selection (ex : selection d’un item du Treeview de la page Selection, selection d’un EditPart GEF) et afficher le resultat de la selection dans la barre de statut (en bas à gauche du workbench).

WorkflowEditor ne doit plus implémenter ISelectionProvider :

Maintenant nous pouvons supprimer tout le code qui implémente l’interface ISelectionProvider : supprimez les champs selectionChangedListener, selectionChangedListeners et editorSelection et supprimez les méthodes WorkflowEditor#addSelectionChangedListener(ISelectionChangedListener listener) WorkflowEditor#removeSelectionChangedListener(ISelectionChangedListener listener), WorkflowEditor#getSelection() et WorkflowEditor#setSelection(ISelection selection).

Commentez dans la méthode WorkflowEditor#handleChangedResources() le code suivant :

L’utilisation du ISelectionProvider s’effectue via le IEditorSite. Modifiez le code de la méthode WorkflowEditor#init(IEditorSite site, IEditorInput editorInput) pour pouvoir utiliser notre MultiPageSelectionProvider :

Pour information, Un EditorPart possède un org.eclipse.ui.IEditorSite qui joue le rôle d’interface entre le workbench et un editor part. IEditorSite est accessible via la méthode EditorPart#getSite() (plus exactement WorkbenchPart#getSite()). C’est à travers IEditorSite que l’on renseigne par exemple :

• les menu contextuels (registerContextMenu) disponibles dans l’EditorPart.
• les actions disponibles (getActionBars) dans le menu globale du workbench (lorsque l’editor est sélectionné).
• le fournisseur de selection org.eclipse.jface.viewers.ISelectionProvider de l’editor via la méthode EditorPart#setSelectionProvider(ISelectionProvider provider).

Modifiez la méthode WorkflowEditor#handleActivate() pour pouvoir utiliser notre MultiPageSelectionProvider :

Modifiez WorkflowEditor#setCurrentViewer(Viewer viewer) qui n’a plus besoin de gérer la selection (branchement/débranchement des listener ISelectionChangedListener) :

Relancez le plugin et assurez vous que la vue Outline n’est pas ouverte, maintenant lorsque vous sélectionnez un EditPart GEF dans la page Graphics, la selection de ce dernier doit s’afficher dans le barre de statut :

Vous pouvez aussi vérifier que lorsque vous sélectionnez un item du Treeview dans la page Selection, la selection doit aussi s’afficher dans la barre de statut.

Combining the Editors

Ouvrez la vue Outline via le menu Window/Show view/Outline, mettez vous sur la page Selection, puis sélectionnez un item de la Outline. Le Treeview de la page Selection, n’est pas synchronisé avec la vue Outline :

Le problème vient de la méthode WorkflowEditor#handleContentOutlineSelection() qui teste entre autre si la variable currentViewerPane n’est pas null. Dans notre cas elle est toujours null (car elle était mise à jour par le code générée que nous avons supprimé).

Ici nous allons effectuer la même chose que ce qui est expliqué dans la section Combining the Editors de l’article GMF

Pour régler ce problème, supprimez le champs currentViewerPane

 //protected ViewerPane currentViewerPane;

et modifiez le code comme suit :

Ce code gère la selection de la page Selection et des autres pages qui hériterait de AbstractWorkflowEditorPart. Ici nous ne gerons ni la page source, ni la page Graphics. Relancez le plugin et vous pourrez constater que la Treeview de la page Selection est synchronisée avec le Treeview de la vue Outline :

GEF – Selection EdiPart

Les modifications de code sont finies dans ce billet. Dans cette section je vais tenter d’expliquer le problème de selection d’EditPart GEF avec le code générée par EMF.

GEF GraphicalViewer – ISelectionProvider

Nous avons modifié le code pour utiliser MultiPageSelectionProvider (et plus que WorkflowEditor implémente ISelectionProvider). Mais pourquoi devons nous faire ca? Ici je vais tenter d’expliquer pourquoi l’utilisation de MultiPageSelectionProvider règle le problème de selection des EditPart GEF.

Lorsqu’un EditPart GEF est sélectionné (clic de la souris sur un state, action, connection de la page Graphics GEF), le viewer GEF GraphicalViewer associé à l’editor GEF GraphicalEditor est capable de détecter l’EditPart sélectionné et notifie les listeners qui ont été préalablement enregistrés qu’un/plusieurs EditPart a/ont été sélectionnés. Le viewer GEF joue le rôle d’un fournisseur de sélection (il implémente l’interface org.eclipse.jface.viewers.ISelectionProvider) sur lequel on peut brancher des listeners org.eclipse.jface.viewers.ISelectionChangedListener qui souhaitent être informés des EditPart sélectionnés.

La méthode qui nous intéresse pour comprendre le probléme de selection dans GEF engendré par le code générée EMF est AbstractEditPartViewer#fireSelectionChanged() de la classe org.eclipse.gef.ui.parts.AbstractEditPartViewer :

Cette méthode est appelée dès qu’un ou plusieurs EditPart GEF sont sélectionnés et appelle pour chacun des listeners qui implémente la méthode ISelectionChangedListener#selectionChanged(SelectionChangedEvent event) de l’interface ISelectionChangedListener. Si vous mettez un point d’arrêt dans la méthode AbstractEditPartViewer#fireSelectionChanged(), vous pourrez constater que 2 listeners ISelectionChangedListener sont enregistrés :

• org.eclipse.gef.ui.parts.SelectionSynchronizer : qui d’après la javadoc GEF est utilisé pour synchroniser les selection entre plusieurs viewer GEF (ce qui n’est pas notre cas).
• org.eclipse.ui.part.MultiPageEditorSite : qui est l’IEditorSite de notre multi page editor. Plus exactement c’est la méthode privée MultiPageEditorSite#getSelectionChangedListener() qui joue le rôle de listener.

Le listener qui nous intéresse est le deuxième (MultiPageEditorSite). Voici le code de MultiPageEditorSite#getSelectionChangedListener() :

Lorsqu’une selection d’un EditPart GEF est effectuée, le méthode MultiPageEditorSite#handleSelectionChanged de la classe MultiPageEditorSite est appelée. Voici son code :

Le test qui nous intéresse est

if (parentProvider instanceof MultiPageSelectionProvider) ...

Il vérifie que le fournisseur de sélection du multi page editor (dans notre cas WorkflowEditor) est de type MultiPageSelectionProvider. Ce test n’est jamais vrai avec le code générée par EMF car le fournisseur de selection le multi page WorkflowEditor lui-même. En effet si on regarde le code générée par EMF de notre multi page editor WorkflowEditor, cette dernière implémente ISelectionProvider

et indique que le fournisseur de selection de son IEditorSite (qui est un MultiPageEditorSite) est lui-même dans la méthode WorkflowEditor#init(IEditorSite site, IEditorInput editorInput) :

Par défaut un MultiPageEditorPart utilise un MultiPageSelectionProvider mais le code générée par EMF n’utilise pas de MultiPageSelectionProvider ce qui rtend obsolète la sélection des EditPart GEF.

GEF GraphicalEditor – ISelectionChangedListener

Après avoir modifiez le code pour pouvoir utiliser un MultiPageSelectionProvider, mettez un point d’arrêt dans la méthode GraphicalEditor#selectionChanged#selectionChanged(IWorkbenchPart part, ISelection selection), et vous pourrez constater que le point d’arrêt s’arrête :

Si on regarde la trace on peut voir que la méthode MultiPageSelectionProvider#fireSelectionChanged() est appelé qui appelle la méthode MultiPageSelectionProvider#fireEventChange(final SelectionChangedEvent event, Object[] listeners) :

La méthode fireEventChange :

itère sur la liste des listeners enregistrés.

Le listener qui nous intéresse est le service de selection (AbstractSelectionService) qui est enregistré dans les listeners et qui appelle la méthode GraphicalEditor#selectionChanged#selectionChanged(IWorkbenchPart part, ISelection selection),.

GEF utilise le service de selection. Le GraphicalViewer GEF jour le rôle du fournisseur de selection ISelectionProvider et l’editor GEF GraphicalEditor jour le rôle du consommateur de selection (ISelectionChangedListener). Ce dernier s’abonne au service de selection dans sa méthode init :

Pour plus d’information sur l’utilisation du service de selection je vous conseille de lire l’article Eclipse Workbench: Using the Selection Service.

L’editor GEF GraphicalEditor enregistre le fournisseur de selection GraphicalViewer via le MultiPageEditorSite comme ceci :