PHP/MySQL
Tablutils


Introduction

L'ensemble Tablutils a pour vocation de permettre de développer rapidement certaines parties fastidieuses d'une application de base de données telles que les formulaires de saisie et les validations afférentes, les formulaires de recherche et les affichages de résultat. En ce qui concerne les validations, je ne l'ai pas traitée côté client en JavaScript (par exemple), ce qui signifie qu'il y a toujours un aller/retour avec le serveur. Je sais c'est moins élégant mais j'ai voulu faire simple pour commencer.

Je suis parti du postulat que les mécaniques totalement systémiques (style phpMyAdmin) étaient inadéquates pour ce que je voulais obtenir. Je n'en prendrai que quelques exemples immédiats (vous découvrirez les autres plus loin) :

  1. On ne souhaite pas toujours que le libellé d'un champ dans un formulaire soit égal au nom du champ, parfois peu parlant pour celui qui saisit
  2. On ne souhaite pas toujours que tous les champs soient affichés et saisis
  3. MySQL ne gérant pas l'intégrité référentielle il peut être bon de lier la saisie d'un champ à l'existence de la même valeur dans un autre champ d'une autre table
  4. Il est bon de pouvoir vérifier l'existence de doublons sur les champs à valeur unique avant que l'utilisateur ne se prenne un message d'erreur MySQL dans la figure
  5. On veut souvent pouvoir spécifier les champs à saisie obligatoire (et là encore c'est mieux de le gérer que de laisser les messages d'erreur MySQL s'afficher)
  6. On souhaite parfois des comportements différents dans le formulaire de saisie et dans celui de recherche (champs affichés ou non, valeur nulle dans les listes déroulantes, etc.).

La première idée de base fut donc de séparer la description de ce que l'on souhaitait obtenir de l'implémentation des algorithmes de façon à rendre générique la plus grosse partie possible du code.

La seconde idée était que, sauf cas particulier de traitement plus subtil et/ou plus complexe que dans la situation standard, la partie de code spécifique à chaque formulaire particulier devait néanmoins être la plus semblable possible d'un formulaire à l'autre de sorte qu'un simple copier/coller suivi d'un minimum d'ajustements permette de générer rapidement des formulaires pour plusieurs tables d'une application.

C'est dans cet esprit, je dirais... économique, que j'ai commencé à concocter ce qui suit. J'espère que certains y trouveront un gain de ce temps qui nous est si précieux à tous. Bien entendu, les remarques et suggestions diverses sont les bienvenues et influeront peut-être sur mes priorités futures. Je réclame, bien sûr, votre indulgence. Je n'ai aucune prétention en présentant cet ensemble, ni d'exhaustivité ni même d'élégance. J'ai simplement bâti ma programmation de cette façon à des fins personnelles et la seule chose que je souhaite est de faire partager à ceux que ça intéresse le fruit de ce travail. Je ne me fais aucune illusion, il y a sûrement mieux ailleurs.

Le fichier descripteur

Le fichier descripteur sert juste à définir dans une variable $descript, de type tableau de tableaux associatifs.

Chaque élément représente un champ du formulaire et à l'intérieur de chaque élément sont définies (dans un tableau de type associatif, clé=>valeur) les caractéristiques de ce champ de formulaire.

Aujourd'hui, les caractéristiques suivantes sont utilisées ou en voie de l'être :

Variable Valeurs Signification Vide autorisé Implémenté
label   C'est le texte affiché devant la zone de saisie
S'il commence par un "#", le champ n'est pas affiché dans la fiche de saisie. Il peut l'être par contre dans la fiche d'interrogation, selon le privilège de l'utilisateur.
Oui Oui
nom   nom du champ destinataire dans la table
(aucune vérification d'existence n'est faite, c'est du ressort du programmeur]
Non Oui
defaut   valeur par défaut dans la zone de saisie Oui Oui
oblig true, false   ? Oui
uniq true, false   ? Oui
reftab   nom de la table de référence Oui Oui
refchamp   nom du champ de référence (valeur renvoyée) Oui Oui
reflistchamp   nom du champ utilisé pour l'affichage de la liste
(peut être identique au précédent)
Oui Oui
typechamp memo le type de champ de formulaire est "textarea" au lieu de "input" Oui Pas encore

Avertissements

  1. Attention, aucun contrôle de cohérence avec la structure de la table concernée n'est effectué. C'est au programmeur de s'en assurer.
  2. Les tableaux associatifs permettant une certaine souplesse, point n'est besoin de saisir, dans chaque champ, les variables dont le contenu serait vide. Cependant, voire la chose en terme de préférences personnelles lors de la relecture de la structure, plus tard.

exemple

exemple de fichier descripteur à inclure dans les scripts formulaires de saisie ou de recherche
<?
$descript = array(
1 => array (
"label"
=>"Identificateur",
"nom"
=>"objetID",
"defaut"
=>"",
"oblig"
=>true,
"uniq"
=>true),
2 => array (
"label"
=>"Type",
"nom"
=>"Type",
"defaut"
=>"",
"oblig"
=>true,
"uniq"
=>false,
"reftab"
=>"objet_type",
"refchamp"
=>"type",
"reflistchamp"
=>"type"),
3 => array (
"label"
=>"Nom",
"nom"
=>"Nom",
"defaut"
=>"",
"oblig"
=>true,
"uniq"
=>false),
4 => array (
"label"
=>"Ville",
"nom"
=>"Ville",
"defaut"
=>"",
"oblig"
=>false,
"uniq"
=>false),
5 => array (
"label"
=>"Code postal",
"nom"
=>"CodePostal",
"defaut"
=>"",
"oblig"
=>false,
"uniq"
=>false)
);
?>

Le script de saisie/validation générique

Vous trouverez ici le fichier cree_brut.php (sous forme de cree_brut.php.txt), une des moutures de ce script. Elle peut être utilisée telle quelle. Elles comporte en fait deux fonctions. Une fonction de saisie et une fonction de vérification. Il reste encore des lignes de déboguage mises en remarque. Vous pouvez les supprimer.

Ce fichier doit être inclus (include ou require) dans les scripts de saisie spécifiques. Il comporte lui-même en inclusion, un petit fichier comportant une fonction de création de liste de sélection, très paramétrable, dans un formulaire.

Le script de saisie spécifique à chaque formulaire

Ce script est celui qui inclut les deux précédents, entre autres. En voici un exemple ci-dessous. J'ai pris pour parti (on verra pourquoi plus loin) de faire commencer tous mes fichiers descripteurs par les caractères "desc_". Donc les deux premières lignes du script ci-dessous servent à inclure le fichier descripteur et le fichier de traitement générique.

exemple de script formulaire de saisie
<?
require ("desc_obj.php");
require ("cree_brut.php");

if ($act=="saisie")
{
$titre="Ajouter un objet";
saisie("addobj.php", $titre, $descript);
}
elseif ($act=="verif")
{
$recommence="non";
for ($i = 1 ; $i<=count($descript) ; $i++)
{ $descript[$i]["defaut"]=${$descript[$i]["nom"]};
}
// paramètres : lien si fini, lien si continuer saisie, table, données, incorrect ou pas
verif("accueil.php","addobj.php", "objets", $descript, $recommence);
}
else
{
echo "<H3>Fonction \"$act\" non reconnue dans addobj !</H3><HR>";
}
?>

Commentaires

  1. En surligné jaune, ce qui change d'un formulaire à un autre, dans le cas de formulaires standards. Le reste peut être copié/collé.
  2. $titre est le titre du formulaire
  3. Le premier paramètre de la fonction saisie est le nom du fichier de saisie qui se rappelle lui-même pour traiter la saisie :
    echo"<form action=\"$act\" method \"post\">\n"
    et plus loin :
    echo"<BR><BR>Pour entrer les données dans la base veuillez Valider.<BR>
    <input type=\"hidden\" name=\"act\" value=\"verif\">
    <HR><input type=\"submit\" value=\"Vérifier et valider\"></FORM>";
  4. Le deuxième paramètre est donc le titre
  5. Le troisième paramètre est la structure descriptive du formulaire
  6. Le premier paramètre de la fonction verif est la page où l'on va si l'on ne veut plus saisir de nouvelle fiche.
  7. Le deuxième celle où l'on va pour continuer la saisie (c'est donc la page elle-même)
  8. Le troisième est la table MySQL concernée par la saisie
  9. Le quatrième le fichier descripteur
  10. Le cinquième un indicateur pour savoir si l'on doit recommencer la saisie.

E. Durup 04/07/2001