truc2geek

2012/10/24

Carnet d’Adresses, part 3 : v0_004

Filed under: Carnet d'adresses (Python), Programmation, Projets, Python, SQLite — truc2geek @ 21:57

Objectif

Dans cette version, on va créer la fonction GererPersonne, qui permettra de gérer les données de type ‘personne’, c’est-à-dire que les personnes existantes seront listées, et l’utilisateur pourra saisir ce qu’il souhaite faire : retourner au menu principal, créer une personne, modifier une personne ou supprimer une personne.
On va aussi créer la fonction ValidChoix2, qui permettra comme la fonction ValidChoix, de demander une saisie à l’utilisateur et de la valider. On ajoute ici la notion d’identifiant : car selon ce que l’utilisateur compte faire, il doit fournir un identifiant de personne : la fonction ValidChoix2 devra donc connaître quels identifiants sont valides, et dans quel cas un identifiant doit être saisi.

pour rappel, voici le contenu de la table ‘T_d_Personne’ tel qu’affiché par SQLite Expert :

les champs de la table sont ‘id_personne’, ‘prenom’, ‘nom’, ‘id_adresse’, ‘crea’ et ‘maj’.
‘RecNo’ est affiché par SQLite Expert et ne fait pas partie de la table.

les fonctions créées ou modifiées

la fonction GererPersonne

ci-dessus :
on se connecte à la BD
on exécute la requête de sélection
on initialise la variable vListeId, de type liste, dans laquelle on va stocker tous les identifiants des personnes (champ ‘id_personne’ de la table ‘T_d_Personne’)
on boucle sur les enregistrements, et pour chacun :

  • on ajoute son id à la liste
  • on affiche la valeur des trois premiers champs, qui correspondent aux champs ‘id_personne’, ‘prenom’ et ‘nom’

on se déconnecte de la BD
on supprime de la liste des identifiants la valeur ‘ini_liste’

ci-dessus :
après avoir affiché à l’utilisateur la liste des personnes existantes, il faut lui donner la possibilité :
de revenir au menu principal
de créer une nouvelle personne
de modifier une personne
de supprimer une personne

Si l’utilisateur souhaite modifier ou supprimer une personne, il devra indiquer laquelle.
on définit qu’il devra simplement ajouter après le choix de l’action, un espace suivi de l’identifiant de la personne.

la fonction ValidChoix, qu’on utilise pour demander à l’utilisateur de saisir un choix puis valider ce choix, ne sera pas appropriée ici.
On créera une autre fonction, nommée ValidChoix2, à laquelle on transmettra 4 arguments :
la liste des actions possibles
la liste des identifiants possibles
la liste des règles : pour chaque action possible, un identifiant doit-il être fourni
un message pour guider l’utilisateur dans la saisie

La variable de type liste nommée vLAct contiendra la liste des « actions possibles », c’est-à-dire des entrées qui seront considérées valides
La variable vLRegle contient soit ‘0’ soit ‘1’ pour chaque action possible ; ici ‘0’ pour les actions ‘0’ et ‘1’ (retour et création), et ‘1’ pour les actions ‘2’ et ‘3’ (modification et suppression)

et enfin, on appelle la fonction ValidChoix2.

ci-dessus :

la variable vChoix1 est de type liste et contient au moins 1 élément : l’action (valeur de 0 à 3 dans ce cas).
Si l’action vaut 2 ou 3 (pour modification ou suppression), vChoix1 contient un autre élément : l’identifiant de la personne.

on commence par stocker dans la variable vAct le 1er élément de la liste.

  • Si vAct vaut ‘0’, l’utilisateur a demandé à retourner au menu principal, on appelle donc la fonction Principal().
  • Si vAct vaut ‘1’, on se contente d’afficher ‘traitement a coder’ pour indiquer que l’application ne le permet pas encore dans cette version ; puis on renvoie l’utilisateur vers le menu principal.
  • sinon, on stocke dans la variable vId le 2e élément contenu dans vChoix1, qui est l’identifiant de la personne qu’il faut modifier ou supprimer.
    Là encore on affiche ‘traitement a coder’ et on renvoie l’utilisateur vers le menu principal.

la fonction ValidChoix2

On initialise la variable vSaisieOk à False, et on ne sortira de la boucle que lorsque cette variable aura pour valeur True.

Ligne 82, on demande une saisie à l’utilisateur

Lignes 84-85, on définit simplement qu’en cas de saisie vide, on ne fait rien. Ainsi dans ce cas, on revient simplement au début de la boucle.

On extrait le premier caractère de la chaîne saisie et on vérifie que ça correspond à une valeur de vLChoix1 : dans le cadre de la gestion des personnes, vLChoix1 correspond aux actions possibles, de 0 à 3.

Si c’est une valeur valide, on détermine l’indice de cette valeur dans vLChoix1 (ligne 92) et on extrait la valeur correspondante dans la chaîne vLRegle (ligne 93).

Si la règle est ‘0’, cela signifie qu’on n’attend pas d’identifiant pour cette action : on retourne la valeur ‘action’ convertie en variable de type liste.

Si la règle est ‘1’, on attend un identifiant : on extrait alors cet identifiant à partir du 3e caractère de la saisie (ligne 101). Si l’identifiant saisi figure dans la liste des identifiants possibles (vLChoix2), on retourne une liste contenant deux élément : l’action et l’identifiant.

Cette fonction ne fait que demander une saisie, la contrôler de manière plus ou moins flexible, et en retourner les éléments si elle est correcte.

La fonction Principal est modifiée

Cette fonction affiche le menu principal, puis appelle la fonction correspondant au choix de l’utilisateur.
Ce menu contenait « Accueil » et « Recherche » ; on ajoute « gérer adresses », « gérer groupes », « gérer personnes ».

note sur le nom de la BD :

dans l’article ‘Carnet d’Adresses, part 1 : début projet’, j’avais nommé la Base de Données ‘Carnet.db’.
dans l’article ‘Carnet d’Adresses, part 2 : code minimal’, dans la fonction TestDb() implémentée dans la v0_003, on recherche un fichier nommé ‘CarnetAdresse’.

Cela ne correspond pas, c’est mal! Pour corriger ça : la BD est dorénavant nommée ‘CarnetAdresse.db’ et le code de la fonction TestDb() est adapté.

l’appli version v0_004

Voici les liens pour télécharger :
le code complet de CarnetAdresse_v0_004.py
la BD

manipuler l’appli

Voyons à quoi ressemble l’appli maintenant :

si la BD est bien présente dans le même dossier que l’application, l’écran d’accueil est le suivant :

on entre volontairement un choix inexistant, 7,  pour vérifier ce qui se passe :
comme prévu, rien ne se passe. L’application attend simplement une nouvelle saisie.

On pourrait rendre ce fonctionnement plus clair pour l’utilisateur.
La fonction Accueil() appelle la fonction AfficherMenu(), qui appelle à son tour la fonction ValidChoix().
Cette dernière fonction accepte un paramètre optionnel nommé vTxtChoix.

Une manière de faire :
ajouter ce paramètre aussi à ceux attendus par la fonction AfficherMenu()
dans la fonction Accueil, passer à la fonction AfficherMenu() une valeur telle que ‘saisissez votre choix : ‘

Ainsi, au lieu de simplement voir deux fois le trait clignotant indiquant que l’application attend une saisie, l’utilisateur verrait deux fois le texte ‘saisissez votre choix : ‘, ce qui indiquerait un peu plus clairement que la première saisie était erronée.

On entre 1 et on valide, pour accéder au menu principal :

c’est l’option « gérer personnes » qui nous intéresse :

on entre « 1 » et on valide pour créer une personne :
cette fonctionnalité n’est pas encore codée, on est redirigé vers le menu principal.

Voilà pour cette version 0_004.

Publicités

Laisser un commentaire »

Aucun commentaire pour l’instant.

RSS feed for comments on this post. TrackBack URI

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Propulsé par WordPress.com.

%d blogueurs aiment cette page :