Discussion :

[Yro]

Bonjour,

J'aimerai avoir votre avis sur le sujet suivant :

J'ai une Jtable qui contient ma liste d'utilisateur (liste d'objet "Utilisateur" chargé via JPA). Mes objets sont "détached" car les transactions sont gérer dans une classe service UserService.

J'ai un Jbouton Editer. Lorsque je clique dessus, j'ouvre une Jframe pour pouvoir editer tout les champs de mon Objet selectionné. Cette frame contient un bouton annuler et un bouton enregistrer.

Ma question est la suivante : Est-il préférable de passer l'Id de l'utilisateur a la JFrame ou l'objet au complet dans la JFrame ?

Passage de l'ID:
Cela me permet de recharger un objet Utilisateur qui est indépendant de l'objet qui se trouve dans la fenêtre de liste des utilisateurs. Mais j'ai une requete supplémentaire a chaque "Edition"
Donc si je clique sur Annuler, je fais rien.
Si je clique sur enregistrer je fait un Merge et récupère le nouvel Objet dans la fenetre de liste des utilisateur via une méthode GetUser() de ma frame d'edition pour mettre a jour ma DefaultTableModel.

Passage de l'obket:
Cela me permet de travailler directement sur l'objet Utilisateur.
Si je clique sur enregistrer je fait un Merge et comme c'est le même objet, ma DefaultTableModel est a jour
par contre si je clique sur Annuler, je suis obligé de recharger l'objet Utilisateur depuis la DB avant de fermer ma frame car on a pu modifier des champs avant de cliquer sur "Annuler". Donc une requête de plus.

Je sais pas si je me fais bien comprendre.
Merci

[joel.drigo]

Salut,

A moins que tu utilises des bindings entre les champs de saisie et ton objet, normalement tant que tu n'as pas appuyé sur un bouton, valider, ou Annuler, les données saisies dans les champs ne sont pas encore affectées aux attributs de l'objet passé en paramètres, donc on peut tout-à-fait annuler la saisie sans avoir à recharger l'objet.

Dans l'application sur laquelle je travaille (non JPA, et je ne connais pas du tout le fonctionnement de JPA, donc je ne sais pas ce que ça implique sur les objets en eux-mêmes), les objets sont des wrappers qui contiennent tous les attributs en double en quelque sorte : tous les champs ont des liens avec les attributs, mais avec une version temporaire de l'attribut. L'objet gère un état dirty qui permet de savoir qu'il y a des propriétés modifiées non sauvegardées et une notion de "commit" pour faire la sauvegarde. Je passe donc toujours les objets, ce qui me permet une parfaite indépendance entre l'objet et le formulaire, la possiblité d'annuler, y compris champ par champ, voire de pouvoir avoir des vues qui travaillent soit avec la valeur temporaire (un outlines par exemple, ou une preview dynamique), soit avec la valeur stockée en base.

[Yro]

Bonjour,

Merci pour ta réponse. Quelques explications supplémentaires.

Je n'utilise pas les binding, mon problème survient lorsque l'utilisateur clique sur enregistrer.

Voici ce que je fait :

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
public void actionPerformed(ActionEvent e) {
			// Alimentation de l'obet PosUSer;
			user.setLogin(tfLogin.getText());
			user.setNom(tfNom.getText());
			user.setPrenom(tfPrenom.getText());
			user.setProfil((PosUserProfil) cbProfil.getItemAt(cbProfil.getSelectedIndex()));
 
			// Enregistrement en Base
			UserService userService = UserService.getInstance();
			try {
				userService.saveOrUpdate(user);
				setVisible(false);
			} catch (MandatoryValueException | IllegalValueException e1) {
				JOptionPane.showMessageDialog(null, e1.getMessage(), "Erreur", JOptionPane.ERROR_MESSAGE);
			}
		}

Au niveau de mon service :

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
 */
	public PosUser saveOrUpdate(PosUser user) throws MandatoryValueException, IllegalValueException {
		EntityManager em = JPAUtil.getEntityManager();
		validateUser(user);
		em.getTransaction().begin();
		if (user.getId() == null)
			em.persist(user);
		else
			user = em.merge(user);
 
		em.getTransaction().commit();
		em.close();
 
		return user;
	}
 
 
public boolean validateUser(PosUser user) throws MandatoryValueException, IllegalValueException {
		PosUser userResult = null;
 
		if (user == null)
			throw new IllegalArgumentException("UserService.validateUser : Null exception !");
 
		if (user.getLogin() == null || user.getLogin().isEmpty())
			throw new MandatoryValueException("Login est un champ obligatoire");
 
		userResult = getUserByLogin(user.getLogin());
		if (userResult != null && !userResult.equals(user))
			throw new IllegalValueException("Login déjà attribué a un autre utilisateur");
 
		if (user.getProfil() == null)
			throw new MandatoryValueException("Profil utilisateur est un champ obligatoire");
 
		return true;
	}

Donc si j'ai une exception a l'enregistrement et que l'utilisateur clique ensuite sur Annuler, J'ai les valeurs modifié dans ma table (liste utilisateur).

Merci

[joel.drigo]

Oui, en cas d'erreur, dans ton cas, il peut être nécessaire d'annuler, et donc de recharger l'objet. On peut considérer que c'est un cas rare. Si c'est une erreur de saisie (donc résultant de validation et de contrôle d'intégrité), la plupart du temps l'utilisateur la corrige et enregistre à nouveau, et s'il annule, on peut considérer que c'est une procédure exceptionnelle qui tolère la requête supplémentaire. Et si c'est une erreur du système, cas rarissime, on passe dans une procédure exceptionnelle, qui peut tolérer une requête supplémentaire si nécessaire).
Le seule problème est si tu fonctionnes avec un modèle évènementiel sur les propriétés, et que la JTable puisse afficher temporairement des valeurs qui ne sont pas sauvegardables (voire qui peuvent avoir un impact plus global sur le tri et ou les filtres de la JTable).

[Yro]

Effectivement, j'ai remarqué que lorsque une exception est levée, ma Jtable derrière affiche déjà les "mauvaises" valeurs.

Ce qui est corrigé dès que l'utilisateur corrige et valide les données ou annule (et donc refresh depuis la base).

Dès lors, A ton avis, est-il mieux de passer l'objet ou l'Id de l'objet a la JFrame ?

Merci

[joel.drigo]

Dès lors, A ton avis, est-il mieux de passer l'objet ou l'Id de l'objet a la JFrame ?

Là, je ne connais pas assez JPA (pas du tout en fait) pour te répondre, mais je me dit : "qu'est-ce-qu'on peut bien faire de l'id à part charger l'objet dans une nouvelle instance, donc faire à priori une requête...", donc pour économiser d'éventuelles requêtes en cas d'annulation, je vais faire une requête systématique à l'ouverture, alors que je peux fermer mon formulaire directement (annuler) sans même saisir quoique ce soit (et je sais que mes utilisateurs ouvrent très souvent le mauvais objet..., voire l'ouvre en édition juste pour le consulter). Enfin, bref, autant passer l'objet.

Ensuite, je ne sais pas quelles possibilités de clonage JPA offre : si on peut cloner, on peut passer le clone de l'objet au formulaire, et si l'option de commit du clone existe c'est encore mieux, sinon pour le coup, je suppose qu'il faudra une requête pour mettre à jour la JTable. C'est géré dans mon application justement par l'encapsulation (les objets que je manipule sont des wrappers des entités que mon API me donne quand je fais une requête, ce qui me permet d'ailleurs de gérer des objets qui n'existent pas encore dans le CMS).

[Yro]

Merci beaucoup pour vos éclaircissements.

Cordialement.