Carnet d’Adresse, part 15 : v0_015 (liens personnes – groupes)

Précédemment, on a créé la vue V_p_Groupe qui affiche les liens entre les groupes et les personnes, et mis à jour le champ « nb_personne » de la table T_d_Groupe, pour tous les groupes existants.
Il est temps d’afficher ces liens à l’utilisateur.

Détail d’un groupe

Le code

Dans le menu de gestion des groupes, il faut ajouter un choix permettant d’afficher la vue détaillée d’un groupe, c’est-à-dire non seulement les informations du groupe lui-même (le nom du groupe, le nombre de personnes rattachées) mais aussi la liste des personnes rattachées.

La fonction VoirDetailData() permet d’afficher cette vue.
Elle attend en argument, comme beaucoup de fonctions de cette appli, vDonneeType et vDonneeId, soit le type et l’id de la donnée à gérer. Mais à ce stade, seules les données de type « groupe » sont gérées.

Bien sûr, pas de nouvelle fonction sans modification d’une fonction existante, pour l’appeler.
Ci-dessous, la nouvelle version de la fonction GererData() :

La démo

Détail d’une personne

On pourra afficher la vue détaillée d’une personne, à partir du menu de gestion des personnes, de la même manière, et en utilisant la même vue V_p_Groupe pour les liens personnes/groupes.

Le code

La fonction VoirDetailData devient :

Du côté de la fonction GererData, on propose d’afficher la donnée en détail pour les personnes en plus des groupes :

La démo

L’appli plante, on refait la manip en exécutant l’appli depuis l’IDE pour identifier le problème :

C’est donc cette ligne qui plante :

Rien de vraiment choquant, on va voir au niveau des données :

Dans la ligne de code 693, row[3] et row[4] font référence aux champs « adresse2 » et « adresse3 » :

Le message d’erreur parle de l’objet NoneType, a priori le fait d’avoir une valeur nulle.
Dans l’adresse 9, on a des valeurs vides à la place.
Essayons d’afficher le détail de Joe Lecowboy :

Pas d’erreur cette fois, ok.

La solution

Pour les données qui sont présentes actuellement dans la DB, il faut remplacer les valeurs nulles par des chaînes vides.
Et pour éviter que le problème se reproduise avec les futures données, il faut modifier le code qui permet de créer les données :

Les enregistrements de la table T_d_Adresse concernés sont :

On teste dans la console, la clause WHERE qui permet de filtrer sur les enregistrements concernés :

On remplace les valeurs nulles par des chaînes vides, puis on vérifie :

Tester comment est construite la requête lors de la création des données, on ajoute une ligne dans la fonction CreaData pour afficher la requête :

On crée une adresse, sans entrer de valeurs pour les champs « adresse2 » et « adresse3 ».
On a une chaîne vide pour ces champs :

On va voir avec SQLite Expert :

On a bien simplement des chaînes vides, et pas de valeurs nulles, rien à modifier concernant la création des données ; reste simplement à supprimer la ligne qui affiche la requête.

Concernant la mise à jour de données, vérifier la même chose :

Pour voir s’ils seront traités différemment, on valide le champ « adresse2 » sans valeur, et on met ‘/’ pour « adresse3 ».
Mais comme aucune valeur n’a été modifiée, la requête de mise à jour, UPDATE, n’a été ni exécutée ni construite.
On recommence en modifiant vraiment la valeur d’un champ :

Ok, la requête de mise à jour a bien été construite et exécutée, et seuls deux champs ont été mis à jour : « adresse1 » et « maj ».
La valeur des champs « adresse2 » et « adresse3 » est donc toujours une chaîne vide, normal, et donc tout va bien.
Là encore, reste simplement à supprimer la ligne de code dans MajData, qui a servi à afficher la requête.

Avec cette version de l’application, on n’a pas de nouvelles valeurs nulles dans la DB, donc pas de modif à faire au niveau du code, il faut
encore remplacer les valeurs nulles par des chaînes vides dans les autres tables :

Seules deux autres tables contiennent des valeurs vides : T_d_Email et T_d_Numero :

On reste dans SQLite Expert pour modifier les valeurs et vérifier :

Améliorer la navigation

L’application permet d’avoir la vue détaillée d’une personne ou d’un groupe, c’est bien mais à partir de la vue détaillée, on ne peut
que taper « entrée » pour aller au menu Principal :

Ce serait bien d’avoir le choix entre :
aller au menu Principal
retourner au menu de gestion des groupes
créer un groupe
modifier le groupe qu’on a affiché en détail
supprimer le groupe qu’on a affiché en détail
afficher la vue détaillée de l’une des personnes liées à ce groupe

code pour la vue détaillée des personnes

Quand on liste les groupes auxquels cette personne est liée, on affiche leur id, pour que l’utilisateur puisse ensuite désigner celui qu’il voudra voir en détail.

Pour la saisie utilisateur, on utilise donc la fonction ValidChoix2, comme dans GererData.
Elle traite correctement la saisie et prend en arguments : la liste des actions possibles, la règle associée à chacune (pour chaque action, faut-il renseigner un id), et la liste des id acceptés :

On déplace le code qui propose de taper « entrée » pour aller au menu Principal : il ne concerne plus que la vue détaillée des groupes.

test

Pour aller au menu Principal : ok.
Pour afficher la vue détaillée d’un groupe auquel la personne est rattachée : ok.

Tester une suppression annulée :

Tester une suppression confirmée :

On a un problème… l’intégrité référentielle a empêché l’exécution de la requête de suppression.
A priori, la fonction qui vérifie si la donnée est supprimable est erronée, elle ne prend peut-être pas en compte la table T_p_Groupe?

C’est la fonction DataLiee :

Lignes 858 et 859, on appelle la fonction InfoData pour récupérer des données.
Voici cette fonction :

Le problème s’explique : pour l’information « tables liees » pour les types ‘personne’ et ‘groupe’, la fonction retourne ‘Aucun’.
Mise à jour de cette fonction :

On teste la même manip, sauf que si la fonction DataLiee fait bien son boulot, elle devrait m’informer que je ne peux pas supprimer cette donnée ; et pour tester la suppression confirmée, il faudra donc afficher le détail d’une personne qui n’est rattachée à aucun groupe.

Ok parfait, on a bien cette fois le message qui nous annonce que la suppression est impossible.

Maintenant le test de la suppression confirmée, avec Joe Lecowboy :
Oops, un bug…
On recommence en exécutant l’appli à partir de l’IDLE :

La variable vListeId est utilisée alors qu’on ne lui a pas encore attribué de valeur, c’est directement dû au fait que cette personne n’est liée à aucun groupe.
Il faut placer cette ligne dans le même bloc que celui où vListeId est alimenté, mais aussi déplacer la ligne par laquelle on donne à vListeId une valeur d’initialisation, sinon l’appel à vListeChoix2 déclenchera une erreur car vListeId n’aura reçu aucune valeur.

test :

C’est déjà une avancée, on peut voir Joe Lecowboy. Essayons de le supprimer :

Tout semble ok, on affiche le menu de gestion des personnes pour vérifier, Joe Lecowboy ne devrait pas y apparaître :

Ok.

code pour la vue détaillée des groupes

Premier test : afficher la vue détaillée d’un groupe, puis aller au menu Principal :

Test ok.
Essayons d’afficher la vue détaillée d’un groupe, puis la vue détaillée d’une personne rattachée à ce groupe :

Test ok.
Essayons de supprimer ce groupe ; la suppression devrait être refusée :

Test ok.
Maintenant, une tentative de suppression d’un groupe auquel aucune personne n’est liée ; la suppression devrait être accpetée :

La suppression semble avoir été effectuée ; on affiche le menu de gestion des groupes pour vérifier :

Pas de trace du groupe « voisins », ok.

CarnetAdrese v0-015

Puisque les tests sont concluants, ce sera tout pour cette fois, voici les liens vers :
l’application
la DB