validation formulaire |
See You Why? |
Les pages en français traitant du sujet sont nombreuses sur le Web : Google en ce début 2013 nous en propose près de 50 000. Rares sont celles qui répondent valablement à ce que des créateurs de sites voudraient obtenir. Vérifier qu'un formulaire soit bien rempli est un problème classique en JS. Mais n'oubliez pas que chacun peut désactiver le JS et que votre script de vérification peut ne pas être fiable.
Cependant, JS garde de nombreux avantages dans la pré-vérification de vos formulaires, en effet:
Avant de valider les entrées d'un formulaire, nous renverrons le lecteur à la construction de formulaire que nous avons développée dans notre page HTML. Cependant, nous ne croyons pas que cette page puisse vous expliquer toutes les nuances de la création d'un bon formulaire. Nous rappellerons donc l'essentiel des formulaires.
Avant de vouloir valider chaque entrée d'un formulaire, le lecteur aura dû prendre connaissance de la façon d'accéder et/ou modifier chaque élément d'un formulaire, ce qui a été fait dans le chapitre précédent. Si cela ne présente plus aucun problème, libre à vous de poursuivre la lecture de ce chapitre.
Sans forcer le lecteur à lire ou relire les pages mentionnées ci-dessus, nous préférons rappeler, ici l'essentiel concernant les formulaires :
Ce qui nous intéressera, c'est le contenu de ce fichier JS qui vérifie les réponses données.
Notre but n'est pas de critiquer ce que vous faites, mais d'attirer votre attention sur les conséquences de certains choix faits par les concepteurs de pages ou d'habitudes prises par certains internautes.
"En bien quoi ? C'est bien ce que l'on nous a appris en HTML."
Certes, vous n'avez pas tort. Les fans de l'ordi sont souvent aussi des fanatiques de la souris. Mais il ne faut pas oublier que les utlisateurs acharnés du clavier sont également très nombreux (j'en fais partie). Tous les employeurs et ergonomes le savent : les acharnés du clavier sont plus productifs, car ils ne perdent pas à chaque opération les secondes pour lâcher son clavier et retrouver sa souris (sur sa table de travail et sur son écran) ou vice-versa.
"Pas de problèmes... les inconditionnels du clavier savent tous que l'on peut passer d'un champ de formulaire à un autre en appuyant sur la touche 'TAB' et 'Enter' pour simuler un 'clic' sur un bouton."
Exact, mais tous les navigateurs n'acceptent pas ce détour de la même façon qu'un 'clic' sur le bouton... donc pas de réponse à l'évènement 'onclick'... donc pas de vérification si l'on a créé un bouton ainsi <input type="submit" value="OK" onclick="verifier()" />
.
Outre ce bouton 'OK', on trouve aussi des variantes trop nombreuses, mais qui présentent les mêmes inconvénients :
<script type="text/javascript">
function verifier() {
// si la valeur du champ 'nom de famille' n'est pas vide
if(document.formSaisie.nom.value != "") {
// alors on envoie le formulaire
document.formSaisie.submit();
} else {
// sinon on affiche un message
alert("Saisissez le nom de famille");
}
}
</script>
ou encore via un bouton-image <img src="ok.jpg" onclick="verifier()" alt="ok" />
ou même un simple lien <a href="../verification_formul#" onclick="verifier()">Ok</a>
voire aussi <a href="javascript:verifier()">Ok</a>
ou <a href="javascript:verifier()"><img src="ok.jpg" alt="ok" /></a>
.
En bref, évitez de sortir d'un formulaire par une instruction de type 'onclick'.
Même si les navigateurs acceptent encore la désignation d'un formulaire par l'attribut 'name', ce dernier est devenu obsolète depuis l'apparition de la norme HTML5. On préfèrera (avant d'y être bientôt obligé) l'emploi de l'attribut 'id' pour désigner ou identifier un formulaire.
Pour l'instant, si on emploie les deux attributs et si leurs noms diffèrent, c'est l'attribut 'id' qui sera pris en considération.
voir suite >>>
voir suite >>>