Contrôle formulaire en Javascript avant contrôle en PHP
16 réponses
Sam Lion
Bonjour à tous,
Un bout de code pour expliquer mon problème.
Soit un formulaire tout bête suivant :
---
<form name="ma_liste" action="" method="post">
<p>Quantité 1 : <input type="text" name="quantite[]" size="10" /></p>
<p>Quantité 2 : <input type="text" name="quantite[]" size="10" /></p>
[suite = submit etc.]
</form>
---
Il peut y avoir de une à des dizaines de lignes de quantité.
Pour le contrôler, je dois faire la somme des quantités
- En php, pas de problème : quantite[] me renvoie un tableau, je fais la
somme des quantités.
- En javascript avant envoi, a priori pas compliqué non plus :
---
function somme_quantite()
{
var nb_lignes = document.ma_liste.elements["quantite[]"].length;
for(i=0;i<nb_lignes;i++)
{
[Je fais la somme et divers traitements]
}
}
---
Mais c'est là que mon problème surgit : Quand il n'y a qu'une seule ligne
dans le formulaire, le javascript ne considère pas quantite[] comme un
tableau, et "nb_lignes" n'est donc pas défini, ni "
document.ma_liste.elements["quantite[]"][i].value " dans la boucle
Y-a-t-il un moyen simple pour contourner ce problème ?
Oui et non (à mon avis de non spécialiste de javascript), si c'est un tableau la propriété est "undefined", donc typeof lignes ne me renvoie pas "string" et je sais donc que j'ai plusieurs lignes...
D'accord, la propriété appelée n'existant pas pour un tableau renverra bien "undefined". Mais comme cet appel est fait dans une affectation de valeur à une variable (var lignes =...), cela provoquera une erreur visible dans la console JS du navigateur.
Ce n'est pas exactement l'inverse que de faire "lignes.length = > undefined" pour vous ?
Le test, lui, se place après l'affectation, donc le problème n'est pas là.
-- Cordialement, Pascal
Le 22/11/2010 17:02, Sam Lion a écrit :
Oui et non (à mon avis de non spécialiste de javascript), si c'est un
tableau la propriété est "undefined", donc typeof lignes ne me renvoie
pas "string" et je sais donc que j'ai plusieurs lignes...
D'accord, la propriété appelée n'existant pas pour un tableau renverra
bien "undefined".
Mais comme cet appel est fait dans une affectation de valeur à une
variable (var lignes =...), cela provoquera une erreur visible dans la
console JS du navigateur.
Ce n'est pas exactement l'inverse que de faire "lignes.length = > undefined" pour vous ?
Le test, lui, se place après l'affectation, donc le problème n'est pas là.
Oui et non (à mon avis de non spécialiste de javascript), si c'est un tableau la propriété est "undefined", donc typeof lignes ne me renvoie pas "string" et je sais donc que j'ai plusieurs lignes...
D'accord, la propriété appelée n'existant pas pour un tableau renverra bien "undefined". Mais comme cet appel est fait dans une affectation de valeur à une variable (var lignes =...), cela provoquera une erreur visible dans la console JS du navigateur.
Ce n'est pas exactement l'inverse que de faire "lignes.length = > undefined" pour vous ?
Le test, lui, se place après l'affectation, donc le problème n'est pas là.
-- Cordialement, Pascal
Pascal
Le 22/11/2010 17:38, Y.D. a écrit :
Ah ! Et que vaut !undefined ?
Bien sûr, un double transtypage !
Si c'est une question de style, plutôt que tester undefined je préférerai if (!("length" in lines))
Je suis d'accord.
Autant utiliser la syntaxe littérale, toujours plus sure.
En quoi est-ce plus sûr ? [...]
Pour faire court, déjà parce que la syntaxe "new Array(truc)" est ambigüe, puisqu'elle peut exprimer un dimensionnement avec un entier.
On peut aussi écrire lignes = Array(lignes); c'est tout aussi correct.
Je préfère, c'est plus clair.
Ça, c'est votre problème pas celui du javascript qui s'y retrouve tout à fait et qui impose dans votre code un else et une affectation inutiles (ou l'utilisation de l'opérateur ternaire).
Oui, je sais, il y mille façons de coder la même chose, qui "marche". Et certaines règles de style ne peuvent être que conventionnelles. Pourquoi ne pas violer les conventions ? Éternelle question, de goût pour les uns, de qualité pour les autres.
Il faut tenir compte du fait que mes remarques s'adressaient davantage à l'auteur du fil, qui se déclare lui-même débutant. Je pensais bien faire (je le pense encore).
-- Cordialement, Pascal
Le 22/11/2010 17:38, Y.D. a écrit :
Ah ! Et que vaut !undefined ?
Bien sûr, un double transtypage !
Si c'est une question de style, plutôt que tester undefined je préférerai
if (!("length" in lines))
Je suis d'accord.
Autant utiliser la syntaxe littérale, toujours plus sure.
En quoi est-ce plus sûr ? [...]
Pour faire court, déjà parce que la syntaxe "new Array(truc)" est
ambigüe, puisqu'elle peut exprimer un dimensionnement avec un entier.
On peut aussi écrire
lignes = Array(lignes);
c'est tout aussi correct.
Je préfère, c'est plus clair.
Ça, c'est votre problème pas celui du javascript qui s'y retrouve tout à
fait et qui impose dans votre code un else et une affectation inutiles
(ou l'utilisation de l'opérateur ternaire).
Oui, je sais, il y mille façons de coder la même chose, qui "marche".
Et certaines règles de style ne peuvent être que conventionnelles.
Pourquoi ne pas violer les conventions ? Éternelle question, de goût
pour les uns, de qualité pour les autres.
Il faut tenir compte du fait que mes remarques s'adressaient davantage à
l'auteur du fil, qui se déclare lui-même débutant.
Je pensais bien faire (je le pense encore).
Si c'est une question de style, plutôt que tester undefined je préférerai if (!("length" in lines))
Je suis d'accord.
Autant utiliser la syntaxe littérale, toujours plus sure.
En quoi est-ce plus sûr ? [...]
Pour faire court, déjà parce que la syntaxe "new Array(truc)" est ambigüe, puisqu'elle peut exprimer un dimensionnement avec un entier.
On peut aussi écrire lignes = Array(lignes); c'est tout aussi correct.
Je préfère, c'est plus clair.
Ça, c'est votre problème pas celui du javascript qui s'y retrouve tout à fait et qui impose dans votre code un else et une affectation inutiles (ou l'utilisation de l'opérateur ternaire).
Oui, je sais, il y mille façons de coder la même chose, qui "marche". Et certaines règles de style ne peuvent être que conventionnelles. Pourquoi ne pas violer les conventions ? Éternelle question, de goût pour les uns, de qualité pour les autres.
Il faut tenir compte du fait que mes remarques s'adressaient davantage à l'auteur du fil, qui se déclare lui-même débutant. Je pensais bien faire (je le pense encore).
-- Cordialement, Pascal
SAM
Le 22/11/10 18:21, Pascal a écrit :
Le 22/11/2010 17:38, Y.D. a écrit :
Ah ! Et que vaut !undefined ?
Bien sûr, un double transtypage !
Si c'est une question de style, plutôt que tester undefined je préférerai if (!("length" in lines))
bon .. ben .. moi .. je m'en tiens à du basique ... laborieux ... (sans trop me poser de question de quoi que ça c'est ... transtypage, array/tableau, object, collection ...)
<script type="text/javascript">
function ctrl(f) { var n, t = f.elements['total'], x = 0; f = f.elements['test[]']; if(typeof f != 'undefined') { n = f.length; if(n>1) while(n--) x += f[n].value*1; else x = f.value; } else alert('pas de champ à additionner'); t.value = x; return false; }
Si c'est une question de style, plutôt que tester undefined je préférerai
if (!("length" in lines))
bon .. ben .. moi .. je m'en tiens à du basique ... laborieux ...
(sans trop me poser de question de quoi que ça c'est ...
transtypage, array/tableau, object, collection ...)
<script type="text/javascript">
function ctrl(f) {
var n,
t = f.elements['total'],
x = 0;
f = f.elements['test[]'];
if(typeof f != 'undefined') {
n = f.length;
if(n>1) while(n--) x += f[n].value*1;
else x = f.value;
}
else alert('pas de champ à additionner');
t.value = x;
return false;
}
Si c'est une question de style, plutôt que tester undefined je préférerai if (!("length" in lines))
bon .. ben .. moi .. je m'en tiens à du basique ... laborieux ... (sans trop me poser de question de quoi que ça c'est ... transtypage, array/tableau, object, collection ...)
<script type="text/javascript">
function ctrl(f) { var n, t = f.elements['total'], x = 0; f = f.elements['test[]']; if(typeof f != 'undefined') { n = f.length; if(n>1) while(n--) x += f[n].value*1; else x = f.value; } else alert('pas de champ à additionner'); t.value = x; return false; }
function ctrl(f) { var n, t = f.elements['total'], x = 0; f = f.elements['test[]']; if(typeof f != 'undefined') { n = f.length; if(n>1) while(n--) x += f[n].value*1; else x = f.value; } else alert('pas de champ à additionner'); t.value = x; return false; }
Bonjour "Sam", Merci d'être venu aussi sur mon problème ! J'ai fait un mix des solutions proposées, mais effectivement le secret était de jouer sur le undefined, par typeof ou autre... Bonne journée, "Sam"
<script type="text/javascript">
function ctrl(f) {
var n,
t = f.elements['total'],
x = 0;
f = f.elements['test[]'];
if(typeof f != 'undefined') {
n = f.length;
if(n>1) while(n--) x += f[n].value*1;
else x = f.value;
}
else alert('pas de champ à additionner');
t.value = x;
return false;
}
Bonjour "Sam",
Merci d'être venu aussi sur mon problème !
J'ai fait un mix des solutions proposées, mais effectivement le secret était
de jouer sur le undefined, par typeof ou autre...
Bonne journée,
"Sam"
function ctrl(f) { var n, t = f.elements['total'], x = 0; f = f.elements['test[]']; if(typeof f != 'undefined') { n = f.length; if(n>1) while(n--) x += f[n].value*1; else x = f.value; } else alert('pas de champ à additionner'); t.value = x; return false; }
Bonjour "Sam", Merci d'être venu aussi sur mon problème ! J'ai fait un mix des solutions proposées, mais effectivement le secret était de jouer sur le undefined, par typeof ou autre... Bonne journée, "Sam"
SAM
Le 23/11/10 10:03, Sam Lion a écrit :
Merci d'être venu aussi sur mon problème !
Bon ... un peu à la fumée des cierges !
J'ai fait un mix des solutions proposées, mais effectivement le secret était de jouer sur le undefined, par typeof ou autre...
Les puristes diront qu'il faut *toujours* tester la validité de n'importe quelle variable(*) avant de la tripoter. M'enfin en php on doit bien faire pareil ? (même si @ permet qques facilités)
(*) variable déclarée ou représentant un objet qui peut être un élément du DOM ou comme ici un élément ou une collection d'éléments de form(ulaire).
-- Stéphane Moriaux avec/with iMac-intel
Le 23/11/10 10:03, Sam Lion a écrit :
Merci d'être venu aussi sur mon problème !
Bon ... un peu à la fumée des cierges !
J'ai fait un mix des solutions proposées, mais effectivement le secret
était de jouer sur le undefined, par typeof ou autre...
Les puristes diront qu'il faut *toujours* tester la validité de
n'importe quelle variable(*) avant de la tripoter.
M'enfin en php on doit bien faire pareil ?
(même si @ permet qques facilités)
(*) variable déclarée ou représentant un objet qui peut être
un élément du DOM ou comme ici un élément ou une collection
d'éléments de form(ulaire).
J'ai fait un mix des solutions proposées, mais effectivement le secret était de jouer sur le undefined, par typeof ou autre...
Les puristes diront qu'il faut *toujours* tester la validité de n'importe quelle variable(*) avant de la tripoter. M'enfin en php on doit bien faire pareil ? (même si @ permet qques facilités)
(*) variable déclarée ou représentant un objet qui peut être un élément du DOM ou comme ici un élément ou une collection d'éléments de form(ulaire).
-- Stéphane Moriaux avec/with iMac-intel
Sam Lion
Les puristes diront qu'il faut *toujours* tester la validité de n'importe quelle variable(*) avant de la tripoter. M'enfin en php on doit bien faire pareil ? (même si @ permet qques facilités)
Des contrôles de cohérence par des logiques getvalue/setvalue dans les fonctions oui, mais puriste non, et aller tester le type de chaque variable avant de l'utiliser...même pas en rêve :-) Sam
Les puristes diront qu'il faut *toujours* tester la validité de
n'importe quelle variable(*) avant de la tripoter.
M'enfin en php on doit bien faire pareil ?
(même si @ permet qques facilités)
Des contrôles de cohérence par des logiques getvalue/setvalue dans les
fonctions oui, mais puriste non, et aller tester le type de chaque variable
avant de l'utiliser...même pas en rêve :-)
Sam
Les puristes diront qu'il faut *toujours* tester la validité de n'importe quelle variable(*) avant de la tripoter. M'enfin en php on doit bien faire pareil ? (même si @ permet qques facilités)
Des contrôles de cohérence par des logiques getvalue/setvalue dans les fonctions oui, mais puriste non, et aller tester le type de chaque variable avant de l'utiliser...même pas en rêve :-) Sam
