Après la correction de quelques bugs, on va terminer de mettre en place la mise à jour des données.
Les fonctions modifiées sont :
ValidChoix()
SelecId()
DefData()
DefDataAfficher()
InfoSpecial()
AfficherData()
CreaData()
SuppData()
MajData()
TestDb()
Les fonctions ajouétes sont :
SaisieMaj()
FormaterValSql()
Les fonctions modifiées
ValidChoix() 
Cette fonction attend un argument supplémentaire, vVide, optionnel et qui vaut False s’il est omis.
Il indique si une saisie vide est autorisée.
SelecId() 
La version précédente de SelecId() attendait seulement deux arguments : vDonnee et vChamp. On a ajouté vManip, vObl et vValActu :
vManip vaut soit ‘crea’ soit ‘maj’, selon si SelecId est appelée par CreaData ou MajData
vObl permet de préciser à l’utilisateur si la sélection est obligatoire ou facultative
vValActu permet de préciser à l’utilisateur la valeur actuelle (qu’il peut garder en saisissant directement ‘/’)
DefData()
Cette fonction n’a pas véritablement changé : dans les commentaires on précise l’utilité de vLChampDef, et dans le code on a mis des espaces qui manquaient, par exemple ici entre ‘vLChampObl’ et le signe ‘=’ :
DefDataAfficher()
Seuls les commentaires ont changé.
InfoSpecial()
Un seul changement, lignes 586 et 587 : si vDonneeId vaut None, on retourne une chaîne vide.
Cela permet de gérer le cas où, pour un champ clé étrangère qui n’attend pas obligatoirement une valeur, l’utilisateur a laissé le champ vide.
Sans ces deux lignes, InfoSpecial concatène les valeurs puis exécute la requête, mais ça plante bien sûr :
AfficherData()
On a ajouté la ligne 636, pour utiliser la variable globale vgEncodage.
La ligne 648 permet de récupérer la liste vLChampType de DefData, donne le type des champs : ‘texte_80’, ‘nombre’, ‘id’…
Le bloc try-except se sentait tellement bien là qu’il a oublié de partir.
Lignes 660-661, on convertit en texte la valeur si c’est un id ou un nombre (dans ces deux cas, la valeur est un numérique)
CreaData()
Une seule modification : l’appel de la fonction SelecId
SuppData()
La suppression était autorisée seulement si la fonction DataLiee retournait ‘non’.
Or cette fonction peut retourner trois valeurs : soit ‘Aucun’, soit ‘non’, soit ‘oui_x_y’.
La valeur de retour ‘Aucun’ correspond au cas où la donnée est forcément supprimable, car aucun champ de clé étrangère ne fait
référence à la table contenant cette donnée.
Le cas ‘Aucun’ était traité comme le cas ‘oui’, or il doit être traité comme le cas ‘non’, c’est maintenant le cas.
MajData()
Dans la version v0_012, cette fonction ne faisait qu’afficher la donnée dans son état actuel.
On a ajouté :
récupérer la définition des données
copier la liste, ligne 884, par la méthode vue dans l’article précédent, qui crée bien une nouvelle liste à partir de la première, et pas simplement un nouveau pointeur vers la même variable
demander la nouvelle valeur pour chaque champ, en appelant soit SelecId soit SaisieMaj
afficher la donnée dans son état avec les nouvelles valeurs
demander à l’utilisateur de valider ou annuler la modification
si l’utilisateur valide, constituer la requête de mise à jour, uniquement pour les champs dont la valeur a changé
TestDb()
Seule la ligne 1104 a changé, on a ajouté le ‘u’ juste avant la chaîne de fin de phrase.
Les fonctions ajoutées
SaisieMaj()
Cette fonction demande à l’utilisateur de saisir une valeur, en lui précisant quelle est la valeur actuelle, et qu’il peut saisir simplement un slash pour garder cette valeur.
Une valeur est exigée ou pas selon l’argument vObl, et le type de donnée saisi est vérifié selon l’argument vType (nombre ou texte, les dates ne sont pas traitées donc pour l’instant)
FormaterValSql()
Met en forme une valeur pour l’intégrer à une requête SQL.
Pour une valeur d’id qui vaut None, comme pour un nombre ou une date non renseigné, on remplace par NULL.
liens pour CarnetAdresse v0_013
Voici les liens vers l’application et la DB.
Test :
On va tester si l’appli fonctionne bien dans le cas de la saisie facultative d’un id.
Pour cela il faut créer avec une version alternative de la DB, car on a un seul champ clé étrangère que le code de l’application peut déjà gérer, et il est obligatoire.
On modifie la ligne 29 du fichier isql1.txt pour supprimer « NOT NULL », on garde les fichiers isql2.txt et isql3.txt originaux.
La création de la DB à partir de ces fichiers :
Une petite vérif, on affiche le contenu de la table T_d_Personne :
On quitte :
Il nous reste à modifier une information dans le code de la version v0_013 pour cet test :
dans la fonction DefData, on indique que le champ ‘id_adresse’ de la table ‘T_d_Personne’ est facultatif :
on lance l’application, menu principal, menu des personnes
on modifie la personne Tiffany Delaroue, en gardant son nom et son prénom, on ne sélectionne aucune adresse :
on valide :
On quitte l’application.
On vérifie par la console, le contenu de T_d_Personne puis de V_Personne
Tout est ok quand on affiche le contenu de la table T_d_Personne : on a bien l’enregistrement pour Tiffany Delaroue, sans aucune valeur dans le champ id_adresse.
Par contre, l’enregistrement est absent de la vue V_Personne.
Pour rappel, voici l’instruction SQL par laquelle on a créé cette vue :
Le type de jointure, ‘INNER JOIN’, définit comment le lien entre les deux tables source sera fait.
On va supprimer la vue pour la recréer avec un autre type de jointure : LEFT OUTER JOIN
Cette fois-ci, on retrouve bien l’enregistrement 8, Tiffany Delaroue, dans la vue V_Personne.
Ce test est terminé, le but était de vérifier que l’application permettait de ne pas sélectionner d’identifiant dans le cas d’un champ identifiant facultatif : c’est chose faite avec cette version alternative de l’application et de la DB.
On continue en reprenant la version v0_013.
Recette
Etant donné qu’on a apporté beaucoup de modifications à l’application, on va effectuer une recette c’est-à-dire un test.
C’est indispensable pour vérifier que les nouvelles fonctionnalités se comportent comme attendu, et que les fonctionnalités existantes n’ont pas été altérées.
Pour chaque type de donnée que l’application gère, on va tester : la modification, la suppression, la mise à jour.
création d’une personne
On renseigne un prénom, un nom, on sélectionne une adresse et dès qu’on tape ‘entrée’ pour valider la sélection de l’adresse, on est redirigé vers le menu principal.
Pour une création donc, on n’a pas la possibilité de valider ou d’annuler la création.
Ok.
mise à jour d’une personne, annulée
On lance une mise à jour de l’enregistrement Jim Marshall.
On annule la mise à jour, puis on affiche le menu de gestion des personnes pour vérifier que la mise à jour a bien été annulée.
Ok.
mise à jour d’une personne, validée
De nouveau, on lance la mise à jour de Jim Marshall :
Cette fois on valide ; ensuite on affiche le menu pour vérifier que la mise à jour a bien été effectuée :
Ok.
suppression d’une personne, annulée
On demande la suppression, on annule, on vérifie :
Ok.
suppression d’une personne, validée
On demande la suppression, on valide puis on vérifie :
Ok.
les groupes et les adresses :
Faire les mêmes vérifs pour ces données.
résultat de la recette
Aucune anomalie constatée, cette version de l’application est validée. Oh yeah!
La suite
Il reste pas mal de choses à faire : proposer de valider/annuler la création des données, lier les personnes aux groupes, gérer les numéros de téléphone et les emails…
Laisser un commentaire