[Eclipse RCP] Comment développer un formulaire de CRUD avec RCP?

**azerr** · 19/09/2011, 15h52

Bonjour,

Nous sommes actuellement en train de mettre en place une application de reporting en RCP (client lourd) et RAP (Web) pour le projet XDocReport http://code.google.com/p/xdocreport/wiki/EclipseRAPRCP

Je suis en train d'étudier les solutions pour gérer un formulaire de CRUD (Create, Read, Update, Delete), autrement dit comment mettre en place un editor RCP qui puisse saisir des données d'une instance domain (Modèle, Pojo, etc..) mappée sur une Table d'une BD.

J'aimerais faire ça proprement, et la première chose que je pensais faire est d'utiliser JFace Databinding pour binder les widgets de l'IHM et le domain à mettre à jour. Mais la question que je me pose est sur la mise à jour du dirty de l'editor, de la gestion du undo (Ctrl+Z).

En effet dès que l'on modifie une valeur d'un champs du formulaire, il faut mettre à jour l'état dirty de l'editor. Soit c'est :

l'UI qui fait ça, autrement dit il faut ajouter un listener sur chaque widget qui met à jour l'état dirty de l'editor.
le modèle qui fait ça, autrement dit le modèle doit gérer des listeners en interne (soit codé à la main avec PropertyChangeSupport, soit utilisé EMF qui génère toute cette tuyauterie de listeners) .
utiliser JFace Databinding pour détecter dans le DatabindingContext les changements de valeurs.

Je pense plutôt à mettre en place la 3ème solution mais ce qui impose le fait de cloner l'instance domain avant car cette solution ne permet pas de "reseter" les valeurs domain avec les valeurs initial. EMF, même si j'adore, me fait un peu peur de par son coté lourd en terme d'apprentissage (j'ai peur que ça refroidisse les gens qui souhaiterait contribuer à l'application).

Il existe aussi le projet Riena mais je ne sais pas si il gère ce genre de problématiques?

J'aurais aimé connaitre les solutions que vous avez mis en place dans vos projets pour gérer les formulaire de CRUD avec lock, gestion du dirty, getion de l'undo, etc....

Merci de vos réponses.

Angelo

**Mickael_Istria** · 19/09/2011, 16h32

Perso, je mets du EMF partout parce que le gain est toujours au rendez-vous. Du coup, je choisis la solution 2 que j'applique de cette maniere:
Quand tu ouvres ton modele, tu le fais de maniere transactionnelle (en créant un TransactionalEditDomain et tout). Du coup tu utilises ensuite des EMFEditObservables. L'avantage c'est que le Undo est offert. Pour le dirty, il suffit de mettre un listener sur la CommandStack EMF et des qu'il exécute un commande, tu mets l'éditeur en dirty.
Tout cela est relativement simple.

J'aime bien la solution 3 en théorie, mais je me retrouve toujours avec plusieurs DataBindingContext dans mes éditeurs, ou alors il y a toujours un truc qui me saoule avec un DataBinding et je laisse un listener a l'ancienne...

**azerr** · 19/09/2011, 16h59

Bonjour Mickael,

Merci de ta réponse. Venant de toi je me doutais bien que la solution EMF était ta préférée

La solution avec JFace Databinding, ralfebert a eu déjà cette idée et l'a implémenté avec
ModelDataBindingEditorPart.java

EMF, j’hésite beaucoup car c'est quand même chaud de faire quelque chose quand tu n'y connais rien (j'ai passé quand même pas mal d’heures à me former dessus).

Angelo

**Gueritarish** · 19/09/2011, 18h12

Salut,

Pour ma part, ce serait:

mise en place du JFace DataBinding
et utilisation du framework d'Operations d'Eclipse (avec OperationHistory et IUndoableOperation):
- Il "suffit" d'enregistrer un listener sur l'OperationHistory (que l'on obtient à partir de l'OperationHistoryFactory) dans la IWorkbenchPart dont on souhaite changer l'état (pour le dirty).
- Il faut ensuite enregistrer les actions d'undo / redo dans l'actions bars de la part.
- Et coder une IUndoableOperation pour les actions (create, update, delete).

Je ne sais pas s'il y a plus de travail qu'avec EMF, mais ça a le bon goût de ne pas mettre le doigt dans cet engrenage

Voilà, à+
Gueritarish

**Mickael_Istria** · 20/09/2011, 11h47

Envoyé par Gueritarish

Je ne sais pas s'il y a plus de travail qu'avec EMF, mais ça a le bon goût de ne pas mettre le doigt dans cet engrenage :aie

Ah ce troll! Il est irrésistible

EMF est certes plus difficile a saisir que du Pojo. C'est donc en effet un investissement. Ceci dit, il suffit de se lancer pour comprendre assez rapidement les choses. Le coup d'apprendre EMF est le même que d'apprendre DOM ou java.lang.reflect.
Une fois que cela est fait, c'est un framework ULTRA-productif. Je pense qu'il n'y a pas trop de rival qui permette aussi facilement de générer une API (== un métamodele) métier de manière si simple, si agile et si rapide; et qui offre un telle foultitude de features qui je pense divisent bien par 2 le temps de dev sur des use-case tels qu'un éditeur de forms pour un domaine métier.
EMF n'a pas de dépendances sur Eclipse, l'API, le parser et le sérializer qu'il te génère pour tes modèles peuvent être embarqués dans n'importe quelle appli Java - et aussi dans le mode du faux Java de Google (Android, GWT, AppEngine). C'est un peu triste d'ailleurs de voir encore autant de travail fait sur de la sérialization/déserialization de modèles avec DOM alors qu'EMF te fait ça pour moins cher.
Ensuite, se lancer dans EMF, c'est s'ouvrir a tout l'écosystème de Modeling chez Eclipse, donc a transfos M2M, M2T, aux visualisation graphiques avec GMF, au versionning avec CDO... Bref, c'est le point d'entrée de technos plus puissantes les unes que les autres.

Ainsi mon conseil est: mettez les doigts dans cet engrenage, le retour sur investissement est incroyable.

(je suis en train de préparer une présentation "Modeling w/ Eclipse" pour SoftShake, du coup je suis a fond en mode évangélisation, je vais pas laisser passer cette occasion d'essayer de vous convaincre!)

**Gueritarish** · 20/09/2011, 12h36

Envoyé par Mickael_Istria

Ah ce troll! Il est irrésistible

On sent le passionné là

Après, pour la petite histoire, c'est que j'ai déjà un peu touché à EMF et que je me sers d'une classe qui hérite de EContentAdapter pour envoyer des notifications lorsque le modèle évolue

Donc, j'ai déjà mis le doigt dans l'engrenage... Mais je n'ai absolument pas assez de connaissances sur le sujet pour faire bénéficier Angelo de mon expérience

**azerr** · 20/09/2011, 15h00

Bonjour Gueritarish et Michael,

Merci a vous 2 de vos réponses. EMF est un long débat qui fait couler de l'encre. J'ai de mon côté joué pas mal avec EMF ou d'ailleurs j'avais rédigé la série d'articles Conception d'un Editeur Eclipse de workflow XML qui utilise EMF et DOM-SSE. Je t'avoues que j'ai quand même passé des heures dessus.

Ce qui me frêne aussi avec EMF c'est qu'il y a beaucoup de code généré et dans une application client/serveur ou les instances domain doivent être sérialisés je ne sais pas si ca peut poser problème.

Ensuite dans une application RAP ou il y a plusieurs utilisateurs, les instances Commande EMF vont se multiplier et tout cela juste pour gérer un Ctrl+Z. Je me pose la question si le Ctr+Z prime sur la mémoire (plein d'instanciation de Command EMF).

Teneo me séduit pas mal car apparemment on peut faire de l'EclipseLink ou Hibernate avec JPA.

C'est un peu triste d'ailleurs de voir encore autant de travail fait sur de la sérialization/déserialization de modèles avec DOM alors qu'EMF te fait ça pour moins cher

J'espère que je ne vais pas te faire hurler avec mes propos et on s'évade un peu du sujet. Mais le problème avec EMF c'est que c'est impossible d'écrire à la mano ton XMI alors qu'avec XML, c'est plus simple. L'idée de EMF c'est de modéliser via un outil, mais pas de saisir le XML (XMI ou autres) à la mano. Tu vas me dire que tu peux créer ton propre sérializer EMF mais je n'ai jamais réussi à virer les namespaces par exemple.

Angelo

**Mickael_Istria** · 30/09/2011, 14h26

Au fait, j'avais oublié, mais tu si tu pars sur un model en EMF, tu as EEF qui est dédié a la création de formulaire CRUD.

**azerr** · 30/09/2011, 21h42

Bonjour Mickael,

Merci pour cette information. Après avoir bien réfléchi je ne vais pas utiliser EMF dans un premier temps. Il y a trop d'inconnu pour me lancer véritablement dedans car notre application doit gérer RCP (client lourd, client/serveur) et RAP, doit s'appuyer sur Eclipse Forms, doit utiliser Spring DM avec JPA EclipseLink/Hibernate.

Tous ces paramètres je commence à les connaître mais pas avec EMF qui va ajouter encore une complexité (ex: EMF génère un editor, mais comment faire pour qu'il génère de l'Eclipse Forms, une instance EMF est plus gourmande en mémoire qu'un POJO etc....).

Peut être que je reviendrais sur ma décision mais je vais démarrer sans EMF et la j'ai commencé à développer un éditeur basé sur Eclipse Forms qui gère le dirty via JFace Databinding, qui va gérer les états d'un éditeur pour du CRUD (CREATE, READ, UPDATE, etc...).

Si quelqu'un est intéressé par le sujet d'éditeur Forms avec JFace Databinding (qui met à jour le dirty de l'éditeur) + gestion des états d'un éditeur pour du CRUD. N'hésitez pas à me le demander et je vous donnerais des liens sur le projet avec des explications.

Angelo

**Mickael_Istria** · 01/10/2011, 11h09

RCP, RAP, Forms, tu n'as vraiment pas a t'en faire. C'est transparent.
Par contre j'avoue que JPA et EMF, il faut rajouter l'apprentissage de Teneo. Je n'ai jamais utilisé, je ne connais pas le cout.
Pour ce qui est de Spring DM, alors la, j'en sais fichtre rien de si il marche bien avec EMF.

Au final, étant donné tout cela, le choix du POJO semble raisonnable. Je vais quand meme continuer d'argumenter pour EMF pour ceux que ca peut intéresser dans l'immédiat ou a l'avenir.

Envoyé par azerr

Tous ces paramètres je commence à les connaître mais pas avec EMF qui va ajouter encore une complexité

Elle est minime la complexité, c'est juste que ton API Domain est généré par EMF au lieu que tu l'écrives toi-meme en Java.

mais comment faiore pour qu'il génère de l'eclipse forms

Si tu veux du forms avec EMF, et bien soit tu utilises EEF, un projet dédié a ca; soit tu le fais toi-meme tranquillement en Java. Avec EMF, Dirty, Undo, Redo sont gratuit; JFace databinding est au meme prix qu'avec Pojo.

une instance EMF est plus gourmande en mémoire qu'un POJO

12 pauvres octets!

**azerr** · 24/10/2011, 09h36

Bonjour,

Pour votre information j'ai commencé un projet qui gère le cycle de vie d'un editor qui utilise FormEditor + qui bindle un modèle avec JFace Databinding :

FormEditor (onLoad, onSave, etc)
FormPage (onBind, etc)

dans le projet fr.opensagres.eclipse.forms

Vous avez un exemple d'utilisation dans fr.opensagres.eclipse.forms.samples

et ce formulaire est aussi utilisé dans la démo Eclipse RCP/RAP de gestion de CV.

Voici un exemple basique d'implémentation de ModelFormEditor où onLoad et onSave doivent être implémentés :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public class PersonEditor extends ModelFormEditor<PersonEditorInput, Person> {
 
    @Override
    protected void doAddPages() {
        try {
            super.addPage(new OverviewPage(this));
        } catch (PartInitException e) {
            e.printStackTrace();
        }
    }
 
    @Override
    protected Person onLoad(PersonEditorInput input) {
        long personId= input.getPersonId();
        IPersonService personService = PersonService.getInstance();
        return personService.getPerson(personId);
    }
 
    @Override
    protected Person onSave(Person person, IProgressMonitor monitor) {
        IPersonService personService = PersonService.getInstance();
        return personService.savePerson(person);
    }
 
}

et voici un exemple de FormPage ou onCreateUI, onBind doivent tre implémentées :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
public class OverviewPage extends ModelFormPage<Person> {
 
    private Text personNameText;
    private Label label;
 
    public OverviewPage(ModelFormEditor editor) {
        super(editor, "ID", "Person");
    }
 
    @Override
    protected void onCreateUI(IManagedForm managedForm) {
        FormToolkit toolkit = managedForm.getToolkit();
        Composite body = managedForm.getForm().getBody();
        TableWrapLayout tableWrapLayout = new TableWrapLayout();
        tableWrapLayout.numColumns = 1;
        body.setLayout(tableWrapLayout);
 
        Composite parent = toolkit.createComposite(body);
        parent.setLayout(new GridLayout(2, false));
        parent.setLayoutData(new TableWrapData(TableWrapData.FILL_GRAB));
 
        toolkit.createLabel(parent, "Name:");
        personNameText = toolkit.createText(parent, " ", SWT.BORDER);
        personNameText.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));
 
        toolkit.createLabel(parent, "Unique ID:");
        label = toolkit.createLabel(parent, "");
        label.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));
    }
 
    @Override
    protected void onBind(DataBindingContext dataBindingContext) {
        dataBindingContext.bindValue(
                SWTObservables.observeText(personNameText, SWT.Modify),
                PojoObservables.observeValue(getModelObject(), "name"));
 
        dataBindingContext.bindValue(
                SWTObservables.observeText(label),
                PojoObservables.observeValue(getModelObject(), "uniqueId"));
 
    }
}

Comme vous pouvez le remarquer, il n'y a pas besoin de gérer l'instanciation du DatabindingContext, il n'y a pas besoin de re-binder le modèle une fois que le formulaire est sauvé (une autre instance du modèle peut venir après le save, il n'y a pas besoin de gérer le dirty de l'éditor qui est géré en bindant avec le ou les DatabindingContext, etc)

ModelFormEditor et ModelFormPage permettent de s'occuper uniquement du onLoad, onSave et onBind. Le reste est géré en interne.

Angelo

**Gueritarish** · 24/10/2011, 10h04

Merci pour la contribution Angelo

**Mickael Baron** · 25/10/2011, 10h37

Bonjour à tous,

Angelo vient de me faire part de cette discussion. Oh que j'ai honte

pour un responsable de rubrique.

Bref cette discussion est très intéressante. Mickael tu as vraiment des arguments qui accrochent. J'ai les yeux qui brillent

Je me rends compte depuis le temps que je programme avec la plateforme Eclipse que je passe plus de temps à coder la partie basse que de m'intéresser vraiment à la partie métier.

En fait je voulais me mettre à EMF sans vraiment savoir pourquoi l'utiliser. Je crois que j'ai ma réponse.

Mickael aurais-tu d'autres liens de tutoriels qui pourraient aider pour un départ ? Je vais essayer de créer une petite étude de cas qui couvre tous ce dont tu as parlés (surtout ORM dans EMF)

Merci d'avance

En tout cas superbe boulot à tous

Mickael

**Mickael_Istria** · 25/10/2011, 14h47

Salut,

Je dois avouer que je ne connais pas trop les tutoriels mais il y en a un bon listing ici: http://www.eclipse.org/modeling/emf/docs/

Je pense que la clé pour vite se faire la main, c'est de partir très simple, avec 1 seule classe, puis en rajouter une, puis mettre une relation...
Ensuite, faire connaissance avec emf.edit (pour l'aspect transactionnel), les EditingDomain et les commandes.

Après, le monde du modeling s'ouvre à toi.
Si ca peut t'inspirer, voici la présentation que j'ai faite à SoftShake (d'ailleurs je compte l'utiliser pour faire la tournée des JUGs sur Eclipse RCP un jour) [ame="http://www.slideshare.net/mickaelistria/modelingwitheclipse"]Modeling With Eclipse @SoftShake 2011@@AMEPARAM@@ssplayer2.swf?doc=modelingwitheclipse-111004052921-phpapp02&stripped_title=modelingwitheclipse@@AMEPARAM@@modelingwitheclipse-111004052921-phpapp02@@AMEPARAM@@modelingwitheclipse[/ame]. Les codes de démo sont ici: https://github.com/mickaelistria/Modeling-With-Eclipse

Je ne connais pas Teneo spécifiquement, mais si tu as des problématiques de persistance d'objet métier, et que tu restes dans le monde d'EMF, il y a CDO qui est vraiment top.

**azerr** · 25/10/2011, 14h59

Salut Michael,

Tu peux lire les premiers billets que j'avait fait sur la conception d'un editeur de workflow avec EMF+DOM-SSE+GEF

Step1 : genere un modèle EMF via un Schema XML + génère l'editeur EMF.
Step2 qui modifie le modèle EMF et explique la sérialisation EMF.

Angelo

**Mickael Baron** · 25/10/2011, 16h57

Merci à vous deux pour les pointeurs

Je pense que la clé pour vite se faire la main, c'est de partir très simple, avec 1 seule classe, puis en rajouter une, puis mettre une relation...

Je crois que nous avons la même méthodologie

Je ne connais pas Teneo spécifiquement, mais si tu as des problématiques de persistence d'objet métier, et que tu restes dans le monde d'EMF, il y a CDO qui est vraiment top

Si je demande la différence, c'est trop demandé ?

Merci beaucoup

Mickael

**Mickael_Istria** · 25/10/2011, 17h04

En fait Teneo fait un ORM tout normal.
CDO assure la persistence d'EObjects dans un server/repository abstrait, qui peut etre implémenté du JDBC, Hibernate, ou encore des bases de données objets pour de meilleurs performances. Le truc vraiment sympa avec CDO c'est qu'il offre versioning et historique de tes modeles.

**Mickael Baron** · 25/10/2011, 17h15

CDO assure la persistence d'EObjects dans un server/repository abstrait, qui peut etre implémenté du JDBC, Hibernate, ou encore des bases de données objets pour de meilleurs performances. Le truc vraiment sympa avec CDO c'est qu'il offre versioning et historique de tes modeles.

ça c'est cool pour travailler à plusieurs.

Si je simplifie en disant que les fonctionnalités de Teneo se retrouvent dans CDO, j'ai juste ?

Mickael