Discussion :

[azerr]

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]

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]

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]

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]

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]

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