acceder a un tableau de champ

Le 04/02/11 08:14, J-F Portala a écrit :

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.

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.

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

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.

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

Le 04/02/11 09:50, Pascal Poncet a écrit :

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

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.

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" <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> a écrit dans le message
de news: 4d4bad45$0$7712$ba4acef3@reader.news.orange.fr...

Le 04/02/11 08:14, J-F Portala a écrit :

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.

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.

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

Le 04/02/2011 10:45, J-F Portala a écrit :

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

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

Le 04/02/11 10:45, J-F Portala a écrit :

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é.

--
Stéphane Moriaux avec/with iMac-intel

merci de ces précisions

Jeff

On 04/02/11 11:34, SAM wrote:

parce que :
- 1) l'arbre des forms existe

Mais c'est du DOM ;)
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.