Petit rappel sur les formulaires
Rappelons-nous d'abord de quoi est composé un formulaire :
- de champs de saisie, matérialisés par des balises
input
,select
ettextarea
; - de boutons pour valider ou annuler / effacer le formulaire,
respectivement
<input type="submit" />
et<input type="reset" />
; - une balise
form
qui encadre le tout ; - et éventuellement ce fameux script en Javascript qui va vérifier le contenu avant son envoi vers le serveur Web.
Cet ensemble peut être complété par des balises label
,
fieldset
, legend
, etc.
pour améliorer l'accessibilité et la structure d'un formulaire. Je vous renvoie à l'article
Utilisation des formulaires pour
en savoir plus à ce sujet. Nous ne nous occuperons ici que de l'aspect Javascript.
Voila ce que cela pourrait donner :
<form action="url_page_suivante" method="get" name="formSaisie"> <p> <label for="prenom">Saisissez votre prénom :</label> <input type="text" name="prenom" id="prenom" /> <input type="submit" value="Ok" /> </p> </form>
Nous sommes dans l'hypothèse où notre page est conforme au
XHTML 1.0 Transitionnal,
et non Strict, pour faciliter la compréhension des exemples qui suivront. En effet, en
XHTML Strict ou HTML
4.01 Strict, l'attribut "name"
de la balise form
est obsolète. De ce fait, il est impossible avec ces DTD
d'utiliser le code document.nom_du_formulaire
, très souvent utilisé,
pour accéder aux champs de saisie (comme par exemple
document.nom_du_formulaire.mon_champs.value
). Nous verrons
à la fin de cet article comment contourner cette restriction et écrire du code
respectant un peu mieux les spécifications du DOM,
utilisable avec toutes les versions de HTML et sur tous les navigateurs.
Les erreurs les plus courantes
En général, les formulaires ressemblent à notre exemple, il n'y a pas trop de soucis. Là où ça se gâte, c'est au moment d'inclure le petit bout de code Javascript qui va vérifier que l'internaute a bien saisi un prénom (en se référant à notre exemple), avant d'envoyer le formulaire.
Beaucoup de développeurs, instinctivement, implémentent (à tort) cette vérification au niveau du clic sur le bouton « Ok ». C'est ainsi que l'on trouve ce genre de fonction (à ne pas faire).
<script type="text/javascript"> //<![CDATA[ function valider() { // si la valeur du champ prenom est non vide if(document.formSaisie.prenom.value != "") { // alors on envoie le formulaire document.formSaisie.submit(); } else { // sinon on affiche un message alert("Saisissez le prénom"); } } //]]> </script>
Puis sur le bouton « Ok », on trouve en général
l'appel de la fonction valider()
sur l'événement
"onclick"
, déclenché lorsque
l'on clique sur le bouton, ce qui ressemble à ceci (Cas A) :
<input type="submit" value="Ok" onclick="valider()" />
On trouve parfois aussi, non pas un bouton « submit » mais un bouton tout court, ou une image, ou un lien, ce qui est encore moins bien (Cas B):
<input type="button" value="Ok" onclick="valider()" /> <img src="ok.png" onclick="valider()" alt="ok" /> <a href="/articles/validation_formulaire#" onclick="valider()">Ok</a>
Souvent même, la fonction valider()
est
appelée directement dans l'attribut "href"
d'un lien (Cas C):
<a href="javascript:valider()">Ok</a> <a href="javascript:valider()"><img src="ok.png" alt="ok" /></a>
Pourquoi ce sont des erreurs ?
Il faut se mettre en tête que :
- l'utilisateur peut vouloir préférer appuyer sur la touche Entrée de son clavier plutôt que de cliquer sur le bouton « Ok ». Il peut s'agir des inconditionnels du clavier, mais il peut s'agir aussi de personnes qui sont obligées de passer par le clavier. Il y a ainsi ceux qui utilisent un navigateur texte. Il y a aussi les handicapés moteurs pour qui la manipulation de la souris peut être difficile. Il y a aussi les gens qui doivent manipuler à longueur de temps des formulaires, comme c'est le cas dans les applications intranet. Car éviter de passer du clavier à la souris et de la souris au clavier permet d'être plus productif et est moins fatiguant. Tous les ergonomes vous le diront ;
- le Javascript n'est pas forcément disponible dans le navigateur de l'internaute (ou tout simplement désactivé). La plupart des statistiques rapportent que c'est le cas pour 5 à 7% des internautes.
Ces constats nous amènent donc à nous rendre compte que les exemples vus précédemment sont inadaptés.
Dans le cas A, si l'utilisateur appuie sur la touche
Entrée en étant dans l'un des champs de
saisie, ou s'il met le focus sur le bouton avec la touche Tab
puis en appuyant sur Entrée, le formulaire
sera envoyé, sans même que la fonction valider()
soit
exécutée (Ce n'est cependant pas le cas de tout les navigateurs). En effet,
elle n'est ici appelée que sur l'événement "onclick"
.
Dans le cas B, étant donné qu'il ne s'agit ni de bouton « submit », ni de bouton « image », la touche Entrée est inactive, et ne provoque pas l'envoi du formulaire. On est obligé de cliquer sur le bouton, l'image ou le lien. Cela peut être donc embêtant pour certaines personnes comme on l'a vu.
Pire, dans les cas B et C, si le support du Javascript est désactivé ou n'est pas présent dans le navigateur, le formulaire ne pourra jamais être envoyé ! Idem si on n'a pas de souris (navigateur texte) dans le cas B !
La bonne façon de vérifier un formulaire
En fait, il n'existe qu'une seule méthode valable pour vérifier le contenu d'un formulaire en Javascript avant son envoi.
Utilisation des bons boutons
Le/les bouton(s) pour envoyer le formulaire doivent être :
- soit de type « submit » :
<input type="submit" value="Ok" />
; - soit de type image, si on veut un bouton « submit »
sous forme d'image :
<input type="image" src="ok.png" alt="ok" />
.
Rappelez-vous qu'il est possible d'utiliser des feuilles de styles pour changer l'apparence des boutons : couleurs, bordures, image de fond, etc. Il faut noter cependant que certains navigateurs ne permettent pas d'utiliser tous les styles sur les boutons.
L'événement "onsubmit"
Cet événement, spécifique à la balise form
, est
déclenché lorsque le formulaire est sur le point d'être envoyé, suite à
l'appui sur la touche Entrée, ou d'un clic sur un
bouton « submit », ou toute autre action indiquant au navigateur
d'envoyer le formulaire.
Donc l'éxecution d'un script devant vérifier le contenu du formulaire
(ou faisant éventuellement d'autres traitements liés à l'envoi)
doit toujours se faire sur l'événement "onsubmit"
!
Comme sur tous les événements ("onclick"
…),
le script appelé doit renvoyer un booléen, true
ou
false
. S'il ne renvoie rien, l'événement reçoit
true
par défaut. Ce booléen indique si l'événement
doit se propager, c'est-à-dire si l'événement par défaut doit s'exécuter.
Ainsi, si vous renvoyez true
sur l'événement
"onsubmit"
, le formulaire sera envoyé.
Si vous renvoyez false
, il ne le sera pas et le navigateur ne changera
pas de page. Par exemple, en mettant onsubmit="return false"
,
le formulaire ne pourra jamais être envoyé !
Nous devons donc appeler notre fonction valider()
sur
le "onsubmit"
, et celle-ci devra renvoyer
un booléen pour indiquer si le formulaire doit être envoyé ou non :
<script type="text/javascript"> //<![CDATA[ function valider(){ // si la valeur du champ prenom est non vide if(document.formSaisie.prenom.value != "") { // les données sont ok, on peut envoyer le formulaire return true; } else { // sinon on affiche un message alert("Saisissez le prénom"); // et on indique de ne pas envoyer le formulaire return false; } } //]]> </script>
Et la balise form
devient :
<form action="url_page_suivante" onsubmit="return valider()" method="get" name="formSaisie"> <p> <label for="prenom">Saisissez votre prénom :</label> <input type="text" name="prenom" id="prenom" /> <input type="submit" value="Ok" /> </p> </form>
Notez l'emploi du mot-clé return
sur l'appel de valider()
.
Ainsi, que l'on appuie sur la touche Entrée ou
que l'on clique sur le bouton « submit », la fonction
valider()
sera toujours appelée. Et si le Javascript n'est
pas activé, cela n'empêche pas le contenu du formulaire d'être envoyé.
Quelques précisions
- Le test du contenu d'un formulaire en Javascript doit être seulement considéré comme un plus pour le confort de l'utilisation de la page, afin d'éviter un envoi et un rechargement du formulaire si son contenu est invalide. Il ne remplace en aucun cas une vérification faite côté serveur, qui doit être systématique (que ce soit en PHP, ASP, Java, etc.), afin de palier le cas où le Javascript n'est pas activé, donc au cas où le formulaire n'est pas vérifié côté navigateur.
- S'il y a du code Javascript qui envoie le formulaire en appelant
la methode
submit()
de l'objet formulaire comme ceci :document.formSaisie.submit();
, l'événement"onsubmit"
n'est pas déclenché, mais le formulaire est tout de même envoyé. Donc la fonctionvalider()
ne sera pas appelée dans ce cas. - On évitera d'utiliser les méthodes propriétaires à Internet Explorer comme
document.all
pour récupérer l'objet formulaire ou les objets correspondants aux champs de saisie, afin de garder une interopérabilité maximum. On préferera utiliser les fonctions du DOM comme nous allons le voir dans la section suivante.
La vérification de formulaire en Strict
Le problème des DTD Strict (HTML 4.01 Strict,
XHTML 1.0 Strict ou XHTML 1.1),
c'est que l'attribut "name"
de la balise
form
est obsolète. Du coup, il est impossible de
récupérer l'objet formulaire par l'instruction suivante comme on a très souvent l'habitude
de faire : document.formSaisie
. Cette instruction est en fait
un raccourci de ce qu'il faudrait faire.
Utilisation du DOM avec la collection forms
L'objet document
possède une propriété forms
,
qui est une collection contenant les objets formulaires présents dans la page.
On peut alors l'utiliser de deux manières pour récupérer l'objet formulaire désiré
document.forms[n]
oùn
est le numéro de formulaire, 0 étant le premier formulaire.- ou
document.forms['mon_formulaire']
oùmon_formulaire
est la valeur de l'attribut"id"
de la baliseform
, ou bien de l'attribut"name"
en (X)HTML transitionnal. Il faut savoir que si la baliseform
a les 2 attributs, c'est la valeur de l'attribut"id"
qu'il faudra utiliser pour récupérer votre objet formulaire.
Ensuite, un objet formulaire contient une propriété elements
qui est une collection contenant les éléments de saisie du formulaire. On récupère
donc un élément du formulaire d'une de ces façons :
-
document.forms['mon_formulaire'].elements[n]
oùn
est le numéro de l'élément dans la collection, 0 étant le premier élément. - ou
document.forms['mon_formulaire'].elements['mon_element']
oùmon_element
est la valeur de l'attribut"id"
ou"name"
de l'élément. Même remarque que pour les formulaires si il y a les 2 attributs, il faudra utiliser la valeur de l'attribut"id"
pour récupérer l'élément.
Notre fonction valider()
devient donc
function valider(){ frm=document.forms['frmSaisie']; if(frm.elements['prenom'].value != "") { return true; } else { alert("Saisissez le prénom"); return false; } }
Ou encore
function valider(){ elt=document.forms['frmSaisie'].elements['prenom']; if(elt.value != "") { return true; } else { alert("Saisissez le prénom"); return false; } }
C'est une méthode qui fonctionne sur tous les navigateurs. Tout comme la solution suivante.
Utilisation de this
Le mot clé this
désigne toujours l'objet
courant. Si on l'utilise lors de l'appel de la fonction
valider()
dans le "onsubmit"
,
on peut transmettre l'objet formulaire à la fonction valider()
:
<script type="text/javascript"> //<![CDATA[ function valider(frm){ if(frm.elements['prenom'].value != "") { return true; } else { alert("Saisissez le prénom"); return false; } } //]]> </script> <form onsubmit="return valider(this)" id="frmSaisie" …> … </form>
À noter une petite astuce au passage : si vous avez
besoin de faire des manipulations du formulaire Javascript sur
des événements des champs de saisie ou de boutons, sachez que
les objets Javascript correspondants à ces éléments
HTML ont une propriété form
représentant l'objet formulaire. Voici un exemple d'utilisation :
<script type="text/javascript"> //<![CDATA[ function afficher(frm){ alert("Vous avez tapé : " + frm.elements['prenom'].value) } //]]> </script> <form> <p> <label for="prenom">Saisissez votre prénom :</label> <input type="text" name="prenom" id="prenom" /> <input type="button" value="Afficher" onclick="afficher(this.form)" /> <input type="submit" value="Ok" /> </p> </form>
Les commentaires dans la balise script
En théorie, le code situé entre les balises script
,
doit être encadré par <![CDATA[
et ]]>
.
C'est la manière en XHTML d'indiquer que le contenu représente des données.
En HTML, il faut utiliser les délimiteurs de commentaires HTML, à savoir
<!--
et -->
, pour éviter que le code
javascript ne s'affiche dans les anciens navigateurs.
Pour que le contenu de la balise script en XHTML soit interpreté correctement, quel que soit le navigateur (pas trop vieux, de l'époque de IE6 par exemple), y compris donc ceux qui ne connaissent pas XHTML, il faut alors utiliser l'astuce suivante :
<script type="text/javascript"> //<![CDATA[ ... //]]> </script>
La façon la plus simple et celle qui garantie une parfaite compatibilité entre les navigateurs, est de mettre le script dans un fichier séparé :
<script type="text/javascript" src="nom_de_mon_fichier.js"></script>
Conclusion
Si la validation en JavaScript est pratique pour l'utilisateur, il convient de la
développer correctement de façon à rester compatible avec tous les types de navigateurs
et d'usages. Pour cela, le recours au bouton submit
s'impose !
Vos commentaires
# Le 29 juillet 2010 à 09:57
Un article clair et precis. !
Javascript reste néanmoins pour moi un sous-langage a ne pas mettre entre toutes les mains de bidouilleurs ou plutôt scriptouilleurs. (ss langage car pas assez de sécurité, pas de typage, trop de variante, lié aux navigateurs et j’en passe)
# Jones Le 20 novembre 2010 à 16:47
très bonne explications !
Le seul problème avec submit est qu’on est obligé de recharger de page ce que l’on voudrait parfois pas vraiment avec javascript...
# Goldorak Le 14 janvier 2011 à 10:03
Superbe documentation ! Si tous les tutos pouvaient être de cette qualité...!
Merci Laurent !
# Seb Le 28 janvier 2011 à 03:41
"La plupart des statistiques rapportent que c’est le cas pour 5 à 7% des internautes."
Aujourd’hui, en 2011, ce taux est inférieur à 2%
Un article où des tests on été effectués sur les visiteurs de Yahoo :http://dev.neowebmag.com/javascript-ajax/combien-de-visiteurs-desactivent-javascript
Le taux moyen de JavaScript désactivé oscille autour de 1,3% des visiteurs réels (1,46% pour la France), avec pour taux le plus élevé près 2% aux États-Unis et le plus bas autour de 0,25% au Brésil.
Des témoignages pour de plus petits sites, donnent des résultats toujours inférieurs à 1%.
# Seb Le 28 janvier 2011 à 03:42
"La plupart des statistiques rapportent que c’est le cas pour 5 à 7% des internautes."
Aujourd’hui, en 2011, ce taux est inférieur à 2%
Un article où des tests on été effectués sur les visiteurs de Yahoo :http://dev.neowebmag.com/javascript-ajax/combien-de-visiteurs-desactivent-javascript
Le taux moyen de JavaScript désactivé oscille autour de 1,3% des visiteurs réels (1,46% pour la France), avec pour taux le plus élevé près 2% aux États-Unis et le plus bas autour de 0,25% au Brésil.
Des témoignages pour de plus petits sites, donnent des résultats toujours inférieurs à 1%.
# GUI Le 4 février 2011 à 10:29 En réponse à : Jones
Pas avec le XHR !!!!
Si ton but est d’éviter de recharger les pages, tu utilises Ajax, donc tu peux faire des submit sans recharcger la page. C’est le but !
# Le 26 mai 2011 à 09:13
Cool les explications... merci ! Je passais par hasard et voilà que je tobe sur ce bonheur ! J’ai vrament apprecié ce mini tuto-conseil
# Le 31 mai 2011 à 12:39
Super !
Merci ! enfin un article clair, simple et précis, bravo !
# mouhibi Le 1er juin 2011 à 11:38
waaaaaaaaaw je peux rien dire :)
# mouhibi Le 1er juin 2011 à 12:17 En réponse à : Anonyme
tres bonne expliquation :)
merci
# Asmaa Le 8 juin 2011 à 22:09
merciiiiiii bcp pour cet article
# Kach Le 24 août 2011 à 13:36
Enfin des réponses à mes questions.
Merci
# Kiki Le 21 septembre 2011 à 09:44
Parfaite et concis, cette explication expose bien les erreurs à ne pas commettre ! Moi même en BTS informatique de Gestion 2ème année, ce rappel ne peut faire que du bien ! Merci !
# medalimeziane Le 9 février 2012 à 14:26
Salut,
Je veux remercier mon ami Google qui m’a emmené de la Tunisie jusqu’ici sur cette page.
Merci pour à Laurent Jouanneau de cet article clair et complet qui reste encore une référence malgrès le passage de presque 8 ans déjà.
Toutefois, j’espère trouver une aussi complète explication sur la meilleure validation coté serveur en PHP.
Encore merci..
# Le 24 février 2012 à 22:22
Merci pour ce très bon article :)
# amateur Le 23 septembre 2012 à 17:45
Merci beaucoup pour ces explications qui m’ont beaucoup éclairé.
# XcentY Le 26 octobre 2012 à 08:57
Je ne m’avancerai pas pour dire que telle ou telle manière choisie par un développeur est une erreur et que l’auteur est la bonne et unique manière de faire.
Le problème de son "onSubmit()" avec la validation par la touche Return est pour moi le plus gros soucis puisque des utilisateurs inexpérimentés valideraient le formulaire avant d’avoir rempli tous les champs. De plus, les gens qui utilisent le clavier, naviguent dans le formulaire avec la touche de tabulation et il n’y a rien qui empêche de valider le formulaire en tapant la touche Return quand la tabulation arrive sur le bouton.
# Laurentj Le 21 novembre 2012 à 09:19
@XcentY
>Le problème de son "onSubmit()" avec la validation par la touche Return
Il n’y a aucun problème avec la touche return ou tab : dans le script JS du onsubmit, qui est appelé quand on appuie sur Return ou que l’on clique sur le bouton de submit, à vous de vérifier le contenu du formulaire et de renvoyer true ou false (ou de faire un preventDefault() sur l’event sbmit), pour accepter ou non l’envoi du formulaire.
Bref, si le JS du onsubmit est correctement fait, le formulaire ne peut être envoyé au serveur si le contenu n’est pas valide.
Et de toute manière, il faut aussi COTE SERVEUR, toujours valider les données qui sont soumises, car le JS peut avoir buggé dans la page, ou que l’utilisateur a désactivé le JS dans son navigateur, ou encore que le formulaire est envoyé par un robot (cas des outils pour spammer).
Donc non, il n’y a aucun souci si le développeur fait une bonne vérification des données à la fois coté client (en js) et coté serveur (ce qui est le plus important).
# rick des bois Le 19 février 2013 à 11:41
Merci ce tuto clair et concis m’a beaucoup aidé dans mon apprentissage. ;)
# sarah Le 8 mars 2013 à 21:29
Hello, merci pour cet article. J’étais sur un tuto qui s’est révélé incomplet en fait ! grace à vous j’ai trouvé l’erreur. Thx.
# sami Le 19 mars 2013 à 10:49
c’est très bien
# emma Le 19 mars 2013 à 17:30
bonjour
Merci pour votre tuto qui est super bien expliqué
j’aimerais savoir comment vous gérez la vérification de plusieurs champs ?
quelle est la meilleure méthode pour vous ?
Personnellement, j’ai fais des if imbriqués.
merci par avance pour votre avis
# Béryl Le 20 mars 2013 à 18:49
Tuto clair, précis et fouillé.
Les exemples sont simples et utilisables immédiatement.
Les mises en garde sont particulièrement pertinentes.
Bravo et merci à Laurent, son auteur, de nous guider aussi bien.
# B Le 20 mars 2013 à 20:00
A l’attention d’Emma (19 mars 17:30)
Une tentative pour vous donner le listing de la façon de faire que j’ai adoptée n’ayant pu aboutir du fait que toutes les accolades ne ressortaient pas, je vous propose de vous l’envoyer par mail si vous le souhaitez.
Il s’agit en fait de répéter, dans un fichier que j’appelle verif.js, la formule suivante autant de fois qu’il y a de champs de formulaire à vérifier :
if (condition sur le champ)
[accolade] alerte += "\n- Nom" ; n=n+1 ; test=false [accolade]
en ayant pris le soin d’initialiser alerte à "", n à 0, test à true.
On termine en vérifiant la valeur de n :
– 0 : on sort sans alerte ;
– 1 : message d’erreur au singulier et liste des erreurs concaténées dans "alerte" ;
– 2 : comme ci-dessus pour 1, mais message d’erreur au pluriel.
L’émission du message d’erreur consiste à écrire alert(alerte).
On termine par un "return test" (sans les guillemets).
Pour être complet, on place la ligne suivante entre les balises
etdu fichier du formulaire :
<script type="text/javascript" src="verif.js"></script>
Cordialement
# Béryl Le 20 mars 2013 à 20:04
Oups !
Le message précédent est parti un peu vite.
A l’attention d’Emma (19 mars 17:30)
Une tentative pour vous donner le listing de la façon de faire que j’ai adoptée n’ayant pu aboutir du fait que toutes les accolades ne ressortaient pas, je vous propose de vous l’envoyer par mail si vous le souhaitez. Il s’agit en fait de répéter, dans un fichier que j’appelle verif.js, la formule suivante autant de fois qu’il y a de champs de formulaire à vérifier :
if (condition sur le champ) [accolade] alerte += "\n- Nom" ; n=n+1 ; test=false [accolade]
en ayant pris le soin d’initialiser alerte à "", n à 0, test à true. On termine en vérifiant la valeur de n :
- 0 : on sort sans alerte ;
- 1 : message d’erreur au singulier et liste des erreurs concaténées dans "alerte" ;
- 2 : comme ci-dessus pour 1, mais message d’erreur au pluriel. L’émission du message d’erreur consiste à écrire alert(alerte). On termine par un "return test" (sans les guillemets).
Pour être complet, on place la ligne suivante entre les balises et du fichier du formulaire :
<script type="text/javascript" src="verif.js"></script>
Cordialement
# Jiji Le 5 avril 2013 à 12:12
Très clair ; merci
# Koffi Le 29 mai 2013 à 10:52
Très bon tuto. Je dirai tout simplement, Bravo !
# Webmaster Le 29 mai 2013 à 19:20
je veux savoir comment vérifier une adresse e-mail
un exemple svp
cordialement
# Mohcine Le 19 juin 2013 à 16:22
Un très bon article,
Merci à vous tous
# zeboudja Le 3 juillet 2013 à 10:13
Merci pour cette clarté
# nobody Le 11 septembre 2013 à 14:24
Bonjour,
les méthodes indiquées ici sont idéales, (vérification côté serveur, et client, usage du onsubmit et du input submit) cependant, la réalité et l’évolution des techniques change quelque peu la donne.
A l’heure de l’Ajax, avec un usage intensif du JavaScript, et une standardisation des différentes implémentations, il devient de plus en plus rare de trouver des sites fonctionnant SANS JavaScript. En effet, le confort et les fonctionnalités que procure l’utilisation de XHR, font qu’il est parfois impossible de faire un site équivalent sans activation du JavaScript.
C’est malheureusement au dépend des personnes à besoins spécifiques comme avec les lecteurs Braille, ou audio. (bien que de nombreux systèmes le gèrent de nos jours également).
l’activation ou non du JavaScript est devenu un problème exceptionnel (ce que montre les différentes enquêtes...).
Quant au "input submit", c’est alors les graphistes des applications qui s’arrachent les cheveux par manque de standardisation de l’apparence de ces derniers qui peuvent vous ruiner une belle page.
Quant aux handicap visuels, c’est souvent plus du ressort d’une bonne présentation et d’une gestion propre du CSS que cela se trouve gérer.
J’encourage néanmoins l’utilisation autant que possible des bonnes pratiques ci-dessus énoncées, mais parfois il faut savoir faire quelques exceptions.
# andy Le 31 mars 2014 à 17:26
super explication, merci ! on ne peut pas être plus clair. enfin une aide en programmation bien expliquée !
# nesrine Le 14 mai 2014 à 19:24
je veut changer l’apparence des messages d’alerte pouvez vous m’aider voici le code
function verifClient()
var val3 =document.getElementById("val3").value ;
var forme2 = document.getElementById("forme2") ;
$.ajax(
url : "ajaxSupClinet.php",
type : "get",
data : "name=" + val3 ,
success : function(resultat)
if( $.trim(resultat) == "true" && confirm (’Voulez vous supprimer le client ?’ ))
alert("Client supprimée") ;
forme2.submit() ;
else
alert("Client inexistant") ;
return false ;
) ;
# Elodie Le 4 juillet 2016 à 11:28
Excellent article
# Vetime Le 24 août 2017 à 13:27
Bonjour, votre démonstration est très intéressante et bien documentée, le problème est qu’un formulaire ne comporte pas que le prénom, j’ai essayé d’ajouter le nom et la cela fonctionne pour le prénom mais cela ne fonctionne pas pour le nom
function valider()
// si la valeur du champ prenom est non vide
if(document.formSaisie.prenom.value != "")
// les données sont ok, on peut envoyer le formulaire
return true ;
else
// sinon on affiche un message
alert("Saisissez le prénom") ;
// et on indique de ne pas envoyer le formulaire
return false ;
if(document.formSaisie.nom.value != "")
// les données sont ok, on peut envoyer le formulaire
return true ;
else
// sinon on affiche un message
alert("Saisissez le nom") ;
// et on indique de ne pas envoyer le formulaire
return false ;
Pourriez nous indiquer que faire si il y a plusieurs champs
par avance merci
Cordialement
A.Vetime
# docteurflata Le 18 mars 2018 à 15:07
très bonne explication, j’ai facilement compris ce cours qui est d’une grande clarté.
Vos commentaires
Suivre les commentaires : |