Bonjour,

j'ai une petite page de formulaire html dans laquelle je voudrais faire un contrôle sur un champ pour garantir qu'il soit au format nombre et que si on saisi autre chose ça envi un petit message d'erreur. Comment faire?

mon code est le suivant :

<label for="Nom">référence 01 :</label> <input type="text" name="ref1" id="ref1" size="8" maxlength="6"/>
<label for="Nom">libellé :</label> <input type="text" name="lib1" id="lib1" size="30" maxlength="30"/>
<label for="Nom">quantité :</label> <input type="text" name="qte1" id="qte1" size="4" maxlength="2"/></p>

c'est le champ quantité que je voudrais contrôler pour qu'il ne contienne que des caractères numériques.

merci pour votre aide !

Ca doit pouvoir se faire en javascript, en mettant un attribut onChange dans le champ qui appel une fonction qui va vérifier, chaque fois qu'on rentre un caractère, qu'il n'y a que des nombres.

Ça peut aussi se faire lorsque le formulaire est soumis (événement onSubmit du formulaire).

Par contre, la vérification devrait de toute façon se faire aussi côté serveur pour contrer un contournement de la vérification côté client (ex: scripts désactivés).

il y a une fonction incluse dans javascript qui permet de faire rapidement ce test :

function f_ctrlNaN(nomForm, NomElem)
{
if(isNaN(document.forms[nomForm].elements[NomElem].value))
{ alert(document.forms[nomForm].elements[NomElem].title+" non numérique");
document.forms[nomForm].elements[NomElem].focus();
return false
}
return true
}

pour ce qui est de la vérification coté serveur, je ne vois pas trop l'intéret.

>>pour ce qui est de la vérification coté serveur, je ne vois pas trop l'intéret.

Eviter le spam par les robots qui ne s'occupent que du html (contrôles js inopérant), éviter les attaques par injection, ou tout simplement vérifier les données envoyées par ceux qui désactivent le javascript et donc les fonctions de contrôle comme le disait Petit_PimoOosE.

En gros le js permet de gagner du temps pour l'utilisateur lambda (pas de refresh de page si erreurs), et le contrôle côté serveur de véritablement faire les vérifications, le js est donc secondaire.

Généralement on controle coté client le format des données et coté serveur les règles fonctionnelles.

Effectivement il y a toujours des exceptions qui confirme la règle. On pourrais aussi prévoir le cas des chinois qui n'utilise pas les caractères numériques habituels ...

Ajouter du code pour un risque plus que faible, c'est le meilleurs moyen d'exploser les budgets et de ne plus avoir ensuite le temps de tester le reste du code et le programme plante ailleurs...

defrance > pas du tout d'accord avec toi et entierement d'accord avecv moinal. il n'y a pas de risque minimum, soit tu codes correctement et tu geres en consequence a la fois le cote client et le cote serveur, soit tant qu'a faire tu ne fais rien du tout. en faire la moitie revient a ne rien faire

d'autre part, ajouter du code et exploser les budgets... c'est pas avec un controle en une ligne dans ton php que tu vas exploser les budgets en revanche, un trou de secu decouvert et utilise et la oui tu vas exploser les budgets

pour conclure, je repete l'adage habituel : ca ne prend pas plus de temps de bien faire que de mal faire, en consequence, autant bein faire du depart

et j'ajouterais que ce sont de toute facon de bonnes habitudes de codage a prendre, une fois que tu as reellement compris les risques, alors tu le fais machinalement et ca roule. et puis entre nous, quand tu bouffe du site a longueur de journee, a moins d'etre un gros bourrin, tu as tes propres bibliotheques de fonctions, en consequence, aucune surcharge ni dans le code ni dans l'emploi du temps, c'est typiquement le concept fondamental de reusabilite

quant aux problemes de codage de caracteres type chinois comme tu dis, je ne vois pas le probleme, l'utf-8 sert a ca il me semble et si le gars met un caractere "non chiffre" alors de toute facon le script le bloquera, et pour le coup la oui tu est dans un cas plus que particulier

enfin c mon avis

++

sinon autre chose, pour le controle en js, le onchange n'est pas la bonne solution dans le sens ou a chaque touche il y a controle, un onsubmit est plus adapte car il concerne la verif de tout le forumlaire, autant ne pas surcharger la page en evenements, sinon le pauvre utilisateur risque de se retrouver avec un message d'erreur a chaque champ, donc pas de onchange, au pire tu utilises onblur sur le champ, la tu fais le controle seulement sur la perte de focus

bah l'avantage du onchange, c'est que dès que tu tente de mettre un caractère non numérique, la frappe est bloquée et on te gueule dessus. Donc tu ne refais pas l'erreur et tu n'as pas a te retaper tout le formulaire avec tes erreurs lorsque tu l'envoie.

Le 09 septembre 2007 - 23 h 13, Woofy a écrit : bah l'avantage du onchange, c'est que dès que tu tente de mettre un caractère non numérique, la frappe est bloquée et on te gueule dessus. Donc tu ne refais pas l'erreur et tu n'as pas a te retaper tout le formulaire avec tes erreurs lorsque tu l'envoie.

je suis d'accord avec toi sur ce point, cependant n'oublies pas que le javascript s'execute cote client, en consequence, le pauvre gars qui a un ordi de daube, il va peter les plombs avec les evenements a chaque frappe de touche
bon c'est pas le cas general, mais disons que comme avant, meme si nos becannes sont plus grosses qu'avant, il y a encore des petites configs partout, et donc j'essaye de conserver l'esprit de depart qui voulait qu'un site passe sur toute config, meme petite. d'autre part, sur le onsubmit, tu n'executes qu'une seule fonction globalement, alors qu'avec les onchange, tu vas declencher des fonctions differentes, donc page plus grosse, donc temps de chargement plus lent... bref.
tu vois ce que je veux dire

apres ok au final ca change pas des masses

Il me semble qu'idéalement, chaque champ devrait être vérifié au onSubmit, et chaque faute fait afficher un message à côté du champ concerné (ou quelque part dans le formulaire). Une faute ou plus fait retourner "false", ce qui permet à l'utilisateur de corriger directement ses erreurs...