|
Chapitre 25 :
les formulaires simples |
|
|
1 - Introduction |
|
|||||||
|
|
|
Le
formulaire est souvent considéré
comme le troisième objet des bases de données, par ordre d'importance décroissante,
après la table et la requête. En fait, son importance réelle dépend de la
manière dont on utilise le SGBD. |
|
||||||
|
|
|
Le
formulaire est avant tout un outil de saisie d'information au clavier.
A ce titre, il entre en concurrence avec : |
|
||||||
|
|
|
|
|
||||||
|
|
|
La
facilité d'écriture directe dans les tables peut varier de très pratique à
parfaitement impraticable suivant les cas. Un formulaire peut rendre la
saisie de certaines informations plus facile, principalement dans les SGBD
qui, au contraire d'Access, n'affichent pas les sous-feuilles
de données. Enfin, les formulaires permettent l'ajout de boutons, menus, etc.
qui donnent à l'application un aspect très "fini". Les SSII
(sociétés de service en informatique) soignent donc les formulaires pour
donner la meilleure impression possible à leur client -- surtout si ce
dernier n'est pas capable de juger sur autre chose que la présentation. |
|
||||||
|
|
|
Certaines
bases de données sont principalement alimentées en données par importation des données : le formulaire
ne sert alors plus à rien. C'est, par exemple, le cas des magasins à grande
surface, qui alimentent leur BDD directement et en temps réel depuis les
caisses enregistreuses. C'est aussi le cas des sites web qui déversent
quotidiennement leur fichier journal dans la BDD qui sert au suivi du site et
à la mesure d'audience. C'est encore le cas de tous ceux qui font de
l'acquisition de données via des capteurs couplés à des ordinateurs, etc. |
|
||||||
|
|
|
Accessoirement,
le formulaire sert aussi d'outil de visualisation, c'est à dire de
consultation du contenu de la base à l'écran. On reproche parfois au
formulaire de montrer les enregistrements un par un, alors qu'une table en
montre un grand nombre à la fois, mais on peut concevoir le formulaire de
telle sorte que sa présentation soit très proche de celle d'une table. |
|
||||||
|
|
|
Cette
discussion peut en fait se résumer ainsi : |
|
||||||
|
|
|
|
|
||||||
|
|
|
Comme
pour l'ensemble de ce tutoriel (encore appelé
"cours en ligne" ou tutorial), nous utiliserons le SGBD Access
comme support pratique. |
|
||||||
|
|
|||||||||
|
|
2 - La création d'un formulaire simple |
|
|||||||||||||
|
|
|
Un
formulaire est avant tout un outil permettant de saisir au clavier des
données qui sont immédiatement introduites dans une ou plusieurs tables. Le
formulaire est donc lié à une ou à plusieurs tables, et il hérite de leurs
propriétés : types de données, propriétés des champs, listes de choix et
protection contre les doublons via un index. A l'inverse, les propriétés du
formulaire ne rejaillissent pas sur les tables sous-jacentes. Il arrive enfin
que l'on puisse attribuer à un champ de formulaire une propriété qui modifie
ou contredit celle du champ correspondant de la table. |
|
||||||||||||
|
|
|
Pour
étudier les formulaires, nous utiliserons une table (nommée "Personnes")
dotée d'une liste de choix (nommée "Communes"), comme le montre la
figure ci-dessous. Nous faisons en sorte (comme expliqué au chapitre 3)
que le nom de la commune, et non son code, s'affiche
dans le champ "Code_commune" de la table
"Personnes". |
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
Pour
travailler sérieusement, nous créons un index sans doublon sur les champs Nom+Prénom
dans "Personnes", et sur les champs "commune+code postal dans
"Communes". Nous interdisons de plus le Null
et la chaîne vide dans tous les champs sauf "Adresse". Le champ
"code_commune" de la table
"Communes" est du type NuméroAuto. |
|
||||||||||||
|
|
|
Créons,
pour commencer, un formulaire simple qui nous permette de saisir les noms des
communes et les codes postaux correspondants. Dans la fenêtre "Base de
données", nous sélectionnons (colonne de gauche) l'objet
"Formulaires". Nous double-cliquons sur "Créer un formulaire à
l'aide de l'Assistant" et nous répondons aux demandes de ce
dernier : |
|
||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
Voici
comment se présente le formulaire, dont le nom apparaît désormais dans la
fenêtre "Base de données" : |
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
Le
formulaire est constitué d'étiquettes
(les noms des champs dans la table) et de contrôles
correspondant aux champs de la table. Lorsqu'ils sont directement dérivés de
la table, les contrôles sont appelés "contrôles dépendants", ou
encore "champs". La table à partir de laquelle est construit le
formulaire est la table sous-jacente. |
|
||||||||||||
|
|
|
Nous
constatons d'abord que nous pouvons examiner le contenu de la table
"Communes" enregistrement par enregistrement, le formulaire jouant
alors son rôle d'outil de visualisation. Certes, l'aspect est plus
joli que celui de la table, mais cette dernière présente l'avantage de nous
donner une vue globale des informations. Si nous avions choisi la
disposition "Tabulaire", nous aurions obtenu une présentation par
lignes plus proche de la table sous-jacente. La disposition "Feuille de
données", quant à elle, fournit une présentation pratiquement identique
à celle de la table sous-jacente. |
|
||||||||||||
|
|
|
Nous
constatons ensuite que nous pouvons nous placer sur la première ligne vide de
la table sous-jacente, et saisir des données (noms et prénoms des personnes).
Ces données sont automatiquement introduites dans la table sous-jacente,
comme nous pouvons le constater en fermant le formulaire et en ouvrant la
table. Le formulaire joue alors son rôle d'outil de saisie des données.
Mais les problèmes de synchronisation que nous avons déjà rencontrés
demeurent : si nous laissons la table sous-jacente ouverte, nous
constatons que les données saisies dans le formulaire n'y apparaissent pas.
On peut fermer, puis rouvrir la table sous-jacente, pour que les nouvelles
données s'y trouvent inscrites, mais il est plus simple de rendre la table
active, de cliquer dans le menu sur "Enregistrements", puis sur
"Afficher tous les enregistrements". La table se complète
immédiatement. |
|
||||||||||||
|
|
|
Notons
que le formulaire nous présente les informations dans l'ordre où elles se
trouvent dans la table sous-jacente. Pour faire en sorte que les informations
apparaissent triées, nous disposons de plusieurs méthodes : |
|
||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
3 - La mise en forme du formulaire |
|
||||||||||
|
|
|
Il
est fréquent que les administrateurs de BDD empêchent les utilisateurs de
voir les tables (et par la même occasion, d'effectuer des requêtes -- quelle
politique !). Les formulaires constituent alors (avec les états et les
menus, que nous étudierons plus loin) la seule interface entre la base et ses
utilisateurs. Le SGBD Access met à disposition des concepteurs de BDD de
multiples outils permettant de rendre cette interface aussi soignée que
possible. Avec la mise en forme du formulaire, nous entrons quelque peu dans
le domaine de l'informatique "cosmétique". |
|
|||||||||
|
|
|
Sélectionnons
le formulaire que nous venons de créer, et cliquons sur l'icône |
|
|||||||||
|
|
|
Comme
les tables et les requêtes, le formulaire se présente donc sous deux aspects
: |
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
Le
mode création met à notre disposition de multiple outils (entre lesquels il
existe une redondance partielle) pour modifier le formulaire que nous avons
créé. Nous pourrions même les utiliser pour créer le formulaire de toutes
pièces, mais il est plus simple de passer d'abord par l'assistant. Ces outils
peuvent être regroupés ainsi : |
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
La
mise en forme d'un formulaire, avec ses très nombreuses possibilités, fera
l'objet d'une annexe (décembre 2002). Nous reviendrons plus loin sur certains
usages particuliers de la boite à outils. Voici ce que devient la figure
précédente après un léger lifting : |
|
|||||||||
|
|
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
|
4 - Le perfectionnement du formulaire |
|
|||||||||||||
|
|
|
Pour
modifier les propriétés d'un formulaire, il faut ouvrir sa feuille de
propriétés de la manière suivante : |
|
||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
Dans
le formulaire tel qu'il est, nous pouvons non seulement saisir de
nouvelles données, mais aussi modifier ou supprimer des données existantes.
Cette possibilité peut être fort dangereuse, et nous pouvons la supprimer en
basculant la propriété "Modif autorisée"
de "Oui" à "Non". En revenant en mode formulaire, nous
constatons que désormais, les données enregistrées (par fermeture du
formulaire) ne peuvent plus être modifiées. Cette interdiction est très
gênante en cas d'erreur de saisie, mais elle ne s'étend pas à la table
sous-jacente. |
|
||||||||||||
|
|
|
Nous
pouvons aller plus loin, et cacher complètement les enregistrements déjà
saisis. Les enregistrements nouvellement saisis seront cachés à leur tour dès
que nous refermerons le formulaire. Pour ce faire, nous basculons la
propriété "Entrée données" de "Oui" à "Non". En
revenant en mode formulaire, nous constatons qu'aucune donnée ne s'affiche.
Nous pouvons, par contre, saisir de nouvelles données. |
|
||||||||||||
|
|
|
Nous
pouvons aussi faire en sorte que le formulaire ne permette pas la
modification des données, c'est à dire qu'il serve uniquement de dispositif
de visualisation. Pour ce faire, nous basculons la propriété "Ajout
autorisé" de "Oui" à "Non", puis nous revenons au
mode formulaire. Nous pouvons ainsi donner à un utilisateur la possibilité de
consulter la base, mais sans pouvoir en modifier le contenu. |
|
||||||||||||
|
|
|
Recréons
le formulaire des communes en incluant le champ "code_commune".
Nous constatons que nous pouvons introduire le curseur dans ce champ, mais
que nous ne pouvons pas le modifier. Le type de données est NuméroAuto, et seul le SGBD peut écrire dans ce champ.
Dans le formulaire, cette propriété est héritée de la table sous-jacente.
Pour ne pas agacer la personne qui utilise le formulaire, nous pouvons faire
en sorte que le curseur ne passe plus dans le champ "code_commune".
Plusieurs solutions s'offrent à nous. |
|
||||||||||||
|
|
|
Pour
modifier les propriétés d'un contrôle ou d'une étiquette, nous pouvons faire
apparaître la feuille de données comme ci-dessus, et sélectionner l'objet
dans la liste déroulante qui se trouve tout en haut. Nous pouvons aussi
sélectionner l'objet en mode création , effectuer un
clic droit, et choisir "Propriétés". |
|
||||||||||||
|
|
|
Sélectionnons
l'onglet "Autres", et basculons la propriété "Arrêt
tabulation" de "Oui" à "Non". Quand nous revenons au
mode formulaire, nous constatons que le curseur ne peut plus être placé dans
le champ "code_commune", bien que la
valeur de ce dernier continue à s'afficher. |
|
||||||||||||
|
|
|
Nous
pouvons aussi sélectionner l'onglet "Donnée", et basculer la
propriété "Activé" de "Oui" à "Non" (la
propriété "Verouillé" étant sur
"Non"). Quand nous revenons au mode formulaire, nous constatons que
le contrôle "code_commune" et son
étiquette sont grisés, comme lorsqu'une fonction n'est pas disponible dans un
menu. De plus, le curseur ne pénètre plus dans le champ. La figure suivante
illustre cette situation : |
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
Basculer
la propriété "Verrouillé" à "Oui" (la propriété
"Activé" étant sur "Oui") a pour conséquence d'empêcher
la modification du contenu du champ, sans en modifier l'aspect et sans empêcher
le curseur d'y pénétrer. Cela ne nous est d'aucune utilité dans le cas
présent, puisque le champ "code_commune"
hérite déjà de cette propriété de par son type de données NuméroAuto. |
|
||||||||||||
|
|
|
Pour
consulter la suite, qui traite des formulaires basés sur deux tables, cliquez
sur la flèche droite ci-dessous. |
|
||||||||||||
|
|
|||||||||||||||