Discussion :

[jpguiche]

Bonjour,

Je cherche une référence, ou un example de "bonne pratique" pour réaliser une forme avec Annuler / Valider.
Je peux le faire de plusieurs façons :
- avec 2 formes, chacune a son onsubmit et donc on peut avoir une action javascript spécifique à chaque bouton + une action php aussi spécifique
Inconvénient : on ne peut pas positionner facilement le "Annuler" n'importe où par rapport au "Valider" (pas pratique)
- avec 1 forme et une action onclick pour le Annuler, et l'action onsubmit pour le Valider.
Inconvénient : si on appuie avec Entrée sur Annuler ça ne marche pas.

Quelle est la "bonne pratique" recommandée dans ce cas de figure qui est fréquent sur le web ?

Merci.

[bigboomshakala]

http://javascript.developpez.com/faq...bjs#BoutSubmit

[TheRedLed]

Bonjour,

Je cherche une référence, ou un example de "bonne pratique" pour réaliser une forme avec Annuler / Valider.
Je peux le faire de plusieurs façons :
- avec 2 formes, chacune a son onsubmit et donc on peut avoir une action javascript spécifique à chaque bouton + une action php aussi spécifique
Inconvénient : on ne peut pas positionner facilement le "Annuler" n'importe où par rapport au "Valider" (pas pratique)
- avec 1 forme et une action onclick pour le Annuler, et l'action onsubmit pour le Valider.
Inconvénient : si on appuie avec Entrée sur Annuler ça ne marche pas.

Quelle est la "bonne pratique" recommandée dans ce cas de figure qui est fréquent sur le web ?

Merci.

En fait la "bonne pratique" serait surtout ne de pas utiliser de Javascript

Tu perds toute l'accessibilité, un certain nombre de fonctionnalités du navigateur, et autres, tout en complexifiant le codage...

Le mieux, niveau bonne pratique, ce serait :
- un bouton submit classique, dans un formulaire classique
- bouton annuler : tu n'as pas besoin de soumettre le formulaire puisque tu veux juste retourner à la page précédente (si j'ai bien compris ?). Donc tu peux en faire un lien tout bête (à styler comme un bouton au besoin).

A+
B.

[flo850]

En fait la "bonne pratique" serait surtout ne de pas utiliser de Javascript

Tu perds toute l'accessibilité, un certain nombre de fonctionnalités du navigateur, et autres, tout en complexifiant le codage...

Le mieux, niveau bonne pratique, ce serait :
- un bouton submit classique, dans un formulaire classique
- bouton annuler : tu n'as pas besoin de soumettre le formulaire puisque tu veux juste retourner à la page précédente (si j'ai bien compris ?). Donc tu peux en faire un lien tout bête (à styler comme un bouton au besoin).

A+
B.

Je ne peux que confirmer ton message.

Même si il peut être tentant de faire le bouton "annuler" en javascript, le faire sous forme d'un lien n'a que des avantages en terme d'accessibilité, d'ergonomie ou de fiabilisation. Un lien fonctionnera toujours, alors qu'une fonction js peut déconner si d'autres morceaux de code de la page ont des erreurs

Le javascript, dans la mesure du possible, ne doit apporter qu'un enrichissement de la page, pas gérer les fonctions essentielles.

Par exemple, tu fais ton "bouton" annuler sous forme de lien et tu ajoutes, en javascript, une demande de confirmation pour annuler la saisie.

[E.Bzz]

Bonjour,
il ne s'agit pas là de "bonnes pratiques", mais de "points de vue".

Aucun n'étant meilleur que l'autre, tout dépendant du contexte (ne serait-ce qu'internet/intranet).

Pour ma part (de mon point de vue, quoi) une "bonne pratique" serait de ne pas prévoir de bouton "Annuler"
Car ça ne sert à rien !

On "annule" pas un formulaire, on va sur une autre page (ou on referme son nav). Et dans l'histoire, la fonction essentielle me semble plus être la soumission du formulaire et non un moyen supplémentaire, même si plus esthétique, de changer de page par rapport au systèmes déjà prévu (les boutons du nav, le menu de l'appli etc.)

Dans ce sens un lien serait la meilleure solution (mais inutile de le travestir en bouton ou autre) sauf qu'il serait certainement redondant, donc superflu (et si en plus on y ajoute une confirmation en Javascript, ça devient absurde, non ?).

Par contre, pour prévoir dynamiquement l'action de boutons d'un formulaire (et bien au-delà des seuls 2 choix envisagés), une des solution à privilégier est celle de la FAQ.
Bien sûr s'il y a une erreur le code plante
N'est-ce pas le cas dans la majorité des cas, quelque soit la techno ?

Mais de là à dire qu'utiliser une fonction Javascript par rapport à un <a href> fait perdre des fonctionnalités ...
Il suffit d'essayer de réaliser une appli web sans utiliser Javascript pour remettre en cause le postulat ...

Tiens, c'est marrant ça : en remplissant le formulaire qui me permet de poster cette réponse, je constate qu'il n'y a pas de bouton "Annuler"

A+

[pataluc]

Pour ma part (de mon point de vue, quoi) une "bonne pratique" serait de ne pas prévoir de bouton "Annuler"
Car ça ne sert à rien !

je plussoie fortement.

Luc

[skeye]

Bonjour,
il ne s'agit pas là de "bonnes pratiques", mais de "points de vue".

C'est ton point de vue

Aucun n'étant meilleur que l'autre, tout dépendant du contexte (ne serait-ce qu'internet/intranet).

On est d'accord. Sans plus de précisions, on prendra donc le cas général, i.e. "site destiné à être utilisé par le grand public".

Mais de là à dire qu'utiliser une fonction Javascript par rapport à un <a href> fait perdre des fonctionnalités .

C'est le cas dans de nombreux cas de figure.
Sans parler des bugs éventuels du javascript sur tel ou tel navigateur, de nombreuses personnes choisissent de désactiver javascript dans leur navigateur, et d'autres n'ont pas le choix, cette technologie n'étant tout simplement pas supportée par les navigateurs à leur disposition.
Ne pas utiliser le javascript lorsqu'on peut fournir exactement le même service en s'en passant et avec peu d'efforts devrait bel et bien figurer en bonne place dans les "bonnes pratiques" de référence pour tout développeur web qui se respecte.

[skeye]

je plussoie fortement.

Luc

Tout dépend là aussi du contexte, amha. Il cherche peut-être à fournir une interface proche de ce que font des programmes desktop classiques, auquel cas il est difficile de ne pas conserver cette convention du bouton "annuler" pour revenir sur l'écran précédent.

[E.Bzz]

On est d'accord. Sans plus de précisions, on prendra donc le cas général, i.e. "site destiné à être utilisé par le grand public".

Ben non : sans plus de précisions, on ne pourra pas préconiser de solution "préférable" ...
Juste donner les solutions possibles

Ne pas utiliser le javascript lorsqu'on peut fournir exactement le même service en s'en passant et avec peu d'efforts devrait bel et bien figurer en bonne place dans les "bonnes pratiques" de référence pour tout développeur web qui se respecte.

N'est-ce pas ce que j'ai dit ?
Mais en plus radical : ce "service" existe déjà il est donc inutile de le rajouter quelque soit le moyen.

A+

[flo850]

Bonjour,
il ne s'agit pas là de "bonnes pratiques", mais de "points de vue".

Il s'agit d'un besoin exprimé ( un bouton d'annulation en plus du bouton validation)

Aucun n'étant meilleur que l'autre, tout dépendant du contexte (ne serait-ce qu'internet/intranet).

Pour ma part (de mon point de vue, quoi) une "bonne pratique" serait de ne pas prévoir de bouton "Annuler"
Car ça ne sert à rien !

joli. Tu fais de ton utilisation d'un forum la généralité de l'utilisation des formulaires

On "annule" pas un formulaire, on va sur une autre page (ou on referme son nav).

d'ou l'intéret du lien qui permet justement d'aller sur une autre page.
Quand à refermer son navigateur parce qu'on a pas toutes les données ou qu'on veut en finir la saisie plus tard, je ne vois pas le rapport.

Et dans l'histoire, la fonction essentielle me semble plus être la soumission du formulaire et non un moyen supplémentaire, même si plus esthétique, de changer de page par rapport au systèmes déjà prévu (les boutons du nav, le menu de l'appli etc.)

les boutons de nav sont inutiles dès qu'on parle de formulaire en plusieurs étapes.
Les menus de l'applis, comme tu le dis, ça dépend du contexte.

Dans ce sens un lien serait la meilleure solution (mais inutile de le travestir en bouton ou autre) sauf qu'il serait certainement redondant, donc superflu (et si en plus on y ajoute une confirmation en Javascript, ça devient absurde, non ?).

Donc le lien répond à la question. la confirmation peut avoir un sens dans certains cas. Comme tu le dis, c'est à adapter au contexte

Par contre, pour prévoir dynamiquement l'action de boutons d'un formulaire (et bien au-delà des seuls 2 choix envisagés), une des solution à privilégier est celle de la FAQ.

oui bien sur
et j'ajouterai que pour centrer du texte, il vaut mieux arreter d'utiliser la balise center. Ca n'a rien à voir, mais c'est vrai

Bien sûr s'il y a une erreur le code plante
N'est-ce pas le cas dans la majorité des cas, quelque soit la techno ?

Ce n'est pas le cas de la solution que je conseille

Mais de là à dire qu'utiliser une fonction Javascript par rapport à un <a href> fait perdre des fonctionnalités ...

ben si , comme par exemple, quand le js plante, ou qu'il n'y a pas de js ( lecteur d'écran par exemple)

Il suffit d'essayer de réaliser une appli web sans utiliser Javascript pour remettre en cause le postulat ...

C'est pas parceque c'est plus compliqué que c'est impossible.
Bien sur facebook , sans javascript c'est impossible, mais dans la majorité des cas, une alternative est possible, a coup de js qui enrichit le contenu en fonction du disponible.

Tiens, c'est marrant ça : en remplissant le formulaire qui me permet de poster cette réponse, je constate qu'il n'y a pas de bouton "Annuler"

A+

Peut être qu'il existe des formulaires qui sont un poil plus complexes que celui qui permet d'envoyer une réponse hâtive sur un forum ? emission de bon de commande, édition de fiche agent, gestion de planning


Pour résumer, la question posé par jpguiche est inutile
Si il avait fallu y répondre intelligemment, il faut utiliser un lien, mais quand même , tu lui conseilles la FAQ
Enfin ça dépend du contexte, mais non, finalement, c'est toujours la FAQ

[E.Bzz]

Et si on laissait jpguiche nous en dire plus avant d'essayer d'aller plus loin ?

Les "peut-être" sont très loin de faire partie des bonnes pratiques pour un développeur

A+

[flo850]

Et si on laissait jpguiche nous en dire plus avant d'essayer d'aller plus loin ?

Les "peut-être" sont très loin de faire partie des bonnes pratiques pour un développeur

A+

Je ne vois pas un seul cas pour lequel la réponse de la FAQ est la meilleure pratique pour ajouter un bouton d'annulation d'un formulaire.

Edit : une FAQ peut évoluer pour prendre en compte l'évolution des pratiques. si on commence à la considérer comme un livre sacré, figé, elle ne sert à rien. Sans parler de la révolution qui arrive avec HTML5, qui va vraisemblablement avoir de gros impacts

[TheRedLed]

Bonjour,
il ne s'agit pas là de "bonnes pratiques", mais de "points de vue".

Aucun n'étant meilleur que l'autre, tout dépendant du contexte (ne serait-ce qu'internet/intranet).

Je pense que si.

Pour ma part (de mon point de vue, quoi) une "bonne pratique" serait de ne pas prévoir de bouton "Annuler"
Car ça ne sert à rien !

Même si je suis d'accord avec ça, c'est une bonne pratique d'ergonomie, pas de programmation...
A la limite la bonne pratique de programmeur serait de convaincre le chef de projet

Dans ce sens un lien serait la meilleure solution (mais inutile de le travestir en bouton ou autre) sauf qu'il serait certainement redondant, donc superflu (et si en plus on y ajoute une confirmation en Javascript, ça devient absurde, non ?).

Je ne comprends pas, redondant avec quoi ?

A noter que puisque le bouton apporte une fonctionnalité qui ne semble pas essentielle, ça me choquerait pas sinon qu'il soit fait avec un <button> + javascript, ça évite de styler le bouton en CSS, ça implique un JS minime, et ça ne pose pas trop de pb...
Ca ce serait la "bonne pratique" de l'homme pressé...

Par contre, pour prévoir dynamiquement l'action de boutons d'un formulaire (et bien au-delà des seuls 2 choix envisagés), une des solution à privilégier est celle de la FAQ.

Si par "dynamiquement" tu veux dire "en Javascript" je suis complètement d'accord avec toi Mais ça n'a pas grand sens...

Mais de là à dire qu'utiliser une fonction Javascript par rapport à un <a href> fait perdre des fonctionnalités ...
Il suffit d'essayer de réaliser une appli web sans utiliser Javascript pour remettre en cause le postulat ...

Oui ça fait perdre des fonctionnalités :
- la validation avec la touche entrée sur certains navigateurs marchera mal.
- puisqu'on soumet le form en POST en faisant annuler, la page vers laquelle on va ne pourra plus être rechargée avec F5 ("voulez-vous réenvoyer les données" etc).
- dans le cas de tests automatisés, un robot ne pourra pas soumettre le formulaire (il faudrait qu'il interprète le JS).

Par ex.


Cordialement,
B.

[skeye]

Ben non : sans plus de précisions, on ne pourra pas préconiser de solution "préférable" ...

Je ne suis absolument pas d'accord. En l'absence de précisions, on ne peut que préconiser la solution qui fonctionnera dans tous les cas, puisqu'elle existe.

N'est-ce pas ce que j'ai dit ?
Mais en plus radical : ce "service" existe déjà il est donc inutile de le rajouter quelque soit le moyen.

Cette fois c'est ton tour de prendre parti pour une solution sans connaitre les détails du problème...

[guussss]

bah, de toute façon, entre ça

<input type="submit" onclick="window.location.href=mon_url_précédente" />

et ça

<a href="mon_url_precedente" title="annuler" >Annuler</a>

Je pense que le choix est vite vu

ça me parait évident que si une solution sans javascript existe, il faut l'utiliser en priorité

[TheRedLed]

Par contre, pour prévoir dynamiquement l'action de boutons d'un formulaire (et bien au-delà des seuls 2 choix envisagés), une des solution à privilégier est celle de la FAQ.

Je voudrais revenir sur ça, je crois que j'ai compris, par "dynamiquement" tu veux dire "avec plusieurs bouton submits" ?

Si c'est ça on peut aussi donner des attributs name différents à chacun de ces boutons, et les différencier ensuite sur un script unique côté serveur.

Et c'est beaucoup plus simple que du Javascript

[jpguiche]

Merci pour vos nombreuses réactions. Quelques réponses :
1) utiliser un lien pour Annuler :
Pas idéal pour moi car je veux aller sur 1 page qui est accédée par ailleurs par un post avec des paramètres, donc je préfère y retourner avec un post et les paramètres en question.
2) je ne suis pas encore très expert : est-ce que le bouton retour du navigateur appelerait la page précédente avec les mêmes paramètres que cela a été fait dernièrement (que ce soit en get ou en post) ?
3) je suis d'accord pour minimiser les boutons de type "Annuler" mais il y a des cas où ça me semble utile notamment s'il faut retourner à une page qui n'est pas directement la précédente.

JP

[TheRedLed]

Merci pour vos nombreuses réactions. Quelques réponses :
1) utiliser un lien pour Annuler :
Pas idéal pour moi car je veux aller sur 1 page qui est accédée par ailleurs par un post avec des paramètres, donc je préfère y retourner avec un post et les paramètres en question.

Pourquoi on y accède avec un post ?

2) je ne suis pas encore très expert : est-ce que le bouton retour du navigateur appelerait la page précédente avec les mêmes paramètres que cela a été fait dernièrement (que ce soit en get ou en post) ?

GET oui (ça fait partie de l'url), POST le navigateur va demander à l'utilisateur si il veut rebalancer les paramètres.

En fait il faut bien piger la différence entre GET et POST :
- on utilise GET (paramètre dans l'url) si l'accès à la page ne change pas l'état de l'application (exemple : consultation d'une liste de livres).
- on utilise POST (rien dans l'url) si on veut changer l'état de l'application (ex : ajout/modification d'un livre)

Donc si la page cible du bouton "annuler" ne change pas l'état de l'appli, on doit y accéder en GET.

[jpguiche]

Ce que tu me dis sur la logique d'utilisation de GET et POST me plait bien. Je m'aperçois que ce n'est pas comme ça que je les ai utilisés puisqu'en fait j'ai eu tendance à privilégier POST souvent pour des accès qui ne changent pas l'état sur le serveur simplement pour ne pas qu'on voit affichés les paramètres en clair dans l'url. Penses-tu que ce n'est pas une bonne raison pour utiliser POST ? Peut-être la seule exception à ta règle serait si on a un mot de passe (ou quelque code secret) en paramètre ?

[flo850]

Ce n'est effectivement pas une bonne raison pour utiliser post
Un bon exemple est que tu ne peux pas faire un lien direct vers cette page, ni de favoris

Ensuite, avec un peu de réécriture d'url tu peux avoir des URL sympa et lisibles, chose impossible avec du POST


pour le mot de passe, si tu l'envoi, c'est pour t'identifier , donc tu changes bien l'état sur le serveur ,non ? Idem si tu envoi un mot de passe pour créer un compte, changer un mot de passe, valider une étape critique : tu changes la perception que le serveur à de toi ( tu passe de non autorisé à autorisé )