Ayant eu le besoin de réaliser un formulaire, j’ai choisi de tester un peu la techno Ajax et d’en mesurer les avantages et inconvénients

Vous trouverez ci-dessous un petit tutoriel pour installer et utiliser un système de formulaires web utilisant la technologie AJAX, très facile et rapide d’installation et de configuration une fois que vous en avez compris les principes.

Le cahier des charges que je me suis fixé était le suivant :

• faire un système de formulaire simple à implémenter
• qu’il soit générique et ne nécessite quasiment pas de programmation pour implémenter un nouveau formulaire
• que les validations soient réalisées au niveau serveur
• que les informations de validation soient communiquées en temps réél au client
• qu’il soit le plus sécurisé possible (notamment : impossibilité pour le client de passer outre les validations en modifiant les javascript par exemple)
• en Php et Mysql
• en séparant clairement fond et forme (xhtml 1.1)

J’ai commencé par tout coder directement manuellement, puis à force d’améliorations, je me suis orienté vers des librairies plus génériques : prototype et script.aculo.us.

Le formulaire est très simple, il s’appuie sur :

• une table dans une base de donnée Mysql
• une page php ‘backend’ qui réalise les validations et les updates en base
• une page php ‘frontend’ qui affiche le formulaire

ci-dessous le schéma général, y compris les includes.

Le principe est de surveiller un événement sur les champs du formulaire (par exemple, focus, blur, keyup) et sur cet évènement on déclenche un appel Ajax vers la page en back office. On transmet à cette page l’id de l’enregistrement, le nom du champ qui est en train d’être mis à jour et sa valeur. La page en backoffice effectue la validation et si cette validation est ok, on l’update en base. Elle renvoie une structure XML avec les informations des actions réalisées et les messages d’erreur si nécessaire.

L’ID de l’enregistrement à mettre à jour est généré au début de l’appel de la page ‘formulaire’ et, afin de garder une persistence du formulaire non terminé, cet ID est stocké dans un cookie chez le client. Le cookie est effacé une fois le formulaire validé ou annulé (ainsi le client peut commencer à saisir un formulaire, fermer son navigateur, aller boire un café, partir en vacances.. et revenir le terminer quelques jours plus tard sans avoir perdu une seule information ; la seule contrainte de persistence est la durée de vie du cookie.

La page de backoffice effectue un traitement particulier lorsqu’elle reçoit l’ordre de validation complète du formulaire : elle repasse une validation de chaque champ, et vérifie également si tous les champs obligatoire sont présents. Si c’est ok, elle update en base, sinon renvoie une erreur.

Afin que le code html / php soit le plus propre possible, j’ai utilisé la fonction Event.observe de prototype afin de déclencher les observateurs d’évennements de mise à jour des champs du formulaire, ne vous étonnez donc pas de ne pas trouver de ‘onclick’, ‘onblur’, etc.. un peu partout dans le code, c’est normal, tout est géré dans le javascript init() dans formulaire.php. Ce script n’a pas besoin d’être paramétré lorsqu’on ajoute ou supprime des champs du formulaire : il scanne automatiquement tous les champs du formulaire et détermine les actions. Par défaut, les actions sont réalisées en keyup, c’est à dire que à chaque fois qu’on tape un caractère, on réalise l’appel AJAX. C’est peut-être un peu dangereux pour les performances de gros sites, vous pouvez alors par exemple remplacer les keyup par des blur.
Selon les types de champs du formulaire, on appelle une fonction spécifique située dans formulaire_backoffice.js qui a pour objet de récupérer le nom du champ et sa valeur afin de déclencher l’appel AJAX.
La fonction de call-back ajax interprête le XML de résultat et affiche l’erreur si nécessaire.

L’enregistrement en base est créé par le php la première fois qu’on appelle formulaire.php, ensuite, le cookie enregistré sur le poste client permet de garder le contexte.
A chaque modification d’un champ, l’appel AJAX lance une mise à jour du champ qui est en train d’être modifié. Avant la mise à jour, le php appelé par l’appel XMLHttpRequest fait d’abord une validation. Les validations sont gérées à l’aide d’expressions régulières, c’est donc assez facile d’ajouter d’autres types de validations plus évoluées (la fonction est dans inc_validation.php). Si la validation est ok, alors on update ce champ en base.

Une conséquence importante de ce mode de fonctionnement est ce que j’appelle la fonctionnalité ‘big brother’ : le formulaire enregistre tout : il suffit de venir au moins une fois sur le formulaire, commencer à le remplir. Même en ne le terminant jamais, il restera toujour un enregistrement en base reflétant ce formulaire à moitié rempli (toutefois, seuls les valeurs des champs qui passent la validation sont enregistrés en base).

L’appui sur ‘valider le formulaire’ fait également un simple update en base sur ce même enregistrement et passe le champ ‘formulairevalide’ à 1. Ainsi, on peut distinguer les formulaires terminés et validés (ils ont le champ ‘formulairevalide’ à 1) et ceux jamais terminé (le champ est alors à zéro).

L’appui sur ‘annuler’ efface simplement le cookie : l’utilisateur aura donc l’impression de repartir sur un formulaire vide, mais ce qui a été saisi dans le formulaire précédent est resté en base…

Pour les sites à fort taux de fréquentation, cette fonctionnalité peut éventuellement générer beaucoup d’enregistrements, il faudra peut-être prévoir une tache de ‘purge’ des formulaires non validés dont la date de dernière modification est trop ancienne par exemple.

Téléchargez l’archive située en bas de cette page, dézippez cette archive dans un répertoire quelconque de votre site web (ex: http://www.monsite.com/formulaire/)

Pour l’instant, vous allez juste créer la base et l’utilisateur qui a le droit d’y accéder.
Si votre hébergeur ne vous laisse le droit qu’à une seule base, vous pouvez passer cette section, nous créeront la table plus tard.
Sinon, créez une nouvelle base du nom de votre choix (dans notre exemple : ‘formulaire’).
Créez ensuite un utilisateur mysql avec, au minimum, les droits d’accès SELECT, INSERT, UPDATE sur la base (vous pouvez choisir si vous le souhaitez, plus tard, une fois la table créée, de limiter ces grants à uniquement la table du formulaire)

Il y a deux fichiers de configuration : un pour le côté client et un pour le côté serveur.
Commençont par le côté client :
Editez le fichier ‘parameters.js‘ :

• gs_Base_url: indiquez l’utl d’accès de votre formulaire (dans notre exemple : http://www.monsite.com/formulaire/) [attention de ne pas oublier le slash (/) à la fin]
• gs_Redirect_url: indiquez l’url qui sera appelée à la fin de la validation de votre formulaire (dans notre exemple, on retourne à la home page : http://www.monsite.com/
• gs_Cookie_name: indiquez le nom du cookie qui sera stocké sur le poste client (dans notre exemple : formulaire)
• gl_Cookie_time: on indique la durée de vie de ce cookie. Par défaut elle est de 30Jours après la date de création.

Editez ensuite le fichier ‘inc_parameters.php‘ :

• dans $DBnombase, indiquez le nom de la base que l’on a créé tout à l’heure (ou le nom de la base donnée par votre hébergeur)
• dans $DBnomtable, indiquez le nom de la table que l’on créera ensuite (dans notre exemple : t_formulaire)
• dans les paramètres de mysql_connect, indiquez où se situe votre serveur (ici : localhost) et le login et password de connexion à la base (ici : login et password)
• dans $gs_Cookie_name et $gl_Cookie_time indiquez exactement les même valeurs que ce que vous avez paramétré dans parameters.js

Il est temps maintenant de définir le contenu des champs du formulaire, pour cela, Editez le fichier ‘formulaire.php‘ :

• Choisissez un titre à l’intérieur des tags <title></title> (dans le Head)
• Dans le <body>
  • Laissez tel que le <div id= »infobox »>
  • Entez un titre dans les tags <div></div>
  • Mettez le texte que vous voulez devant le formulaire (en utilisant les classes de style ‘explication’ et ‘question’)

Les éléments du formulaire sont organisés par groupe, un groupe est un ensemble de champs du formulaire à l’intérieur d’un <fieldset>
Les fieldset sont des éléments de présentation, vous pouvez choisir de mettre tout le formulaire dans un seul fieldset ou à l’opposé de faire un fieldset par champ à remplir, c’est votre choix.
Dans le formulaire par défaut, je montre quelques exemples différents.

Chaque fieldset doit avoir une légende qui est représentée par les tags <legend></legend>

la classe « noerreur » : chaque élément de formulaire (input, checkbox, radio, etc..) doit être encadré par un div de classe « noerreur ». Cette classe sera changée dynamiquement en classe « erreur » en cas de pb de validation de cet élément de formulaire.

Ce principe est un des points les plus structurant de ce formulaire, revenons donc sur un des élements de mon cahier des charges : « impossibilité pour le client de passer outre les validations en modifiant les javascript ».

D’habitude, dans la plupart des formulaires classiques, on réalise une validation en javascript du côté du client (par exemple la vérification : est-ce qu’un email est bien un email). Bien sûr cette validation n’est pas suffisante, car il suffit d’interdire les javascripts pour passer outre la validation. Donc les formulaires un peu plus évolués (tous devraient le faire) doublent cette validation javascript par une validation côté serveur. Mais encore une fois, il faut bien passer les paramètres de validation au serveur. Pour un formulaire non AJAX, cela se fait par exemple dans les infos de POST. J’aurais pu également faire la même chose et simplement éviter le POST et  le rechargement de page en utilisant XMLHttpRequest. Mais rien n’empèche non plus une personne mal intentionnée de recopier le formulaire sur un poste local, d’en changer les paramètres et d’appeler le script serveur avec d’autres types de validation (changer une validation email en simple validation txt par exemple).

J’ai donc choisi de passer les paramètres de validation directement dans le nom des champs du formulaires. Et ce sont ces même noms qui structurent la table d’enregistrement de la base de donnée. Ainsi si une personne mal intentionnée cherche à changer une validation, elle doit changer le nom du champ et même si la validation passe, l’enregistrement en base de donnée ne passera pas.

Cette solution est plus sécurisante, mais elle a l’inconvénient de générer des noms de champs un peu compliqués et peut-être un peu compliqué à faire évoluer (dans le cas de nouveau types de validation par exemple qui nécessiteraient de nouveaux paramètres).

Les noms des champs ont donc une structure qu’il faut respecter, en voici les règles :

La Structure du champ est la suivante : ttt_x_y_z_mmm

1. ttt : représente le type du champ, il peut prendre les valeurs suivantes :
   • num : numérique entier
   • real : numérique à virgules
   • tel : téléphone (français)
   • date : date de type JJ/MM/AAAA
   • cp : code postal
   • email : email
   • txt : texte libre
2. x : prends deux valeurs possibles :
   • m : mandatory (champ obligatoire)
   • o : optionnal (champ optionnel)
3. y : nombre de caractères minimum : valable uniquement pour les type de champs txt et email, mettre 0 dans les autres cas
4. z : nombre de caractères maximum : valable uniquement pour les type de champs txt et email, mettre 0 dans les autres cas
5. mmm : nom du champ

exemples :

• txt_m_1_100_nom : nom est un champ texte obligatoire qui doit comporter entre 1 et 100 caractères
• email_m_4_50_couriel : couriel est un champ de type email obligatoire qui doit comporter entre 4 et 50 caractères
• num_o_0_0_quantite : quantite est un champ numérique entier optionnel
• etc…

Voici les associations que vous pouvez utiliser sans risque entre les types de champs du formulaire et les champs en html :

• input type = « text » : num | real | tel | date | cp | email | txt
• textarea : num | real | tel | date | cp | email | txt
• input type = « checkbox » :  num
• input type = « radio » : num
• select : num | txt (dans l’absolu, même si c’est moins logique : num | real | tel | date | cp | email | txt)

Dans l’archive, vous trouverez un exemple de chaque cas d’input afin de vous permettre de copier/coller ce qui vous interesse.
Attention : il y a une petite subtilité avec les input radio : le champ ‘name’ doit avoir la même valeur pour tout les inputs radio du même groupe (ainsi donc que l’appel de la fonction php ‘RecupereValeur’ qui doit avoir ce même champ name comme paramètre). Par contre, les champs ‘id’ doivent être uniques (même un numéro incrémental en plus du name par exemple), ceci afin de faire correspondre l’id de l’input et le label associé.

La table a quelques colonnes obligatoires :

• idformulaire : la clef principale de la table : un id incrémental
• idsession : la valeur du cookie qui sert à garder la persistence du formulaire
• datecreation : la date de la première insertion de l’enregistrement
• datemodification : la date de dernière modification de l’enregistrement
• adresseIP : l’adresseIP du poste client qui a inscrit le formulaire
• formulairevalide : est-ce que le formulaire est validé par l’utilisateur (la valeur est a zéro tant que le formulaire n’est pas terminé)

Les autres colonnes représentent exactement les noms des champs input de votre formulaire
(ex : `txt_m_1_100_nom` varchar(100) NOT NULL default  » qui correspond à l’imput ‘nom’ de votre formulaire). Notez bien que le nom du champ doit être exactement le même que le paramètre ‘name’ de l’inputField.

Regardez le fichier table.sql dans l’archive d’exemple pour plus de détails.

Toute la forme est gérée dans la feuille de style (style.css)
L’objet de cet article n’est pas de faire un détail sur les feuilles de style : l’utilisation des styles pour ce formulaire est très simple. N’hésitez pas à aller faire un tour sur Alsacréations par exemple, un excellent site français qui vous apprendra un tas de choses très pratiques sur les css et sur bien d’autres choses.

J’espère que ce petit formulaire et ce tutoriel pourront vous aider dans vos projets. En tout cas, sentez vous libre de l’exploiter, le modifier, l’améliorer, le triturer. Si toutefois vous avez réalisé des améliorations, rencontré des bugs, souhaitez des améliorations, n’hésitez pas à m’en faire part en utilisant les commentaires ci-dessous.
Ce formulaire est encore très incomplet et il reste pas mal de choses à faire si on voulait le rentre véritablement professionnel. Voici une petite todoList qui résume les points à améliorer :

• être tolérant aux browser qui n’ont pas XMLHttpRequest (revenir en mode post classique par exemple)
• faire un système de validation multichamps (par exemple n checkbox doivent être coché parmi n)
• faire évoluer les messages d’erreur :
  • afficher l’erreur de validation directement à côté du champ (paramètre optionnel par exemple)
  • afficher le faire que le champ est obligatoire ou non
• faire un système d’auto config (wizard ?) / d’install plus simplifié

J’ai mis en ligne le formulaire de démo situé dans l’archive, vous pourrez le retrouver en suivant ce lien.

  formulaireAjax_1.0.zip (128,0 KiB)