Discussion :

[Mickael Baron]

Bonjour à tous,

Je viens de commencer à faire des essais via l'utilisation d'EMF pour faire du CRUD (solution 2 d'Angelo) en intégrant les points suivants :

- Exemple d'un modèle (Person, Address) et génération des codes associées
- Création d'instances via l'éditeur générée
- Création d'instances via l'API
- Persistance dans un fichier XMI (chargement/sauvegarde)
- Création d'une vue (avec un champ texte qui désigne le prénom d'une personne)
- Binding via le composant texte et l'attribut prénom du modèle
- Transaction (TransactionalEditingDomain) et écriture sous transaction avec RecordingCommand
- Undo/Redo via la commandStack Redo et Undo (qui ne fonctionnent que si les modifications ont été réalisées dans une transaction et non via le binding)

Tout n'est pas rose puisque le binding et les transactions n'ont pas l'air de fonctionner ensemble. En fait je me pose la question de savoir à quel niveau doit s'inscrire la transaction ?

• A l'initialisation de ma vue, je fais une copie du modèle et lorsque je sauvegarde j'envoie via transaction à mon modèle de référence. Inconvénient je ne profite pas de undo/redo tout au long de l'édition de mon formulaire.
• A chaque modification dans mon formulaire, je suis dans une transaction. Inconvénient je ne profite pas du binding

Avez-vous une idée sur la question ?

Mickael

[Mickael_Istria]

Le Binding et les transactions marchent ensemble. Tu utilise bien la factory EMFEditObservables ?

[Mickael Baron]

Le Binding et les transactions marchent ensemble. Tu utilise bien la factory EMFEditObservables ?

Non pas exactement. J'exploite directement EMFProperties.value(feature).observe(createPerson)

Je me disais bien que ça pourrait servir à ça. J'y regarde et je te tiens au courant

Mickael

[Mickael Baron]

C'est bon ça fonctionne. Merci beaucoup Mickael

Binding sans transaction

bindingContext.bindValue(WidgetProperties.text(SWT.Modify).observe(firstName),
EMFProperties.value(PersonPackage.Literals.PERSON__FIRST_NAME).observe(createPerson));

Binding avec transaction

DataBindingContext bindingContext = new DataBindingContext();
bindingContext.bindValue(WidgetProperties.text(SWT.Modify).observe(firstName),EMFEditObservables.observeValue(domain, createPerson, PersonPackage.Literals.PERSON__FIRST_NAME));

Ne pas oublier la dépendance vers le plugin org.eclipse.emf.databinding.edit

Prochaine étape la persistance via Teneo et CDO puis j'écris un billet sur le sujet dessus.

Mickael

[azerr]

Prochaine étape la persistance via Teneo et CDO puis j'écris un billet sur le sujet dessus.

Ça c'est une super nouvelle. J'ai hâte de lire ton article. Tu utilises EEF?

En ce qui me concerne, j'ai bien avancé le projet "générique" qui est capable de gérer un formulaire basé sur un FormEditor avec JFace Databinding. Il permet par exemple :

• d'appeler une methode FormPage#onBind pour créer les binding au bon moment (lors du load et du reload du formulaire).
• de gérer le dirty de l'editor en utilisant les bindings JFace Databinding.
• d'afficher les erreurs de validation dans le header du FormEditor automatiquement en utilisant les bindings JFace Databinding.

Concernant les validations, j'ai créé un support JFace Databinding pour JSR-303 que j'aimerais bien donner à Eclipse. Ce support permet d'utiliser les annotations JSR-303 de validations. Ex :

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
package org.eclipse.core.databinding.validation.jsr303.samples.model;
 
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;
 
public class Person {
 
	@Size(min = 1)
	private String name;
 
	@Size(min = 1)
	@Pattern(regexp = ".+@.+\\.[a-z]+")
	private String email;
 
	public String getName() {
		return name;
	}
 
	public void setName(String name) {
		this.name = name;
	}
 
	public String getEmail() {
		return email;
	}
 
	public void setEmail(String email) {
		this.email = email;
	}
}

Pour créer un validator JFace basé sur ses annotations pour afficher, par exemple, que le mail n'est pas bien formaté, etc :

Code :

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

1
2
3
4
5
6
7
8
9
 
Text emailText = ....
Person model = ...
IObservableValue swtEmailTextObservableValue = SWTObservables.observeText(emailText, SWT.Modify);
IObservableValue modelEmailObserveValue = PojoObservables.observeValue(model, "email");
dataBindingContext.bindValue(
		swtEmailTextObservableValue,
		modelEmailObserveValue,
		Jsr303UpdateValueStrategyFactory.create(Person.class, "email"), null);

J'espère que ce support vous plaira.

Angelo

[Mickael Baron]

Angelo,

Ça c'est une super nouvelle. J'ai hâte de lire ton article. Tu utilises EEF?

Non pas encore mais c'est sur ma liste. Actuellement je m'intéresse plus aux aspects persistance en BD. Je viens de jouer avec Teneo et c'est vraiment très simple

Persistance dans un fichier XMI

ResourceSet resSet = new ResourceSetImpl();
Resource resource = resSet.createResource(URI.createURI("My.person"));
resource.getContents().add(pPerson);
try {
resource.save(Collections.EMPTY_MAP);
} catch (IOException ee) {
ee.printStackTrace();
}

Persistance en BD via Hibernate

String uriStr = "hibernate://?"+HibernateResource.DS_NAME_PARAM+"=MyDb";
ResourceSet resourceSet = new ResourceSetImpl();
Resource resource = resourceSet.createResource(URI.createURI(uriStr));
resource.getContents().add(createPerson);
try {
resource.save(null);
} catch (IOException ee) {
ee.printStackTrace();
}

Sinon par rapport à ton avancement, j'ai quelques questions :

d'appeler une methode FormPage#onBind pour créer les binding au bon moment (lors du load et du reload du formulaire).

Tu as également un onUnBind pour supprimer le binding précédent ?

de gérer le dirty de l'editor en utilisant les bindings JFace Databinding.

J'ai pensé comme la proposé Mickael de placer un listener sur les CommandStack. Quelle est la meilleure solution ? Si je le fais sur les bindings il faut faire un listener sur chaque binding alors que sur CommandStack je n'ai besoin que d'en faire un seul.

Mickael

[Mickael_Istria]

J'ai pensé comme la proposé Mickael de placer un listener sur les CommandStack. Quelle est la meilleure solution ? Si je le fais sur les bindings il faut faire un listener sur chaque binding alors que sur CommandStack je n'ai besoin que d'en faire un seul.

Les avantages a le mettre sur la commande stack:
* C'est comme ca que font les éditeur EMF générés.
* Tu n'as qu'une seule fois du code a écrire
* Tu n'as qu'un seul listener a poser
* Et le plus important IMHO, c'est que tu maitrises pleinement le cycle de vie de la commandStack dans ton éditeur (grosso modo, 1 éditeur = 1 commandStack), alors que les bindings peuvent étre supprimés, ou leur widgets disposed, ou tout plein de use-case ou l'éditeur est tellement dynamique que tu te perds facilement dans tes widgets et tes bindings.


Par contre, j'avais vraiment regardé Teneo, mais le coup de l'URL magique qui te donne une resource persistée en DB, c'est tres tres bon!

[azerr]

Merci a vous 2 pour ces précieuses informations.
Je suis de près ce post pour voir si on migrera vers EMF une fois qu'on aura bien tout mis en place (là on met en place Eclipse Gemini (Spring DM) et ensuite on mettre en place JPA).

Sinon par rapport à ton avancement, j'ai quelques questions :

Citation:
d'appeler une methode FormPage#onBind pour créer les binding au bon moment (lors du load et du reload du formulaire).
Tu as également un onUnBind pour supprimer le binding précédent ?

En fait il n'y a pas besoin de cette méthode car le unbind se fait en itérant sur la liste des Binding de DatabindingContext et en faisant Binding#dispose().

Je suis aussi parti du principe qu'il faille cloner le modèle à éditer.

Citation:
de gérer le dirty de l'editor en utilisant les bindings JFace Databinding.
J'ai pensé comme la proposé Mickael de placer un listener sur les CommandStack. Quelle est la meilleure solution ? Si je le fais sur les bindings il faut faire un listener sur chaque binding alors que sur CommandStack je n'ai besoin que d'en faire un seul.

J'ai effectivement ajoute un listener par binding pour observer le dirty mais aussi les erreurs aussi, mais tout ceci se fait automatiquement.

Je ne sais pas comment tu fais pour gérer les erreurs mais si tu regardes notre démo http://xdocreport-rap.opensagres.clo...se.application et que tu ouvres un CV, si tu mets, par exemple, un mail invalide (ceci est géré via JSR-303 en mettant une annotation sur la propriété "email"), tu verras que le bandeau du haut affiche une erreur et que le contrôle SWT qui affiche l'email a une petite puce rouge. Pour cela j'utilise les informations du Binding pour savoir quel contrôle pose problème.



Comment fais-tu avec EMF?

Angelo

[Mickael Baron]

Bonjour à vous tous,

Les avantages a le mettre sur la commande stack:
* C'est comme ca que font les éditeur EMF générés.
...

Merci pour ta confirmation Mickael, je pensais exactement à cela.

J'ai une question peut être toute bête, mais je ne sais pas si je fais comme il faut.

J'ai réalisé un binding entre un composant TableViewer et un élément EMF et je souhaite mettre à jour la table quand de nouvelles entrées sont ajoutées. Actuellement je suis obligé de faire cette mise à jour de manière explicite via un refresh sur ma table. Est-ce normal ?

Mickael

[Mickael Baron]

Comment fais tu avec EMF?

Je ne me suis pas trop posé la question encore. Mais à y regarder j'essaierai de voir du côté de l'API validation d'EMF pour la partie règle. En fonction de la règle qui ne passe pas je sais où impacter l'élément de l'IHM

Mais bon, je ne suis pas un spécialiste, juste en mode "défrichage" EMF

Mickael

[Mickael_Istria]

J'ai réalisé un binding entre un composant TableViewer et un élément EMF et je souhaite mettre à jour la table quand de nouvelles entrées sont ajoutées. Actuellement je suis obligé de faire cette mise à jour de manière explicite via un refresh sur ma table. Est-ce normal ?

C'est une bonne question! Maintenant que tu le dis, je crois que je fais les refresh a la mano aussi. Je trouve pas ca tip-top du coup. En fait les EList ne peuvent pas se voir installer de Listener, du coup il n'y a pas la magie nécessaire et le refresh semble nécessaire.
Tu peux surement ouvrir un bug pour lancer le sujet et avoir l'avis de Tom Schindl, mais en fait je crois que c'est une limitation due a EMF.

Je ne sais pas comment tu fais pour gérer les erreurs mais si tu regardes notre démo http://xdocreport-rap.opensagres.clo...se.application et que tu ouvres un CV, si tu mets, par exemple, un mail invalide (ceci est géré via JSR-303 en mettant une annotation sur la propriété "email"), tu verras que le bandeau du haut affiche une erreur et que le contrôle SWT qui affiche l'email a une petite puce rouge. Pour cela j'utilise les informations du Binding pour savoir quel contrôle pose problème.

Comment fais-tu avec EMF?

Il doit y surement avoir un org.eclipse.core.databinding.validation.IValidator qui traine dans EMF Validation. (en fait avec EMF Validation, tu spécifies des contraintes dans une configuration dédiée et pas dans les classes). Si il n'y en a pas, je crois que ton expérience avec le databinding te permettrait de le créer et de le contribuer en 2-2

[Mickael Baron]

C'est une bonne question! Maintenant que tu le dis, je crois que je fais les refresh a la mano aussi. Je trouve pas ca tip-top du coup. En fait les EList ne peuvent pas se voir installer de Listener, du coup il n'y a pas la magie nécessaire et le refresh semble nécessaire.

D'un autre côté faire un refresh global peut aboutir à des performances horribles.

Je vais m'attaquer à l'aspect validation et l'exemple d'Angelo est parfait.

Par ailleurs, j'ai terminé un plan pour mon prochain support de cours intitulé "Développement des IHMs par les modèles". Je rédigerai des billets sur mon blog au fur et à mesure de l'avancement du support de cours.

Merci les gars vous m'avez bien motivé

Mickael