8792 sujets

Développement web côté serveur, CMS

Pages :
Bonjour,

J'ai des formulaires plus ou moins compliqués, avec à la fois des liens en GET et des boutons en POST.

Si, au lieu de cliquer sur un bouton ou un lien, l'utilisateur utilise les touches entrée ou retour, je ne sais pas trop quel lien ou bouton est activé, mais le résultat est souvent un bug...

1) Y a-t-il moyen d'assigner ces touches à un bouton ou un lien (accesskey ne convient pas, il me semble).

2) De savoir logiquement quel bouton ou lien est activé (le premier qui apparaît dans le code html ?)

3) de tester et corriger ou envoyer un msg d'erreur ?

MERCI d'avance.
Modifié par boteha (16 Apr 2006 - 11:48)
Bonjour,
La touche entrée provoque l'envoi du formulaire sans envoyer le contenu relatif à un bouton submit.

Je m'explique. Si tu as ça :

<form action="page.php" method="post">
<p><label for="champ">Blablabla : </label>
<input type="text" id="champ" name="champ" />
<input type="submit" name="submit" value="submit1" />
<input type="submit" name="submit" value="submit2" />
</p></form>


Si tu soumets le formulaire en cliquant sur un des deux boutons, tu peux normalement savoir lequel a été cliqué en vérifiant ici si $_POST['submit'] contient "submit1" ou "submit2".

Lorsque tu appuies sur entrée pour valider, $_POST['submit'] ne contient ni l'un ni l'autre.

Je sais pas si c'est clair ...
Merci de vos réponses.

1) Pour une démonstration du bug, voir
www.touslescables.com
Tu ouvres un menu, tu affiches une liste, tu coche une case checkbox, tu fais entrée ou retour...

D'ailleurs, si tu ne coches rien, il ne se passe rien, intéressant....

2) Si je comprends QuentinC, aucune valeur du Submit n'est transmise.
Les autres variables POST sont-elles transmises ?
Facile de faire un test...
Avec un print_r ($_POST), je trouve effectivement les variables POST, sauf le submit.

Cela te paraît-il normal ?

L'utilisateur qui utilise les touches entrée ou retour serait alors assez facile à contrôler avec juste quelque chose du genre :

if (isSet ($_POST) && !isSet ($_POST['nom_du_submit']))
echo "Veuillez cliquer sur un bouton, SVP !"
...réaffichage de la page...

Qu'en pensez-vous ?
boteha a écrit :

2) Si je comprends QuentinC, aucune valeur du Submit n'est transmise.
Les autres variables POST sont-elles transmises ?
Facile de faire un test...
Avec un print_r ($_POST), je trouve effectivement les variables POST, sauf le submit.

Cela te paraît-il normal ?

Oui, c'est tout à fait normal. C'est bien l'exemple qui illustre ce que j'ai dit tout à l'heure.

boteha a écrit :
L'utilisateur qui utilise les touches entr
ée ou retour serait alors assez facile à contrôler avec juste quelque chose du genre :

if (isSet ($_POST) && !isSet ($_POST['nom_du_submit']))
echo "Veuillez cliquer sur un bouton, SVP !"
...réaffichage de la page...

Qu'en pensez-vous ?


Oui pour le fragment de code pour tester le bouton appuyé / la touche entrée, mais noooooooon (et j'insiste) sur le "veuillez cliquer sur un bouton".
Si tu me fais ça, ton site, je l'oublie dans la minute qui suit. Tu dois absolument prévoir une action par défaut.
Merci de ta réponse.

Facile de prévoir une action par défaut, il y a généralement une action SUBMIT principale, elle est d'ailleurs marquée comme telle avec un gros bouton SUBMIT suivi d'un > et je pense que d'instinct les utilisateurs utilisent retour ou entrée sur ce bouton.

Donc :
if (isSet ($_POST) && !isSet ($_POST['nom_du_submit']))
$choix = 'Action principale';

Cela dit, je te trouve excessif, car il y peut y avoir sur une page à la fois des submit de recherche avec touches OK et (par exemple) un submit d'ajout au panier.
Beaucoup d'utisateurs ont l'habitude de faire entrée pour un bouton OK et ils ne comprendraient pas forcément qu'ils se retouvent avec un produit dans leur panier ou un msg d'erreur comme quoi ils n'ont sélectionné aucun produit pour leur panier.
Si tu as 5 minutes, va voir touslescables.com, ouvre un menu, affiche une liste de produit et dis-moi quel alias je prends pour entrée ou retour...

Merci d'avance.
boteha a écrit :
Cela dit, je te trouve excessif, car il y peut y avoir sur une page à la fois des submit de recherche avec touches OK et (par exemple) un submit d'ajout au panier.

Je vois pas où est le problème : entre une recherche et un formulaire commercial, il y a une grande différence. De ce fait, ils doivent être facilement distingables.
Enfin je pense que ça devrait être des formulaires différents.

Ne me dis pas que tu utilises le même champ input pour une recherche de produit et pour un ajout ?

boteha a écrit :
Beaucoup d'utisateurs ont l'habitude de faire entrée pour un bouton OK et ils ne comprendraient pas forcément qu'ils se retouvent avec un produit dans leur panier ou un msg d'erreur comme quoi ils n'ont sélectionné aucun produit pour leur panier.
Si tu as 5 minutes, va voir touslescables.com, ouvre un menu, affiche une liste de produit et dis-moi quel alias je prends pour entrée ou retour...


Heu ? Là je comprends plus bien, et encore moins avec ton histoire d'alias.

Déjà de un, c'est quoi pour toi "retour" ? Le bouton Précédent du navigateur ?
merci de ton intérêt.

Retour = retour charriot du clavier, la touche retour du navigateur ne soumet pas de formulaire, donc pas de problème avec ça.

Quand tu as plusieurs boutons submit sur la même page, comment veux-tu définir une valeur par défaut à la touche retour ?

Donc, tu envoies un message en demandant à l'utilisateur de chosir son submit, je ne vois pas d'autre possibilité.
boteha a écrit :
Quand tu as plusieurs boutons submit sur la même page, comment veux-tu définir une valeur par défaut à la touche retour ?

Donc, tu envoies un message en demandant à l'utilisateur de chosir son submit, je ne vois pas d'autre possibilité.


Par principe, on veut que ce soit le premier.
Regarde par exemple, la page où je suis actuellement en train d'écrire ce post.
Si j'appuie sur Entrée alors que je ne me trouve pas sur le bouton Envoyer, c'est bien lui qui sera pris en compte, pas le bouton Prévisualiser qui vient ensuite dans le code.
Merci de ton intérêt.

C'est le premier, mais je ne pense pas que les navigateurs gèrent tous pareil.
De toutes façons, la valeur du submit n'est pas transmise, ce qui en l'occurence met mon script en agonie.

Je ne vois pas d'autres solutions que :
si un seul submit dans la page, tu considères que l'utilisateur a choisi ce bouton.
si plusieurs submit, tu n'es pas devin, et tu lui demandes quel bouton il a voulu choisir.
Ou bien alors ... une idée javascript.

Tu utilises une variable globale initialisée à false.
Sur les onclick des butons, tu la mets à true.
Dans le onsubmit du form, si la variable est à true, tu soumets sans discuter, et si elle est à false, tu ne soumets pas mais tu positionnes le focus sur le premier bouton.
Si on appuie sur enter sur le bouton, ça déclenche le onclick normalement donc pas de soucis.
Merci de ton idée, elle est bonne.

Néanmoins, je n'utilise javascript que pour des petites fonctions de confort, dans lesquelles la non-exécution du sript ne génère pas de bug, car trop d'utilisateurs désactivent javascript et trop de navigateurs le gèrent plus ou moins mal.

Comme ici il s'agit justement d'éviter un bug, je me fie à PHP, le nombre de pages où j'ai plusieurs boutons est limité, le contrôle très facile, l'exécution fort rapide et en plus les données entrées par l'utilisateur sont conservées, il n'a juste qu'à cliquer sur son bouton, pas méchant.
Oui, tu as raison. Mais rien ne t'empêche d'utiliser ce javascript et. Au moins, ça n'affiche pas un message désagréable à ceux qui l'ont activé.
Je me permets de relancer ce sujet parce que quelquechose me chagrinne ...

Je dispose d'un formulaire, rien de très compliquer mais qui offre plusieurs fonctionnalités, recherche, mise à jour et suppression, chacune mise sous la forme d'un input-image avec une accesskey.

J'ai donc mis une petite sécurité js comme dit plus pour le cas où l'utilisateur voudrait faire entrée.

A coté de mes accesskey, comme elle se contente de donner le focus sous IE, j'ai ajouter un
onfocus="variablePourContrerLaToucheEntree = true; click();"

Le problème est que lorsque j'utilise les accesskey, celui-ci réagit comme si je faisais entrée, à savoir il passe par
<form onsubmit="if(variablePourContrerLaToucheEntree == false) renvoi sur la recherche" >

avant de passer dans le
<input type="image" onclick="execution de l'action" />


Donc est-ce normal ?
(Est-ce que je me suis bien fait comprendre Smiley smile ?)

Pour info, l'appli tourne sous IE 6. (Il s'agit d'une utilisation interne donc je n'ai pas à me soucier d'autres navigateurs)
Modifié par Csk (30 Aug 2006 - 15:37)
Bonjour,

Excuse, je ne suis pas assez compétent en javascript pour te répondre.

Je me suis débrouillé avec un script PHP côté serveur.

Cela dit, la suite de la discussion m'intéresse.
En fait je m'interroge surtout sur le fonctionnement du tabindex, comme il est considérer et ce qu'il provoque (plus particulièrement sous IE).

Je travaille avec Struts (Java), et je ne veux pas passer par le serveur pour résoudre le problème. Donc il ne reste que javascript, mais quel merdier Smiley smile !

Edit : Oups je me suis rendu compte que dans mon premier poste j'ai confuser tabindex et accesskey ... (corrigé)
Modifié par Csk (30 Aug 2006 - 15:41)
Bon courage...

Accesskey, aucun navigateur ne le gère correctement, sauf ICab pour Macintosh...
Je travaille dans un environnement propriétaire donc je connais le browser où ca va tourner donc pas de problèmes pour moi Smiley smile .

Sinon j'ai vérifier sur la-grange.net, et mon accesskey ne fait que donner le focus, donc je ne vois pas pourquoi ca déconne ... !? J'ai du faire une couille dans mon js Smiley decu .
Pages :