Discussion :

[mister3957]

Bonjour,


Je dois faire une petite boîte de dialogue où l'utilisateur pourra effectuer quelques actions (2-3 max). Il y aura un bouton "Ok", un autre "Annuler".

Je comptais gérer ça de cette manière :
1) Chargement des données depuis la BDD
2) A chaque action, on remplit une liste "d'action" (représentée par une structure où l'on a les infos de l'action)
3) On met à jour l'IHM pour apliquer visuellement les actions de la liste.
4) -> Si l'utilisateur clic sur "ok", on parcours les actions pour les enregistrer dans la BDD, puis on appelle le chargement (étape 1)
-> Si l'utilisateur clic sur "annuler", on efface la liste des actions, et on recharge les données (étape 1)


Mon supérieur me conseil plutôt de passer par des états. Au chargement, il récupère l'état général des infos de la BDD, puis à chaque action de l'utilisateur, il modifie la BDD (comme si elle était validée). Si l'utilisateur clic sur "ok", il ne fait rien, s'il clic sur annuler, il remet les valeurs qu'il avait sauvegarder au chargement précédent...


Comment vous me conseillez de gérer ça ?


Merci beaucoup,

A bientôt

[koala01]

Salut,

Sans doute, de la manière la plus simple qui soit: avec les transactions (si ton SGBD les autorise).

• Avant d'envoyer la première action, tu entame une nouvelle transaction
• Si l'utilisateur clique sur "ok", tu provoque la validation la transaction
• Si l'utilisateur clique sur "annuler" tu provoque le "roll-back" (l'annulation) de la transaction

[TheLeadingEdge]

Bonjour,

Si l'utilisateur clique sur "ok", tu provoque la validation la transaction

oops. Ne jamais faire confiance à un utilisateur.
Inclure une action utilisateur au milieu d'une transaction, c'est fortement déconseillé comme pratique. Tu risques de te retrouver avec des données verrouillées pendant qu'il se tape l'incruste à la machine à café au lieu de valider.

[mister3957]

Oui j'y avais pensé aux transactions, mais évidemment ça va bloquer une table dans mon cas (mais ça pourrait être plusieurs dans d'autres cas) et provoquer des timeouts chez les autres utilisateurs qui auront besoin d'accéder à cette table.

Finalement, j'ai recopier les données issues de la BDD en mémoire, et je ne travail qu'avec elles. Lorsque l'utilisateur valide, tout ce que j'ai en mémoire je l'applique à la base. S'il annule, je recharge mes données en mémoire depuis la BDD.

Ce qui me dérange c'est que c'est une application réseau, utilisée par plusieurs personnes. Donc si quelqu'un met à jour la base, et qu'un autre fait de même, il peut y avoir des incohérences en base ou des écrasements de données puisque le deuxième, comme il travail avec les données en mémoire, chargées avant validation du travail du premier, il n'est plus à jour.

A moi de faire les vérifications et appliquer les règles métiers avant d'appliquer les modifications ? En général, c'est dans le logiciel qu'on remet tout au carré avant envoi des données en base ou c'est la base avec des triggers qui remet tout en ordre lorsqu'elle reçois les modifs ?


Merci beaucoup,


A bientôt

[TheLeadingEdge]

Tu as 3 domaines de responsabilités différents.
1 La couche données. Uniquement les données stables.
2 La couche métier. (Modèle) Les données manipulables par ton appli. Volatiles tant que pas validées explicitement.
3 La couche IHM (Vue). Les données manipulées par l'utilisateur.

C'est ta couche métier qui doit gérer les modifications et les annulations de modifications.
Tu peux soit mémoriser directement les différentes valeurs modifiées dans la couche vue tant que l'utilisateur n'a pas validé (cas ou les valeurs sont saisies par l'utilisateur), soit mémoriser les formules de calcul qui ont modifié les valeurs pour permettre l'opération inverse (cas ou les valeurs sont 1 résultat de calcul).
Ca c'est le cas simple ou 1 seul user manipule les données.

Si tu as plusieurs accès concurrents tu ne peux plus gérer le undo. Même si tu écrit ds la base à chaque modif tu ne pourra plus revenir en arrière, car tu ne sauras pas si les données que tu vas écrire ne vont pas écraser les modifs faites par un autre user après ta précédente écriture.

Dans ce cas tu pourrais mettre en place 1 gestion de l'accès aux données uniquement au travers de la couche métier. Mais ça signifie que ts les users partagent les mêmes valeurs et les mêmes modifs. Un user peut alors annuler celles faites par un autre utilisateur.
Une autre solution envisageable est de ne permettre aux utilisateurs que de consulter les données dès que l'un d'entre eux a commencé à faire des modifs.

[mister3957]

Ok, merci beaucoup,

J'ai maintenant plus de visuel sur le problème. Je vais opter pour récupérer les données dans l'état avant que l'utilisateur travail, ensuite refléter ses modifs, puis lorsqu'il valide, appliquer les modifs et tampis s'il écrase les informations de son collègue.

J'avais été confronté au même problème, mais sur une action ponctuelle. Un dossier devait être affecté à un utilisateur. Lorsque quelqu'un faisait l'affectation, on allait chercher dans la base de donnée s'il n'était pas déjà affecté. Si c'était le cas, on indiquait un message "désolé, le dossier a déjà été affecté à X, par Y".

Mais là je peux pas tester chaque données de l'IHM si elle est toujours bien conforme avant d'appliquer les modifs, l'ensemble des messages provoquerai chez l'utilisateur "nan laisse, annule tout, je recommence", donc improductif.

Bloquer les données lorsqu'elle sont en manipulation ne me conviendrai pas non plus. Lorsque l'on manipule des données issues de relation sur 3-4 tables, il faudra bloquer ces 3-4 table, et si elle sont critiques, plus personne ne pourra rien faire.

En tout cas, merci beaucoup

A bientôt

[Monstros Velu]

Ce que j'avais fait dans une appli, c'est un "avertissement". C'est à dire que quand l'utilisateur ouvrait des données ouverte par quelqu'un d'autre récement [à définir selon le besoin, dans mon cas, 1/2h], il recevait un message d'avertissement lui signalant, avec le nom de l'autre utilisateur et sa dernière date d'accès : libre à lui de passer outre en forçant l'accès en écriture ou d'ouvrir simplement en lecture.