Code, trucs et astuces

MODE D'EMPLOI DE CETTE PAGE

En laissant le pointeur de votre souris sur un mot souligné par des pointillés, vous pourrez lire sa définition.

Créer un formulaire

Sommaire

Préalable
Les données
Mise en page
Récupération des données
Webographie

Introduction

Un formulaire permet d'offrir à l'usager un moyen confortable de répondre à une série de questions pénibles, tout en réservant un maximum d'emmerdements à son concepteur. Willibald Prosper Leform-Ulaire (secrétaire de mairie 1905-1999)

Derrière la simplicité apparente d'un formulaire se cache en effet une masse de travail, avec son lot de difficultés et quelques joyeusetés techniques qui n'ont rien de drôles. Sans prétendre résoudre quoi que ce soit à vos problèmes, voici mes réponses à quelques-uns des écueils liés au développement d'un formulaire. Je ne suis ni informaticien, ni développeur. Au mieux réalisateur de sites, si cela veut dire quelque chose, avec quelques connaissances très sommaires en HTML, PHP, CSS ou encore Javascript. De quoi faire des sites avec mon éditeur de texte et subvenir péniblement à mes besoins quotidiens (un quignon de pain et une bouteille d'eau...).

J'ai fait ce tutorial en remerciement aux aides que j'ai moi-même reçu de ci, de là. Motivé aussi par le fait que j'ai moi-même longtemps cherché, parfois trouvé et maintes fois constaté que le fruit de mes efforts était proche du zéro. Les réponses trouvées étaient mal expliquées, inexploitables, voire complètement erronées. Quant à chercher des forums sur tel ou tel sujet, c'est long, chiant et totalement improductif, à lire les engueulades des uns et les réponses qui aident vachement à faire avancer le schmilblic du genre "J'ai pas Bac +5", "utilise surtout pas GET" ou le très geek "RTFM" des autres. Ceci est donc mon petit caillou blanc déposé sur le rude sentier de votre recherche. Ah j'oubliai: les trucs indiqués ici fonctionnent ! Du moins au jour où j'écrivais ces lignes !

Préalable

La première des choses à faire est de réfléchir à l'opportunité d'un formulaire. Avez-vous réellement besoin de cet outil pour collecter des données ? Ne pouvez-vous pas utiliser une solution plus simple ? Pas besoin de bricoler un formulaire d'adhésion au club de scrabble, si c'est juste pour obtenir l'adresse d'un nouveau membre. Un mail normal est bien plus rapide pour tout le monde !

Pas besoin, non plus, de jouer au pro du pot en offrant un QCM à vos visiteurs :

ce site est génial 
intéressant 
archi nul 
etc,etc...

dont le résultat vous reviendra par mail en texte brut. Pour traiter 3 questions, passe encore, mais j'en connais des extras longs avec des dizaines de questions !

Autant vous le dire de suite, ne vous servez pas d'un formulaire si vous avez moins de 10 questions à poser ou que vous n'avez pas l'intention d'utiliser une base de données si vous avez un volume plus important à traiter.

Si, comme moi, vous estimez que travailler pour rien est trop dur, choisissez entre l'accessoire et l'indispensable. Vous verrez qu'en triant consciencieusement ces 2 notions dès le départ, vos heures de sieste se rallongeront et vous gagnerez en productivité.

Malgré ces mises en garde, vous devez quand même faire ce fichu formulaire ? Alors bienvenue au club et voilà ce que vous pourriez faire:

La première des choses à mettre dans un document HTML destiné à contenir un formulaire est la DTD, ou doctype, que l'on met avant la balise <html>. Si vous ne l'indiquez pas, vous irez en enfer et vous serez désigné comme un vilain réfractaire aux standards et autres diktats de la conformation W3cienne... Plus couramment, son absence n'est pas si dramatique que ça sur un site perso, mais s'avère à contrario indispensable sur un site commercial, institutionnel, voire de service public, censé favoriser l'accessibilité à un maximum de visiteurs et donc, de navigateurs à la DOM plus ou moins standard...

CODE

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr">

La DTD est un bon moyen pour dire à un navigateur (l'agent utilisateur selon la terminologie du W3C) ce qu'il doit faire ou plutôt, comment(exemple avec XHTML) il doit le faire. On pensera aussi à préciser le jeu de caractères utilisé, au moyen d'une balise META, comme ceci:

Le paramètre charset identifie un encodage de caractères, qui représente une méthode pour convertir une séquence d'octets en une séquence de caractères. Le boulier électronique (votre PC) qui se prend pour un traitement de texte et une machine à écrire, ne s'en portera que mieux ! Dans l'exemple ci-dessus, il travaillera selon les spécifications propres au XHTML 1.0 Transitional, avec comme impératif supplémentaire indiqué dans la balise <meta>, de respecter les polices latines z'et accentuées du français, entre autres...
Ce qui est probablement une indication superflue pour vous, mais pas du tout pour le navigateur. Les choses étant ce qu'elles sont, il est fort possible que si vous ne lui donnez pas cette indication, il utilise un paramétrage de langue par défaut qui pourrait bien être l'anglais. Et votre magnifique formulaire en français avé les assang et les cedilles et les interlignes risque de ne pas s'afficher correctement, ce qui serait balot. Alors tant qu'à faire, autant traiter la situation correctement dès le départ.

Les données

Les données d'un formulaire sont constituées de texte, de chiffres et de conditions de type oui/non.
Pour qu'un formulaire soit efficace, tant du point de vue de l'exploitant que de l'usager, il est important de le structurer. La clarté du cheminement, de même que le regroupement des données en fonction de leur nature, est donc primordiale.
Jusque là, c'est de l'enfonçage de portes ouvertes. Malheureusement, en dépit de ces plates évidences, il n'y a pas de solution simple pour la réalisation d'un formulaire. C'est là que ça se gâte, et que c'est sans doute pour cela que vous êtes en train de lire ceci !

Boileau aurait dit : "Ce que l'on conçoit bien s'énonce clairement". Restons simple et disons que ce qui se prévoit bien avant, se travaille facilement après !

Et pour cela, il existe quelques solutions. Les litres de sueurs de ceux qui ont eu à faire à des formulaires avant vous n'ont pas été vains. D'ailleurs, une première solution vous a déjà été donnée: structurez votre tâche. Mettre un peu d'ordre dans tout ce foutoir est un bon moyen de démarrer le travail !

Dans un formulaire classique, vous trouvez généralement tout ce qui concerne l'identification de la personne qui va le remplir. Ce qui nous fait un premier paquet, bien ficelé et cohérent. A vous de voir pour le reste sur le même principe... Triez comme vous l'entendez, mais évitez de mélanger les torchons et les serviettes ! On pourrait ainsi regrouper les articles d'un panier virtuel en fonction de leur rayon: épicerie, droguerie, etc,... ou poser les questions professionnelles avant les questions à propos de la santé du chat.
Mais quel que soit l'ordre de vos priorités, vous aurez toujours à déclarer un ou plusieurs des évènements suivants, en fonction des réponses que vous attendez:

un champ de saisie
une case à cocher
une liste de sélection
un bouton radio

Rien de plus, mais pas moins non plus ! Tout en sachant qu'il existe des champs de saisie à une seule ligne ou à plusieurs lignes, (typiquement, la petite boîte pour mettre un nom et la grande boîte pour laisser un message), que les cases à cocher et les listes permettent des choix multiples et que les boutons radio (le cercle avec un point noir à l'intérieur...) n'offrent pas d'autre possibilité que de dire oui ou non ou blanc ou noir.

Pour connaître la totalité des détails sur toutes les subtilités des formulaires, reportez-vous aux spécifications du W3C en HTML 4.01 et XHTML 1.0

Gardez juste à l'esprit qu'avant de vous lancer, vous dev(ri)ez impérativement réfléchir au contenu de votre formulaire et à la manière dont vous voulez traiter les informations recueillies. C'est le traitement de celles-ci qui détermine l'usage de l'une de ces 4 possibilités. Veillez à la formulation de vos questions et laissez le minimum de possibilités d'interprétation à vos visiteurs. L'idéal étant qu'ils ne puissent répondre que par oui ou non ou à des choses qu'ils connaissent déjà. Dites-vous bien que dans 99% des cas, vous n'obtiendrez une réponse claire que si posez une question claire. Pour faire un bon formulaire, mieux vaut poser une question fermée ou courte que d'émettre une interrogation du genre "Que pensez-vous de l'usage du php dans le traitement des formulaires ?" qui appelle une réponse argumentée. Faites simple !

Maintenant que vos "cases" sont remplies par les millions d'utilisateurs de votre formulaire en ligne, il va falloir les exploiter. Généralement, si déjà vous posez des questions et que vous obtenez des réponses, vous voulez aussi les connaître. Dans ce cas, c'est bien de pouvoir les afficher. 2 possibilités 1/2 vous sont offertes:
un affichage immédiat, un affichage différé et les 2 mon colonel.

Un affichage immédiat: pratique par exemple, pour relire le contenu du formulaire avant de l'envoyer.
L'affichage différé: on expédie les données par mail et on les récupère au moment de la consultation du courrier..
Les 2: on vérifie d'abord les données puis on les expédie vers une base du même nom, qu'on consulte ultérieurement.

Mais dans les 3 cas, il faut envoyer les données.

Pour cela, HTeuMeuLeu a prévu le bouton d'envoi - le fameux rectangle gris - marqué, selon l'humeur et les pays, "send", "envoi", "jipoush", "~T![°}+". Comme les autres précédemment décrits, cet évènement est déclaré dans la balise <INPUT> suivit du type de commande: bouton (button) ou soumettre (submit).

Button or submit ? That is un choix cruel...

Pas tant que ça en fait. Le type ="button" détermine une action. Typiquement le déclenchement d'un script. Au hasard, un script pour vérifier le contenu d'un formulaire avant son envoi. Plus ludiquement, on peut aussi s'en servir pour la création d'un bouton aussi rigolo que celui-ci:

Démo

Le type="submit" est une valeur prédéfinie qui ne sert par définition qu'à une chose: "envoyer", à condition que la méthode d'envoi ait été définie au préalable. Mais en fait, les 2 termes ne sont que des conventions de nommage. Libre à vous de les respecter ou non.

CODE

<form method="post" action="">
  <p>
    <input type="text" id="toto" />
  </p>
  <p>
    <input type="checkbox" id="checkbox" value="checkbox" />
  </p>
  <p> 
    <input type="radio" id="radiobutton" value="radiobutton" />
  </p>
  <p> 
    <input type="submit" id="monbouton0" value="Envoyer" />
    <input type="reset" id="monbouton1" value="Rétablir" />
  </p>
</form>

Ce qui donne à l'affichage:

Démo

Comme vous pouvez le constater, tout ce code mélange joyeusement l'anglais et le français. Ce n'est pas la merde, mais ça commence à y ressembler. Va falloir faire attention ! En effet, <input type= "quelque chose"> correspond à l'énoncé <attribut=valeur>; l'attribut est une instruction connue, donc invariable, tandis que la valeur est une donnée inconnue, forcément variable. Le code HTML est écrit en anglais, l'attribut s'écrit donc en anglais et sa valeur, puisqu'elle est non fixée, dans la langue qu'on veut.

Les autres attributs comme label="quelque_chose" et value="quelque_chose" fonctionnent sur le même schéma. En anglais pour la partie attribut à gauche du signe = et en français, dans la partie valeur à droite du signe. Cela semble idiot à relever de prime abord, mais figurez-vous qu'on peut vite s'y perdre. En rajoutant par exemple, une classe CSS pour la mise en page, un évènement Javascript, un identifiant ID="quelque_chose" si vous codez en XHTML strict, et ainsi de suite... Mieux vaut donc savoir en quelle langue vous travaillez et surtout, à quel endroit vous devez/pouvez l'utiliser.

Dans votre grande sagacité emplie de clairvoyance, vous avez noté, non sans étonnement je présume, que j'écrivais quelque_chose avec un tiret bas. C_fé_tex_pré !!! Pour vous faire comprendre que les espaces sont interdits ET les caractères spéciaux (é è à @;,.etc) fortement déconseillés à cet endroit. C'est ainsi, je n'y suis pour rien et vous non plus. Si vous tenez à écrire pour le confort de vos yeux, jambon beurre (c'est un exemple) à cet endroit, séparez toujours les mots avec un tiret bas. C'est évidemment valable aussi pour les autres valeurs. Voici comment vous dev(ri)ez faire:

name="jambon_beurre" value="toto_a_faim" ID="titi_aussi".

Ce qui met tout le monde d'accord: notre oeil voit une ligne d'horizon surmontée d'un espace, tandis que la machine est contente aussi, avec sa petite instruction "met donc un espace ici", ce qu'elle fait pour notre regard (si, si) sans en mettre un pour elle. La nature a horreur du vide. Les navigateurs et les ordinateurs aussi. Si vous ne captez rien à ce que je vous explique là, allez rafraîchir vos connaissances par ici et revenez après la cure !

NB: l'aspect des boutons d'envoi et de remise à zéro est géré directement par les navigateurs. Ne cherchez donc pas à les modifier, ça ne marche pas. La seule possibilité de changer ce look soviétique mod.54 réformé 62 est d'utiliser une image. Avec, évidemment, la petite série d'inconvénients propre à ce choix: créer une image, surveiller sa taille et son poids, vérifier son emplacement, URL brisée ou incorrecte, mettre un texte alternatif à l'attention des gens qui n'affichent jamais d'images dans leur navigateur, etc...

Mise en page

Je vous préviens tout de suite: il n'y a pas d'exemples tout prêt ici. En effet, la mise en page d'un formulaire est très facile et le web regorge d'exemples. Vous pouvez vous contenter du HTML de base ou améliorer visuellement les choses avec une feuille de style. Si vous ignorez tout des feuilles de style, faites d'abord un tour chez Mammouth (land). Vous y trouverez notamment un générateur de feuille de style. C'est simple et facile à utiliser et au moins vous saurez à quoi ça ressemble. Au passage, vous y apprendrez plein de choses utiles. Après quoi, vous revenez ici, vous vous asseyez là-bas au fond et vous vous tenez tranquille !

Non mais...

Pour construire un formulaire, on démarre avec la balise FORM, on ajoute les INPUT, on les catégorise avec des FIELDSET qu'on nomme avec LEGEND, et on termine par un bouton ou deux. Pas de quoi fouetter un chat, n'est-ce pas ? Mais...

On observant le bout de code plus haut, vous aurez remarqué qu'il contenait des balises de paragraphes <p> entourant chacune des boîtes. C'est un début de mise en forme. Avec CSS, vous pouvez aller plus loin encore et tout paramétrer à votre goût. Le fond du formulaire, sa bordure, la hauteur des lignes, etc. Il suffit pour cela d'attribuer des class aux éléments qui le composent.

Avant de sortir le grand jeu de CSS, exploitez déjà le potentiel du HTML. Quelques balises peu connues vous permettent de séparer visuellement vos paquets de données: la balise <FIELDSET> accompagnée de la balise <LEGEND>. En français, fieldset signifie jeu de champs (de saisie). Cette balise ne sert qu'à cela: regrouper des champs de même nature. Par ex.: état-civil, habillement, alimentation, électro-ménager etc... Visuellement, cela affiche le cadre rouge autour des blocs de texte que vous voyez sur cette page.

Attention: faites ce que je dis, mais pas ce que je fais ! C'est là un usage détourné, donc pas autorisé par les standards. Mais je suis un vrai rebelle quand je veux. Et là, je voulais. La balise legend permet de mettre une étiquette, un titre si vous préférez, sur le cadre.

Notez que ces 2 balises fonctionnent plus ou moins en couple et ne se laissent pas trop faire par CSS. Chez les navigateurs, ce n'est pas top non plus : Firefox applique d'autorité une marge interne (padding), Explorer a du mal à afficher une couleur de fond qui resterait gentiment à l'intérieur du fieldset ...

Enfin, vous pouvez encore structurer les listes déroulantes avec la balise <optgroup> autour des <options>. Dans la démo qui suit, le style est prédéfini sur gras italique. Seules les colorations du fond et du texte sont données par la CSS:

Démo

Equipier:

Le résultat est tout de même plus sympa et lisible qu'une longue liste de noms, avouez !
Mais comprenez aussi que ce ne sont là que des effets visuels, purement cosmétiques et plus ou moins utiles à l'utilisateur, mais qui n'apportent strictement rien au formulaire lui-même. L'essentiel est ailleurs et peut chaut à votre formulaire qu'il soit vert ou jaune, l'important est qu'il possède tout ce qu'il faut, là ou il faut, pour vous transmettre correctement ce qu'il contient.

CODE

 <select name="select">
  <optgroup label="Equipe junior">
   <option value="toto">toto</option>
   <option value="tata">tata</option>
   <option value="titi">titi</option>
  </optgroup>
  <optgroup label="Equipe senior">
   <option value="toto">gaga</option>
   <option value="tata">gogo</option>
  </optgroup>
</select>

La seule chose que vous dev(ri)ez surveiller, est la confusion possible entre vos expressions et celles appartenant au HTML, à Javascript, à PHP, etc.
La pire de toute étant sans doute l'attribut unique ID="quelque_chose", qui sert à identifier l'élément dans le flux, de l'identifiant de classe ID propre à CSS, qui s'écrit tout pareil alors qu'il n'a pas du tout la même fonction. Méfiez-vous de cela, car pour déboguer derrière, ce n'est pas toujours évident. Un conseil: écrivez si possible votre feuille de style avec des class plutôt qu'avec des id (pas de #toto, mais plutôt des .toto) et vous vous économiserez quelques confusions.

Méfiez-vous aussi des espaces et des sauts de lignes quand vous codez. Quelle que soit la méthode que vous employerez pour envoyer votre formulaire, elles sont quasiment toutes sensibles à la casse et aux espaces. Enfin, fermez bien toutes les balises. Comme nous ne sommes plus en 1999 (sortie de HTML 4.0), surveillez particulièrement la balise INPUT. La syntaxe a évoluée depuis l'arrivée des navigateurs 5.0. Cette balise est rarement à jour dans les exemples que vous trouvez sur le Net. Et pas mieux pour les anciennes versions de, au hasard, Dreamweaver. Avant 2000, il : n'y avait pas de balise fermante </input>. Il n'y en a toujours pas en 2005, mais il faut tout de même penser, XHTML oblige, à ajouter un espace suivit d'un slash avant le chevron final.

CODE

<input type="radio" id="radiobutton" value="radiobutton"[]/>
 Les 2 crochets [] symbolisent l'espace qu'il faut laisser avant l'instruction de fermeture représentée par />

La récupération des données

Nous y voilà enfin ! Le point crucial de notre formulaire: le traitement des données. Après le contenu, la mise en forme, voici l'attribut METHOD de la balise FORM qui spécifie le mode de transfert des données vers le serveur. HTML a prévu 2 méthodes 1/2d'envoi, GET et POST et MAILTO. La dernière est archi nulle, je n'en parle même pas, puisque largement commentée ailleurs.

GET affiche les valeurs qui lui sont confiées dans l'URL. Elle possède de surcroît une limitation sur le nombre maximum de caractères dans l'URL fixé à 256, 512 ou 1024 octets, selon la config du serveur. Pas très performant, ni pour envoyer un gros formulaire, ni pour la sécurité...

Principe de fonctionnement de la méthode GET:

Le navigateur envoie l'instruction GET (en français: obtenir) avec les données en les ajoutant dans l'URL qu'il adresse au serveur.

L'adresse du CGI concerné (ex: http://www.monsupersite.com/envoi.php)
Un point d'interrogation ? pour séparer l'adresse demandée des données transmises.
Les données elles-mêmes sur le principe de: champ1=valeur1&champ2=valeur2, etc.

En conséquence, le CGI lira, puis exécutera tout ce qui se trouve après le ? selon cet exemple:

CODE

http://www.monsupersite.com/envoi.php?nom=tata&prenom=yoyo&message=le code de la porte d'entrée est B52

Principe de fonctionnement de la méthode POST:

La méthode POST a la même utilité que GET, mais ses paramètres sont passés directement au serveur via l'en-tête http, au lieu d'être envoyées via l'URL. Les valeurs ainsi transmises restent invisibles à l'usager lambda. De plus, la longueur des données n'est théoriquement pas limitée en taille, sauf si l'administrateur du serveur en a décidé autrement.

Le navigateur envoie POST l'instruction avec les données incluses dans la requête HTTP qu'il adresse au serveur.

Envoi de l'en-tête HTTP au serveur
Les chaînes de données sont séparées en paires name=value par le script du CGI
Chaque paire est ensuite traitée par ligne.

CODE

Un formulaire de ce type:
     <form method="post" action="envoi.php">
     <input type="text" name="nom" value="Tata">
     <input type="text" name="prenom" value="Yoyo">
     <input type="submit" name="bouton" value="ENVOI">
     </form>
sera envoyé sous cette forme après le déclenchement de l'évènement submit

	)	post /envoi.php HTTP/1.1
en-tête )	host: www.monsupersite.com
	)	content-type: application/x-www-form-urlencoded
	)	content-length: xxx où x est le nombre de caractères à afficher 
		      (x est traité automatiquement par le navigateur)

données	)       nom=tata
données	)	prenom=yoyo

Les navigateurs travaillent indifféremment avec GET et POST. Le choix entre les 2 méthodes se fait d'abord par rapport au volume à traiter et ensuite par rapport à la sécurité . Il dépend aussi très largement de la technologie disponible sur le serveur. Plus confusément, mais très à la mode sur le principe du moins j'en fais mieux je me porte en copiant mon voisin, vous lirez majoritairement qu'il faut utiliser POST pour des raisons de sécurité. Ouais, bon, moi je dis qu'il n'y a que mourir qu'il faut. Pour le reste,c'est si je veux bien ! Et côté sécu, il existe des administrateurs de serveurs sérieux et les autres. Demander aux usagers de n'utiliser que POST relève plus de la flemme ou de l'incompétence...

Sans aller plus loin dans les détails, disons que pour un usage courant depuis un serveur mutualisé type Free ou OVH, vous pouvez tranquillement utiliser GET ou même MAILTO, pour des petits volumes non confidentiels. Evidemment, la méthode POST avec PHP est raisonnablement sûre chez ces prestataires et s'avère simplement pratique si vous avez des gros volumes à traiter.

Et cessez de rêver: ce n'est pas parce que VOUS avez votre site sur le web que VOUS allez devenir la cible des méchants pirates. Ceux-là on tout de même d'autres préoccupations que de hacker VOTRE serveur via un formulaire, fut-ce celui de VOTRE club de scrabble ! Sauf à être hébergé sur un serveur gouvernemental ou bancaire, ce qui est peu probable, vous ne devriez pas figurer au TOP 50 des victimes potentielles immédiates ou alors quelqu'un que VOUS connaissez VOUS veut vraiment du mal, à VOUS !

Maintenant, si votre objectif est un traitement de formulaire sécurisé parfaitement maîtrisé, allez-y franco et adoptez des techniques plus conséquentes, permettant en particulier des contrôles très poussés côté serveur. Travaillez uniquement en connexion sécurisée HTTPS et utilisez des scripts en Python ou en Perl par exemple. Avec un peu de chance, votre bidule sera bien ficelé et vous deviendrez peut-être un morceau de choix pour un pirate en mal d'exploit. Choisir entre GET et POST est aussi une question de moyens et de compétences. Etre pirate aussi...

A présent que vous avez fait votre choix en connaissance de cause, passons à la suite du traitement.
Le CGI va traiter le couple name=value selon la méthode indiquée dans la balise FORM. En conséquence, codez avec soin en indiquant correctement name="qq_chose" ou id="qq_chose", en pensant que l'attribut name est autorisé en XHTML transitional, mais interdit en XHTML strict.

La vérification des champs

Avant d'expédier nos précieuses données à travers la Toile, il serait judicieux de vérifier si les champs ont bien été remplis. Pour éviter quelques abus, on regarde si les champs numériques ne contiennent que des chiffres ou que le champ courrier contient bien une adresse e-mail. Il faut pour cela appliquer une contrainte. Mettre en place un dispositif qui oblige le visiteur à remplir le champ. A part avec un 357 Magnum, je ne vois pas trop comment imposer une telle obligation.

Pour rendre un champ obligatoire, il suffit de le décréter. Vous indiquez gentiment à vos visiteurs quels champs sont obligatoires. Mais en faisant cela vous n'avez encore rien fait ! A ce stade, on pourrait tout aussi bien vous renvoyer un formulaire vide ou rempli n'importe comment. Eh oui, parce que le HTML n'est pas un outil de coercition, même lorsqu'il s'agit de traiter un formulaire.
La méthode qui va être utilisée peut sembler brutale: si l'un des champs n'est pas rempli, on n'envoie pas le formulaire. Oui mais comment faire, puisque rien n'est obligatoire et qu'on n'a pas de flingue sous la main ?
Pour parvenir à nos fins, nous allons faire appel à une force extérieure: le Javascript.

De manière générale, JavaScript sert à contrôler des données et à interagir avec un document HTML via l'interface DOM du navigateur. Le code Javascript est le plus souvent écrit directement dans la page où il agit comme un petit programme indépendant qui viendrait à la rescousse du pauvre petit navigateur, en mettant un peu d'ambiance dans tout ce texte si statique. Javascript permet notamment de générer des effets de rollover lors du passage de la souris sur une , d'afficher un message, de fermer le gaz ou d'éteindre son PC en partant...

CODE

 
Le code utilisé sur "message" :

<a href="noplace" onmouseover="alert('Etonnant, hein ?')">message</a>

Notez que le code (et non le message) est entièrement en minuscules pour respecter la syntaxe XHTML. Surveillez bien la casse, Javascript y est sensible, surtout quand vous copiez/collez depuis un site de pseudo spécialiste ès bidouille. Là où vous trouvez tant de scripts géniaux qui déchirent leur race et ne marchent jamais (et pour cause), fonctionnants à grands renforts de zigouigouis d'hydrocéphales qui confondent langage de programmation et script, Pascal et Javascript et qui utilisent génialement le C++ pour afficher Hello World sur leur page d'accueil, histoire d'en mettre plein la vue à leurs visiteurs:

CODE

 
          #include <iostream>
                      using namespace std;
                      int main()
                     {
                             cout << "Hello World\n";
                     }

au lieu d'un simple <p>Hello World</p> en html .

Or donc, parmi toutes ces choses dérisoires et mytérieuses, Javascript permet aussi de contrôler des champs de formulaire.
Si ! Et voilà comment cela se passe.

Nous allons procéder à quelques vérifications simples sur le contenu des champs. Un contrôle léger aux yeux d'un pirate motivé, mais suffisant dans 99% des cas, quand il s'agit d'empêcher Mr Dupont de mettre le bazar dans votre travail ou de forcer gentiment M. Durand a remplir convenablement votre formulaire. Prenons l'exemple d'un champ de saisie qui ne doit contenir que des chiffres comme un code postal.
On crée une fonction, comme ceci:

CODE

 

function champ_num(valeur) {

   if (isNaN(valeur)) alert("Veuillez ne saisir que des chiffres !");

exit();

}

On attribue un nom à la fonction (s'écrit avec un u en anglais): function toto.

Dans les parenthèses, on indique à quoi cela s'applique. Ensuite on fixe une condition avec if (si) et entre parenthèse (ce que la fonction doit faire si).
Javascript possède une tripotée de bouts de ficelles, dont voici l'une d'elles permettant de contrôler les nombres: isNaN.
is=c'est.
N=un chiffre au hasard (number en anglais, d'où le N).
a=à.
Et à nouveau un N.

Autrement dit isNaN signifie: un nombre au choix, entre zéro et infini. Si la condition n'est pas remplie, vous avez écrit bière au lieu de 1664, le script déclenche l'ouverture d'une boîte d'avertissement, avec un message rédigé dans la langue de votre choix, qui s'écrit ("entre parenthèses et entre doubles cotes")
La dernière ligne indique ce que fait le script si la condition est remplie. Vous avez bien indiqué un nombre: le script quitte silencieusement la scène en recevant l'ordre exit (sortir).

Démo

Veuillez saisir 1 chiffre:
Mettez ce que vous voulez et faites un click ou appuyez sur entrée pour valider la saisie.

Voilà en gros le principe. Cela dit, ce tuto n'est pas un cours de javascript ou de sécurité informatique. C'est juste une petite explication pour que vous compreniez un peu comment fonctionne ce que vous pompez sur le Net !

Les scripts Javascripts sont lus (on dit aussi interprétés) par votre navigateur. Sans entrer dans un long débat sur la portée d'interprétation de chaque navigateur du marché (IE, Moz, FF, Opéra, Safari, etc) ou des versions de Javascript, sachez juste que les scripts données ici peuvent ne pas fonctionner avec quelques versions anciennes. Paraît qu'il en reste... Dans la majorité des cas, ils devraient donc fonctionner.

Pour qu'ils fonctionnent, vous avez le choix: soit mettre vos scripts directement dans la page, soit dans un fichier externe. Si vous choisissez de les placer directement dans la page, il faut les écrire dans la partie head. N'oubliez pas d'annoncer la couleur au navigateur avec la balise <script> , ni bien sûr, de la fermer avec </script>. Remarquez aussi que la plupart des scripts sont en deux partie: une, dans le head, qui contient la ou les fonctions et l'autre dans le body, avec une instruction de déclenchement comme onMouseover,onClick, etc...

CODE

Pour un usage dans la page:
<script type="text/javascript">votre script ici</script>

Pour un usage à partir d'un fichier externe:
<script type="text/javascript" src="monfichier.js"></script>

Nota: même sans contenu, la balise doit obligatoirement être fermée.

Concernant un fichier externe, vous y mettez n'importe quel script, sans aucune balise. Vous entrez vos lignes de code avec un éditeur de texte, type bloc-note, et vous enregistrez le fichier avec l'extension .js. Généralement on utilise un tel fichier losqu'il y a beaucoup de fonctions dans une même page, histoire de les aléger un peu ou pour ne pas faciliter la tâche aux copieurs avides de vos scripts géniaux et forcément uniques, forcément.

Voilà donc pour ce début de commencement de vérification. Hélas, triple hélas, ça ne marche qu'avec des navigateurs qui ont javascript d'activé. Mais tout comme on a le choix de rouler sur une route avec un bolide ou une poubelle, on ne peut forcer personne à surfer avec des navigateurs paramétrés comme on le voudrait. Aussi, avant de dire ça march' pô, vérifiez d'abord que la fonction javascript du navigateur est bien activée !

A peine plus compliquée, voici une fonction permettant de vérifier qu'un champ texte a bien été complété. Ça peut servir lors de la collecte des coordonnées de vos visiteurs par exemple.

CODE


function valider() {
if (document.getElementById('toto').value.length < 1) alert("un message au choix");
exit();
}
pour afficher le champ, on peut utiliser:

<input type="text" name="toto1" id="toto1" title="Votre nom" maxlength="20" />

(maxlength fixe le nombre maximum de caractères qui peuvent être insérés dans le champ)

Le truc important ici, c'est ce bout de code: document.getElementById('nom'). Le getElementById cherche dans la page un champ de formulaire dont l'ID est toto. Cet IDentifiant doit être unique pour chaque champ que vous voulez contrôler.

Ce qui ne vous protège pas des faux noms, des pseudos ou de nimporte quelle autre fantaisie que certains mettent dans un champ de saisie... Dites-vous que vous gérez les oublis de gens bien intentionnés et pas la malveillance de vos contemporains; sauf à coupler votre script à la consultation d'un annuaire de noms type pages blanches, ce qui est tout à fait possible au demeurant, il y aura toujours un petit risque! Alors un conseil: ne vous prenez pas le chou avec ce genre de problème. Faites en sorte que votre public puisse correctement remplir votre formulaire et vous verrez bien à l'usage si vous devez augmenter votre surveillance.

Le traitement d'un formulaire s'effectue à l'aide de plusieurs fichiers distincts.

le fichier de la page contenant le formulaire (par ex: formulaire.php)
le fichier contenant la mise en forme des données qui vous seront envoyées par mail par le serveur (par ex: traitement.php)
le fichier javascript avec les instructions de contrôles des champs (par ex: formule.js)
le fichier CSS contenant la mise en forme d'affichage de votre formulaire (toto.css ou celui que vous utilisez déjà)

Voilà une page typique avec le minimum de code html et php utilisé dans le traitement d'envoi de formulaire.php.
Dans les braquets, figurent les noms que vous avez déclarés dans le ~~"heidi"~~, heu, le "ID" des champs.

Ce code va construire le mail en 4 parties. La fonction mail de PHP envoie l'adresse, le sujet du mail, le contenu du mail, l'auteur du mail. Attention à la séparation des données, matérialisée par des virgules. Notez enfin que l'ensemble figure dans le head de la page.

CODE


<html>

<head>

<title>demande d'information</title>


<?php


mail("email@destinataire","Demande d'infos","


Demande de ".$_POST['nom']." ".$_POST['prenom']."

E-mail: ".$_POST['mail']."
 

Adresse :

".htmlentities($_POST['adresse'])."

".$_POST['code']." ".$_POST['ville']." \n 


Telephone : ".$_POST['tel']."  ","


From:formulaire");


?>


<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

</head>

<body>


<p>Vos informations ont bien été envoyées.</p>


</body>

</html>

Vous voilà arrivé au terme de cette lecture. Il ne vous reste plus qu'à faire ou refaire votre formulaire, avec cette fois quelques éléments de compréhension supplémentaire, qui vous permettront de réaliser dans de bonnes conditions ce petit travail. Un dernier conseil: servez-vous des liens qui sont sur cette page, allez lire la doc, même si elle est parfois en anglais, ça vaut toujours la peine.

Et une précision pour finir: inutile de m'écrire pour me demander de l'aide. Ne m'en veuillez pas, mais je n'ai pas de temps pour cela. Mon aide, vous venez de la lire. Si vous avez des questions techniques, utilisez le forum que j'indique dans la webographie ci-dessous. En revanche, si vous trouvez des erreurs, relevez des inepties ou si vous avez envie de dire merci, n'hésitez pas !

Bon courage !

Webographie

Choisir son doctype: http://www.htmlhelp.com/tools/validator/doctype.html
Un cours (format PDF) sur les formulaires en php et html: Université de Genève
Une bonne référence technique avec forum sérieux: http://www.webmaster-hub.com/
XHTML, CSS et Standards du Web: http://www.alsacreations.com/

XHTML valide ? .::. CSS valide ? Réalisation, copyright: Net à jour