ZeServeur » rcp http://zeserveur.fr/blog La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information… Sat, 06 Mar 2010 11:46:19 +0000 http://wordpress.org/?v=2.9.2 fr hourly 1 EMF, SWT et Databinding http://zeserveur.fr/blog/2009/07/19/emf-swt-et-databinding http://zeserveur.fr/blog/2009/07/19/emf-swt-et-databinding#comments Sun, 19 Jul 2009 10:27:13 +0000 zetom http://zeserveur.fr/blog/?p=172 Habitué au XML pour gérer le stockage de mes modèles de données, je me suis dit « Tiens, pour une fois, regarde ce que donne l’EMF »…
Et je ne suis pas du tout deçu!!! Ca m’a fait gagné pas mal de temps :)

EMF, kesako?

D’après le site officiel, « The EMF project is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. »

Ecore Diagram ou la description graphique d’un modèle

EMF dispose, en incubation (mais il marche très bien), du sous-projet « Ecore Diagram » permettant de décrire graphiquement un modèle Ecore:

ECore Diagram

Une fois le modèle décrit, il ne reste plus qu’à générer le code Java…

Donc New > Others > EMF Generator Model. On lui indique notre modèle ecore et hop, il affiche à nouveau notre modèle, mais sous forme arborescente:

Editeur GenmodelLà, bouton droit sur la racine qui nous permet de :

  • Générer le code du modèle
  • Générer le code pour éditer le modèle
  • Générer le code de l’éditeur
  • Générer le code pour tester le modèle
  • Générer tout

Pour le moment, moi, ce qui m’intéresse, c’est le code du modèle… et me voilà avec une vingtaine de classes (interface & implémentation), des factories…

Génial, pas une ligne de code écrite et je peux déjà lire & écrire des données…

Lire et écrire son modèle EMF

Après une petite recherche de code, voilà de quoi lire et écrire un modèle

/** The resource used to store the model. */
  1.     private Resource resource;
  2.  
  3.     /**
  4.      * Load the resource associated to a model.
  5.      *
  6.      * @param pFile The file.
  7.      * @return The associated resource.
  8.      */
  9.     private Resource load(final File pFile) {
  10.         ResourceSet lResourceSet = new ResourceSetImpl();
  11.         // Register the appropriate resource factory to handle all file extensions.
  12.         lResourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
  13.                 new XMIResourceFactoryImpl());
  14.         // Register the package to ensure it is available during loading.
  15.         lResourceSet.getPackageRegistry().put(ModelPackage.eNS_URI, ModelPackage.eINSTANCE);
  16.  
  17.         // Get the URI of the model file.
  18.         URI lFileURI = URI.createFileURI(pFile.getAbsolutePath());
  19.         // Create a resource for this file.
  20.         return lResourceSet.createResource(lFileURI);
  21.     }
  22.  
  23.     /**
  24.      * Load the model.
  25.      *
  26.      * @param pFile The file.
  27.      * @return The associated model.
  28.      * @throws IOException IO Error.
  29.      */
  30.     public SequenceProject loadModel(File pFile) throws IOException{
  31.         resource = EMFUtils.load(pFile);
  32.         if (pFile.exists()) {
  33.             resource.load(new HashMap());
  34.         }
  35.  
  36.         SequenceProject lSequenceProject;
  37.         if (resource.getContents().isEmpty()) {
  38.                 lSequenceProject= ModelFactory.eINSTANCE.createSequenceProject();
  39.                 resource.getContents().add(lSequenceProject);
  40.         }
  41.         else {
  42.             lSequenceProject = null;
  43.             for (EObject lObj : resource.getContents()) {
  44.                if (lObj instanceof SequenceProject) {
  45.                    lSequenceProject = (SequenceProject) lObj;
  46.                    break;
  47.                }
  48.             }
  49.         }
  50.         return lSequenceProject;
  51.     }
  52.  
  53.     /**
  54.      * Save the model.
  55.      *
  56.      * @throws IOException Error.
  57.      */
  58.     @SuppressWarnings("unchecked")
  59.     public void save() throws IOException{
  60.             resource.save(new HashMap());
  61.     }

SWT et le Databinding

Maintenant, il ne reste plus qu’à câbler le modèle aux formulaires SWT… et là, merci au databinding car il n’y a (presque) rien à faire!

En effet, les développeurs d’EMF et SWT ont eu la bonne idée de fournir un mécanisme permettant d’éviter l’initialisation et la sauvegarde des champs texte, menus déroulants, listes lorsqu’ils sont liés à un modèle EMF.

Voilà les dépendances nécessaires pour le modèle:

  • org.eclipse.emf.ecore
  • org.eclipse.emf.ecore.xmi

… et pour le databinding:

  • org.eclipse.core.databinding.beans
  • org.eclipse.emf.databinding
  • org.eclipse.jface.databinding

auxquels on ajoute évidemment la base (org.eclipse.ui, org.eclipse.ui.forms…)

Lier les widgets de base

Ensuite, il suffit d’indiquer, lors de la création du widget SWT à qui il doit être relié:

Text lText = toolkit.createText(pParent, «  »);
  1.     lText.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));
  2.     bindElement(lText, "movieName");

où bindElement est une méthode magique pour le databinding… Il suffit de lui donner l’élement (EObject) qui contient le champ à lier ainsi que le nom dudit champ.

Voilà quelques exemples d’implémentations:

/** The data binding context. */
  1.     protected DataBindingContext dataBindingContext = new DataBindingContext();
  2.  
  3.     /**
  4.      * Bind the UI element to the EMF element.
  5.      *
  6.      * @param pControl The UI Element.
  7.      * @param pField The EObject field.
  8.      */
  9.     protected void bindElement(final Combo pControl, final String pField) {
  10.         IObservableValue lUIElement = SWTObservables.observeSelection(pControl);
  11.         IObservableValue lModelElement = BeansObservables.observeValue(getEObject(), pField);
  12.         dataBindingContext.bindValue(lUIElement, lModelElement, null, null);
  13.     }
  14.  
  15.     /**
  16.      * Bind the UI element to the EMF element.
  17.      *
  18.      * @param pControl The UI Element.
  19.      * @param pField The EObject field.
  20.      */
  21.     protected void bindElement(final ComboViewer pControl, final String pField) {
  22.         IObservableValue lUIElement = ViewersObservables.observeSingleSelection(pControl);
  23.         IObservableValue lModelElement = BeansObservables.observeValue(getEObject(), pField);
  24.         dataBindingContext.bindValue(lUIElement, lModelElement, null, null);
  25.     }
  26.  
  27.     /**
  28.      * Bind the UI element to the EMF element.
  29.      *
  30.      * @param pControl The UI Element.
  31.      * @param pField The EObject field.
  32.      */
  33.     protected void bindElement(final Text pControl, final String pField) {
  34.         ISWTObservableValue lUIElement = SWTObservables.observeText(pControl, SWT.Modify);
  35.         IObservableValue lModelElement = BeansObservables.observeValue(getEObject(), pField);
  36.         dataBindingContext.bindValue(lUIElement, lModelElement, null, null);
  37.     }

Lier une liste

Ca, ça marche pour les widgets de base… mais pour les listes, c’est (un peu) plus compliqué… enfin, si peu…

En effet, le databinding nous fournit le content provider (ObservableListContentProvider) et l’input (WritableList ; mais on a la même chose pour les Set et les Map) ; pour le label provider, c’est comme d’habitude…

ListViewer viewer = new ListViewer(lComp);
  1.         viewer.setContentProvider(new ObservableListContentProvider());
  2.         viewer.setLabelProvider(new LabelProvider());
  3.         input = new WritableList(getInputList(), getEObjectClass());
  4.         viewer.setInput(input);

Et maintenant, pour ajouter/supprimer un élément de la liste, il suffit de le faire sur l’input (pas besoin de notifier le viewer, c’est fait automatiquement):

input.add(myElement);
  1.        input.remove(myElement);

… et le modèle est mis automatiquement à jour!

Voilà en gros le fonctionnement… je vais maintenant jouer un peut avec EMF Query et je reviendrai poster le résultat de mes recherches :) Articles Similaires

]]> http://zeserveur.fr/blog/2009/07/19/emf-swt-et-databinding/feed 0 JUnit, Eclipse RCP et Test de plugins http://zeserveur.fr/blog/2009/05/25/junit-eclipse-rcp-et-test-de-plugins http://zeserveur.fr/blog/2009/05/25/junit-eclipse-rcp-et-test-de-plugins#comments Mon, 25 May 2009 14:09:29 +0000 zetom http://zeserveur.fr/blog/?p=140 Question du jour: Comment lancer des tests unitaires JUnit quand on a une architecture basée sur des plugins??

Réponse: avec un Headless mode monsieur!

Dans une appli architecturée en couches (UI/Business/IO), il arrive très souvent qu’on souhaite tester les couches basses (Business/IO) de manière unitaire.

Oui mais voilà, si on fait du RCP et donc qu’on travaille avec des plugins, c’est un peu la galère de faire des TU car il faut charger les plugins pour lancer le test correctement…

Heureusement, Eclipse est bien fait :P et permet de lancer une appli RCP en occultant la partie IHM ; ça s’appelle du Headless mode.

Donc après avoir fait son TU avec JUnit, on fait comme d’habitude pour le lancer (bouton droit > Run As… > JUnit Plug-in Test)… sauf que là, on a un Eclipse nu qui se lance :(

Alors reprenons la configuration du Run (Run Configuration…) et jetons un coup d’oeil aux paramètres… et plus précisément dans la section Main.
On voit qu’on démarre le TU avec le product org.eclipse.sdk.ide… qui lance bien évidemment l’IDE!

Il suffit alors de sélectionner Run an application et de choisir [No application] – Headless Mode (le premier du menu déroulant):
headless

Et là, run… oh magie, le TU se lance, embarque tous les plugins nécessaires et pas d’IHM en vue! Articles Similaires

]]> http://zeserveur.fr/blog/2009/05/25/junit-eclipse-rcp-et-test-de-plugins/feed 0 RCP Workspace http://zeserveur.fr/blog/2009/05/02/rcp-workspace http://zeserveur.fr/blog/2009/05/02/rcp-workspace#comments Sat, 02 May 2009 09:07:28 +0000 zetom http://zeserveur.fr/blog/?p=38 Un workspace Eclipse est le répertoire où toutes les métadonnées des fichiers de préférences sont stockées (sous la forme de fichiers spécifiques Eclipse). Dans une application RCP, il se situe à la racine de l’application, dans le répertoire workspace.

Le problème en RCP, c’est que la plupart du temps, on a pas « réellement » besoin de ce répertoire (face à un client, « plugins », « feature » et « configuration », ça se justife… mais là ?!).

L’idée est donc de court-circuiter la création de ce répertoire pour le définir « à la main » lors du runtime.

Le paramètre magique

Il suffit tout simplement d’ajouter un paramètre à la ligne de command d’Eclipse pour lui indiquer que l’on va nous même lui spécifier l’emplacement du workspace.
Evidemment, il faut le positionner dès le lancement de l’application sinon Eclipse va sortir en exception en indiquant qu’aucun workspace n’a été positionné.

Ce fameux « Program Argument » s’appelle -data @noDefault.

De manière à ce que l’application RCP prenne en compte toute seule ce changement, il suffit de l’indiquer dans votre .product (Onglet « Launching »):

.product arguments

Il peut également être utile de le positionner dans les paramètres de lancement du Run:

args_tab

Modification du répertoire

Maintenant qu’Eclipse est déchargé de l’initialisation du workspace, on va simplement lui indiquer où se répertoire se trouve maitenant.

Pour être sûr que ce paramétrage fonctionne sous Linux & Merdow$, on va le créer dans le répertoire temporaire; ce dernier se récupère via les propriétés Java: System.getProperty("java.io.tmpdir")

Comme je l’ai dit précédemment, il faut faire cela très tôt… on va donc le faire dans notre classe
Application (qui implémente org.eclipse.equinox.app.IApplication):

  1. /**
  2.  * {@inheritDoc}
  3.  */
  4. public Object start(final IApplicationContext pContext) throws Exception {
  5.     // set location to the temporary folder
  6.     Platform.getInstanceLocation().set(new URL("file",
  7.              null, System.getProperty("java.io.tmpdir")),
  8.              false);
  9. […]
  10. }

Et c’est tout…

Voilà, maintenant notre application RCP n’est plus parasitée par ce répertoire…Articles Similaires

]]> http://zeserveur.fr/blog/2009/05/02/rcp-workspace/feed 0