acceder a un tableau de champ
J-F Portala
j'ai dans un formulaire de multiples cases à cocher créées dynamiquement
avec PHP.
J'ai donc un id "tableau[]" dans la construction des champs.
Je voudrais limiter le nombre maximum de coches à 3 au moment de la
validation en javascript,
mais je ne sais pas comment accéder à ces champs.
Quelle est la syntaxe ou y a t il d'autres fonctions que getElementById("")
pour des tableaux.
Peut être qu'un multiselect serait plus facile à gérer.
Merci de votre aide
Jeff
SAM
> Bonjour,
>
> j'ai dans un formulaire de multiples cases � cocher cr��es dynamiquement
> avec PHP.
> J'ai donc un id "tableau[]" dans la construction des champs.
>
> validation en javascript,
> mais je ne sais pas comment acc�der � ces champs.
>
> Quelle est la syntaxe ou y a t il d'autres fonctions que getElementById("")
> pour des tableaux.
pour un formulaire on �vite d'utiliser les trucs DOM ...
> Peut �tre qu'un multiselect serait plus facile � g�rer.
Non, pas plus.
var f = document.forms['nom_du_form']; // ou autre syst�me
var t = f['tableau[]'],
n = f.length,
c = 0;
if(typeof n != 'undefined')
for(var i=0; i<n; i++)
if(t[i].checked) {
c++;
t[i].checked = c<4;
}
--
St�phane Moriaux avec/with iMac-intel
Pascal Poncet
> Bonjour,
Bonjour,
> J'ai donc un id "tableau[]" dans la construction des champs.
Attention, un identifiant commun à plusieurs balises, INPUT en
l'occurrence, ne doit pas être dans l'attribut ID mais NAME.
> Quelle est la syntaxe ou y a t il d'autres fonctions que getElementById("")
> pour des tableaux.
Elle est inadaptée dans ce cas, sinon elle s'appellerait
'getElementsById' (avec un 's') et pourrait renvoyer une collection
d'éléments.
Par contre, il existe 'getElementsByName' mais, comme le suggère SAM, il
est peut-être plus simple de passer par le DOM-0, avec :
- document.forms[name] pour accéder au formulaire ;
- document.forms[name].elements[name] pour accéder à un champ.
--
Cordialement,
Pascal
SAM
> Le 04/02/2011 08:14, J-F Portala a écrit :
>> Bonjour,
>
> Bonjour,
>
>> J'ai donc un id "tableau[]" dans la construction des champs.
>
> Attention, un identifiant commun à plusieurs balises, INPUT en
> l'occurrence, ne doit pas être dans l'attribut ID mais NAME.
J'ai même pas pensé à le préciser ... !
du moment qu'on veut les récupérer (par php ou autre) on est *obligé* de
les "nommer", non ?
> Par contre, il existe 'getElementsByName'
mais conmme ce n'est pas bien digéré par tous les navigateurs,
ne reste que :
> comme le suggère SAM, il
> est peut-être plus simple de passer par le DOM-0, avec :
> - document.forms[name] pour accéder au formulaire ;
Là, et s'il a bien un ID, on peut aussi faire
- document.getElementsById('id_du_form');
> - document.forms[name].elements[name] pour accéder à un champ.
comme l'abre des forms est systématiquement répertorié par les
navigateurs (en + du DOM) au chargement du fichier,
c'est le mieux,
le plus simple,
et comme ça pas besoin d'encombrer le html avec des ids inutiles.
mesCheckBoxes=document.getElementsById('id_du_form').elements['tableau[]'];
--
Stéphane Moriaux avec/with iMac-intel
J-F Portala
Cela fonctionne sans probleme. Il y avait juste n qui devait �tre �gal �
t.length au lieu de f.length.
Pourrais tu me dire pourquoi il faut �viter d'utiliser les "trucs DOM" dans
les formulaires?
Encore merci
J'avais aussi une question un peu plus g�n�rale sur la validation des
formulaires. Je vois 3 solutions:
- utiliser javascript directement en saisie (en filtrant certaines touches)
et en validation de formulaire avant l'envoi
- tout envoyer au serveur et valider en PHP (plus simple mais moins r�actif)
- utiliser ajax pour envoyer les champs au serveur pour validation sans
recharger la page
C'est peut �tre mon manque de pratique de javascript qui fait que je serais
tent� de valider en PHP.
Jeff
"SAM" <stephanemor...@wanadoo.fr.invalid> a �crit dans le message
de news: 4d4bad45$0$7712$ba4a...@reader.news.orange.fr...
Pascal Poncet
> J'avais aussi une question un peu plus générale sur la validation des
> formulaires. Je vois 3 solutions:
> - utiliser javascript directement en saisie (en filtrant certaines touches)
> et en validation de formulaire avant l'envoi
> - utiliser ajax pour envoyer les champs au serveur pour validation sans
> recharger la page
Ce sont les types de contrôle à effectuer qui guident ce choix, à mon avis.
Côté client, donc JavaScript, le plus classique est de contrôler la
saisie avant l'envoi des données.
Mais ça n'empêche pas un contrôle doublé côté serveur, puisque le
navigateur pourrait être paramétrer pour ne pas exécuter les scripts.
Le contrôle en cours de saisie doit être limité à quelques cas, vraiment
utiles, sinon ça peut vite devenir anti-ergonomique.
Je me souviens d'un site de petites annonces qui devait limiter le
nombre de caractères saisis dans le corps de l'annonce, car elle était
également publiée sur papier.
Dans ce cas, il était intéressant d'avoir, pendant la rédaction de
l'annonce, un compteur indiquant combien de caractères on pouvait encore
taper.
Quant aux requêtes asynchrones (alias Ajax), elles aussi doivent être
vraiment limitées.
Je pense qu'elles ne sont utiles que lorsqu'il s'agit de confronter la
saisie à une liste disponible uniquement côté serveur.
L'exemple type est celui du choix d'un identifiant lors d'une
inscription à un site web. Il est intéressant de prévenir au plus tôt
l'utilisateur que son choix est disponible ou pas.
Mais s'il s'agit d'aller chercher une liste d'une centaine d'éléments
qui, de plus, ne sont pas confidentiels, alors mieux vaut éviter Ajax.
Par exemple, les stations RATP ou SNCF sont envoyées directement dans le
HTML produit, c'est plus simple et finalement plus rapide.
--
Cordialement,
Pascal
SAM
> Bonjour et merci de ton aide rapide.
>
> Cela fonctionne sans probleme. Il y avait juste n qui devait �tre �gal �
> t.length au lieu de f.length.
Ha! c'est bien possible
c'�tait du jet direct l� ... :-/
> Pourrais tu me dire pourquoi il faut �viter d'utiliser les "trucs DOM" dans
> les formulaires?
parce que :
- 1) l'arbre des forms existe
- 2) normalement tout les �l�ments y sont joignables
- soit par leur index (dans les "elements" du form)
- soit directement par leur "name"
- 3) qques "dynamismes" (ajout d'event JS) y fonctionnent mieux
pour retrouver les b�b�s (IE principalement, mais pas que)
- 4) ancien et bien rod�
- 5) IE se m�lange entre ID et NAME
et que les tests par lui ne valent rien
- 6) que de toute la mani�re on a le droit qu'� un seul m�me ID
donc pas possible d'avoir 2 checkbox avec m�me ID (tableau[])
(m�me si des codeurs irr�fl�chis en php s'en moquent)
- 7) or donc ... pas de collection avec gEBI
> J'avais aussi une question un peu plus g�n�rale sur la validation des
> formulaires. Je vois 3 solutions:
> - utiliser javascript directement en saisie (en filtrant certaines touches)
Heu ... pas d'id�e sur cette question de touches
(sauf que c'est la mort)
et �a n'emp�che pas d'y repasser pour la pr�-validation compl�te
> et en validation de formulaire avant l'envoi
Oui, une *pr�* validation.
> - tout envoyer au serveur et valider en PHP (plus simple mais moins r�actif)
Non, on valide via JS � l'envoi *ET* on re-valide en PHP
> - utiliser ajax pour envoyer les champs au serveur pour validation sans
> recharger la page
int�r�t moyen - surcharge du serveur et de sa base de donn�e, non ? -
(sauf si le form fait 50 champs et 30 selects et x.mille boutons radio)
D'autant que ... finalement, � la r�flexion ... non, le client ne veut
pas valider ... alors � quoi �a a servi d'encombrer le serveur ?
(si ce n'est, ill�galement, recueillir des donn�es sur les visiteurs)
> C'est peut �tre mon manque de pratique de javascript qui fait que je serais
> tent� de valider en PHP.
Bon ...
il est bien plus que temps de pr�ciser et rappeler :
- le JavaScript n'est qu'une "b�quille"
- il ne sert qu'� faciliter la visite
comme, par exemple, �viter des AR serveur pour remplir un formulaire
qui revient pask'on a oubli� une case ou mis une date pour un t�l ...
- le PHP est le seul responsable de la bonne tenue du site
c'est lui qui v�rifie pour de vrai le formulaire
- le JS est sur le poste du visiteur, il peut fonctionner tr�s mal
et, en plus, il peut-�tre arr�t�.
J-F Portala
Jeff
Mickaël Wolff
> parce que :
> - 1) l'arbre des forms existe
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357
> - 3) qques "dynamismes" (ajout d'event JS) y fonctionnent mieux
> pour retrouver les bébés (IE principalement, mais pas que)
Tu peux expliciter s'il-te-plaît ? Ça m'intéresse.
> - 6) que de toute la manière on a le droit qu'à un seul même ID
> donc pas possible d'avoir 2 checkbox avec même ID (tableau[])
> (même si des codeurs irréfléchis en php s'en moquent)
Pas seulement. La plupart des systèmes de template sont ainsi conçus
dans le monde des frameworks Python.
> Non, on valide via JS à l'envoi *ET* on re-valide en PHP
J'appuye à 100%. On ne le répétera jamais assez, le client n'est pas
fiable pour ce genre d'opération car le script ne fonctionne pas en
environnement contrôlé par le développeur.
>> - utiliser ajax pour envoyer les champs au serveur pour validation sans
>> recharger la page
>
> intérêt moyen - surcharge du serveur et de sa base de donnée, non ? -
> (sauf si le form fait 50 champs et 30 selects et x.mille boutons radio)
> D'autant que ... finalement, à la réflexion ... non, le client ne veut
> pas valider ... alors à quoi ça a servi d'encombrer le serveur ?
> (si ce n'est, illégalement, recueillir des données sur les visiteurs)
Toutes les applications majeures font désormais ce type de
vérifications dynamiques, pour fournir l'autocomplétion, la vérification
à la volée de la disponibilité d'un identifiant, etc.
Quand je dis majeur, je parle de plate-formes telles que Facebook,
Google (instant search), Twitter, etc.
Ceci induit forcément un surcoût côté serveur, mais c'est le prix à
payer pour rendre les interfaces *d'applications* plus réactives. Ceci
dit, si on fait bien les choses, on peut se débrouiller pour que les
systèmes de cache soient mis à contribution (du navigateur aux serveurs).
> - le JS est sur le poste du visiteur, il peut fonctionner très mal
> et, en plus, il peut-être arrêté.
Je rajouterai aussi que l'absence de validation côté serveur ouvre la
porte à tout sorte d'attaques via l'usage d'un outil comme cURL, en
forgeant une requête qui sera acceptée par l'application.
Pour être concrêt, l'utilisation typique de ce genre de trous de
sécurité est de créer un compte administrateur, car le serveur ne
vérifie pas que le client web a bien le droit de créer un tel utilisateur.