Un article de azerr    2 Commentaires

Dans le billet précédant [step3] nous avons mis en place les Translator WST pour les élements state et action et leur attribut name. Les attributs fromState et toState des actions qui font références a des states n’ont pas encore été mis en place. Dans ce billet, nous allons :

• Mettre en place les Translator WST pour les attributs fromState et toState de action.
• Ajouter une page Source avec un TextEditor qui utilisera StructuredTextEditor de WST.

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

Translator fromState – toState

A l’étape du billet précédant [step3], les translators pour gérer les attributs fromState et toSate n’ont pas été mis en place. Pour effectuer ce test, ouvrez le fichier My.workflow dans l’editor Workflow Model Editor puis ouvrez ce même fichier dans l’éditor de text (Open With Text Editor) et mettez ces 2 éditors côte à côte :

Vous pouvez constater que la vue properties n’affiche pas les 2 states s1 et s2. Ceci s’explique par le fait que les Translator n’ont pas été mis en place pour les attributs fromState et toState et que par conséquent l’instance EMF ActionType n’est pas synchronisée avec les 2 attributs.

WorkflowTranslator

Pour gérer les 2 attributs fromState et toState nous devons modifier WorkflowTranslator pour gérer les 2 cas suivants :

• la mise à jour de l’attribut name d’un state doit :
  • mettre à jour l’instance StateType avec la valeur de l’attribut name de state (ceci est déja fait)
  • indiquer que l’attribut name est un ID EMF (via la Resource EMF)

  Ceci s’effectue à l’aide de la classe MyIDTranslator que nous allons créer.

• l’attribut fromState est mappé avec le name d’un StateType retrouve par son ID EMF (name de StateType). Ceci s’effectue à l’aide de la classe HRefTranslator que nous allons créer.

StateType – MyIDTranslator

En EMF, il est possible de mettre en ID une instance EMF via la Resource EMF de type org.eclipse.emf.ecore.xmi.XMLResource comme ceci :

et retrouver l’instance EMF par ID comme ceci :

et retrouver l’ID d’une instance EMF comme ceci :

Nous dans notre cas, nous voulons identifier l’instance EMF StateType par son nom, autrement dit faire :

WST propose une classe org.eclipse.wst.common.internal.emf.resource.IDTranslator qui d’après son code est capable de mettre
en ID une instance EMF avec le nom XML id. Je n’ai pas bien compris l’utilité de ce translator car :

1. le nom XML de l’attribut est forcé à id. Dans notre cas nous voulons mettre name et pas id
2. ce translator gère uniquement l’ID EMF de l’instance EMF (dans la Resource EMF) et PAS la mise à jour de l’instance EMFavec la valeur de l’id (dans notre cas la mise à jour de name de StateType)

Autrement dit quand l’attribut name de state change nous devons exécuter le code suivant :

Créer la classe org.example.workflow.model.util.MyIDTranslator comme suit (j’ai repris tel quel le code de IDTranslator et j’ai ajouté l’étape 1. Here we update emfObject with value) et j’ai commenté la méthode getMOFValue (pour qu’elle utilise le name de StateType et pas son ID car lors d’une création d’un StateType on ne met pas à jour l’ID et cette méthode retourne toujours null) :

Modifier ensuite la méthode WorkflowTranslator#createStateTranslator() pour utiliser maintenant notre classe MyIDTranslator (et plus Translator) comme ceci :

ActionType – HRefTranslator

A cette étape les StateType peuvent être récupérés par leur name en utilisant les ID EMF via la Resource EMF. Nous pouvons gérer les translator pour fromState et toState qui doivent rechercher les StateType par ID correspondant au nom des attributs fromState/toState. Pour gérer ceci, créer la classe org.example.workflow.model.util.HRefTranslator (je me suis inspiré de la classe org.eclipse.wst.common.componentcore.internal.util.HRefTranslator et je l’ai simplifié) comme suit :

Modifier ensuite la méthode WorkflowTranslator#createActionTranslator() pour utiliser maintenant notre classe HRefTranslator pour gérer ls translators avec les attributs fromState et toState : :

Vous pouvez ensuite relancer le plugin, et constater que l’instance EMF est bien synchronisée avec les attributs XML fromState et toState:

Modifier l’attribut XML toState avec s1 et vous pourrez constater que l’instance EMF se synchronise avec l’attribut XML toState (sans être obligé de sauvegarder) :

Modifier l’instance EMF via la vue properties en sélectionnant State Type s2 et vous pourrez constater que l’attribut XML toState se synchronise avec l’instance EMF avec la valeur s2 (sans être obligé de sauvegarder) :

Modifier l’attribut XML toState avec s3 qui n’est pas un state existant et vous pourrez constater que l’instance EMF a un StateType null :

Page Source – StructuredTextEditor

WST fournit un editeur texte qui est capable de gérer un modèle SSE org.eclipse.wst.sse.ui.StructuredTextEditor qui éténd la classe org.eclipse.ui.editors.text.TextEditor (éditeur texte de base). L’éditeur XML de WST est basé sur org.eclipse.wst.sse.ui.StructuredTextEditor. Nous allons ajouter une page source dans notre éditeur de workflow à l’aide de cette classe pour donner la possibilité de saisir le contenu XML du workflow :

Dependance StructuredTextEditor

Pour utiliser org.eclipse.wst.sse.ui.StructuredTextEditor il faut tout d’abord ajouter la dépendance org.eclipse.wst.sse.ui : ce plugin contient les classes org.eclipse.wst.sse.ui.StructuredTextEditor.

Ajout StructuredTextEditor dans WorkflowEditor

La classe WorkflowEditor doit être modifiée :

1. ajout champs sourcePage :
     private StructuredTextEditor sourcePage = null;
2. Ajout de la méthode createAndAddSourcePage :
   private void createAndAddSourcePage() {
       sourcePage = new StructuredTextEditor();
       sourcePage.setEditorPart(this);
       try {
         int index = addPage(sourcePage, getEditorInput());
         setPageText(index, "Source");
       } catch (PartInitException e) {
         e.printStackTrace();
       }
     }
3. Appel de la méthode createAndAddSourcePage dans la méthode createPages qui permet de créer les pages de l’éditeur multi-page WorkflowEditor :
   public void createPages() {
   ...
   // Add source page
       createAndAddSourcePage();
   ...

Voici le code de WorkflowEditor :

ATTENTION a bien mettre les @generated NOT pour ne pas écraser les modifications effectuées lors de la prochaine re-génération.

Gestion dirty

A cette étape si on modifie le contenu XML dans l’éditeur texte de la page source, cette opération n’influe pas sur l’état dirty de l’éditeur de workflow. En effet si vous tappez un caractère dans la page source, l’état dirty (qui devrait se mettre a true) de l’éditeur est toujours à false. L’éditeur considère qu’il n’y donc pas eu de modification et il est impossible de sauvegarder le nouveau contenu XML :

L’état dirty est gérée par la méthode WorkflowEditor#isDirty() dont voici son code :

Je parlerai plus en détail de ce code dans le billet suivant step5. Ce code signifie que l’état dirty est géré en fonction de l’état isSaveNeeded d’une stack de commandes. Cette stack de commande est en faite mise à jour lorsque le modèle EMF est modifié via toutes les pages (Selection, Parent, List….) et la vue properties. Par exemple si vous modifiez le nom d’un StateType via la vue properties, une commande EMF de type org.eclipse.emf.edit.command.SetCommand est créée et ajouté à la stack. Cette commande permet de modifier le nom de l’instance StateType sélectionée. En d’autres termes la vue properties ne modifie pas directement le name de l’instance StateType, mais elle ajoute une commande EMF à la stack de commande de l’editing domain EMF. Cette command est ensuite executée et c’est elle qui met à jour l’instance EMF. Ce mécanisme de stack de commande permet de gérer le undo/redo de l’éditeur de workflow. Seul les pages qui modifie l’instance EMF via l’edting domain bénéficie des opérations undo/redo. La page source qui est composée d’un éditor StructuredTextEditor ne met jamais à jour cette stacke de commande quand l’utilisateur saisit du contenu XML dans l’éditeur texte. Pour prendre en compte l’état dirty de l’éditor StructuredTextEditor, il faut modifier le code comme suit :

Ce code signifie que l’éta dirty vaut true si :

1. Il y a eu une modification de l’instance EMF via l’edting domain.
2. OU via la page source (éditeur de texte à dirty).

Cependant si on souhaite dans le futur ajouter une nouvelle page qui contient un autre éditeur (ex : éditeur GEF graphique), il faudra modifier ce code. Il est possible de dire que l’on souhaite effectuer ce mécanisme pour toutes les pages de type org.eclipse.ui.IEditorPart (comme StructuredTextEditor) en appelant MultiPageEditorPart#isDirty() (WorkflowEditor éténd de MultiPageEditorPart) :

Voici le code de MultiPageEditorPart#isDirty() :

Par conséquent modiifier le code WorkflowEditor#isDirty() comme ceci :

ATTENTION a bien mettre les @generated NOT pour ne pas écraser les modifications effectuées lors de la prochaine re-génération.

On se retrouve avec le même code que l’éditeur de JSF Webtools.

Gestion sauvegarde

A cette étape la sauvegarde ne fonctionne toujours pas. Nous avons toujours l’exception :

Je n’ai pas apronfondi la question concernant La ligne de code EMF2DOMSSERenderer.java:250 qui pose problème :

ResourceSetWorkbenchEditSynchronizer synchronizer = (ResourceSetWorkbenchEditSynchronizer) ((ProjectResourceSet) resource.getResourceSet()).getSynchronizer();

Pour régler ce problème nous allons déléguer la sauvegarde à l’editeur de texte StructuredTextEditor de la page source. Je sais que ce choix fera hurler plus d’un qui préféreait sauvegarder l’instance EMF, mais j’ai fait le choix de sauvegarder ce que saisit l’utilisateur quitte à ce que le contenu XML saisi ne soit pas valide.

Pour cela modifier la méthode WorkflowEditor#doSave(IProgressMonitor progressMonitor) comme suit :

Cette modification consite à :

1. mettre en commentaire la sauvegarde de l’instance EMF :
   //resource.save(saveOptions);
2. déleguer la sauvegarde à l’éditeur de texte de la page source :
   sourcePage.doSave(progressMonitor);

JSF Webtools fonctionne de la même manière.

La sauvegarde de l’éditeur fonctionne à nouveau.

Conclusion

On peut constater que fonctionnelement les Translator apporte beaucoup mais au niveau codage, ils sont assez pénible à mettre en place car il n’utilise pas les information meta object de l’Ecore : les ID EMF ont dû être gérés via les classes MyIDTranslator et HRefTranslator.

Il existe à cette étape encore un problème de undo/redo. En effet si vous tappez du contenu XML dans l’éditeur de texte puis si vous allez dans une autre page de l’éditeur puis vous cliquer sur Ctrl+Z, vous pourrez constater que le undo ne fonctionne pas (et inversement). Le undo fonctionne que si on l’effectue dans la page source. Ceci s’explique par le fait que l’editeur de texte gère sa stack de commande et que les autres pages gérent une autre stack de commande (l’editingDomain). Je tenetrais dans le prochain billet d’apporter une solution pour règler ce problème.