Commentaires sur : Concevoir un formulaire HTML qui tient la route

Par : Clément

Clément — Thu, 30 Aug 2012 07:47:33 +0000

Attention,
il préférable de privilégier les requêtes en POST car la longueur de l’URL peut être limitée dans le cas d’un requête en GET. Non pas par une spécification mais par les navigateurs.

Plus de détails :
http://www.boutell.com/newfaq/misc/urllength.html

Par : Capse

Capse — Tue, 12 Apr 2011 10:38:54 +0000

Travaillant pour un grand site de voyage, une des raisons simples pour laquelle les formulaires sont validé en javascript, est tout simplement le tracking du clic :/

Il faut savoir que TOUT clic est tracké, même ceux qui ne servent a rien. Du coup oui la compatibilité entre navigateur est très dur à gérer pour les développeur qui s’en occupe.

!Attention! je ne dit pas que c’est normal, si ça chie c’est le dev qui a déconné, simplement je défend le faite que au vue des spécifications demandé ça devient très compliqué et ont ce retrouve facilement avec des quack :)

Par : musicuser

musicuser — Sun, 04 Apr 2010 21:14:09 +0000

Pour la création des formulaires, il reste aussi (pour gagner du temps) l’option de passer par des applications permettant la création rapide de formulaires.

En voici une proposée par http://www.atomestudio.com/ avec la solution FORMALLIN

Formallin est un assistant graphique offrant la possibilité aux non-développeurs de créer très facilement des formulaires multilingues.
Le principe : Suite à la création d’un formulaire, un fichier .php est généré. Ce seul fichier contient tout code nécessaire à :
l’exploitation multilingue de votre formulaire
les vérifications des champs côté client
les vérifications des champs côté serveur
Ce fichier fonctionne de manière autonome ou peut être intégré dans une page de votre site par une iframe.

Par : Grunt

Grunt — Fri, 02 Oct 2009 08:07:24 +0000

"je suis passé de PC à Mac" Je suppose qu'il fallait comprendre "de Windows à Mac", étant donné le contexte. Merci de ne pas répandre la confusion "PC = Windows", il y a des utilisateurs de PC qui ne sont pas sous Windows. Et qui font eux aussi partie des minorités emmerdées par les sites "conçus pour Windows" ;+)

Par : Pierre Bertet

Pierre Bertet — Sun, 19 Apr 2009 17:17:16 +0000

Veyrat :
Il s’agit de programmation côté serveur, ce qui sort largement du cadre de cet article ;-)

Par : Veyrat

Veyrat — Sun, 19 Apr 2009 15:25:05 +0000

Bonjour
je cherche à créer un formulaire associant des champs (nom, prénom, email, tel, adresse, ville, code postal, pays, choix de dimensions), des boutons radio permettant d’identifier une couleur, la possibilité de joindre un fichier attaché, faire générer un numéro aléatoire de composé de la date (année, mois, jour), d’un numéro de 7 chiffres (aléatoire) et le tout invisible par la personne qui enverra le formulaire mais visible sur l’email que je recevrai.
et , en cliquant sur un bouton « envoyé », que toutes ces informations me parviennent par mail (y compris le fichier attaché)
pouvez vous m’aider?
Cordialement

Par : Les bases pour un formulaire HTML | Kerblog

Les bases pour un formulaire HTML | Kerblog — Mon, 09 Feb 2009 23:35:30 +0000

[…] site des Intégristes nous gratifie d’un très bon article présentant la base pour réaliser convenablement un formulaire HTML, tant en terme de codage qu’en terme d’ergonomie (tests de messages d’erreur). […]

Par : Hubert

Hubert — Wed, 04 Feb 2009 12:50:12 +0000

Validation js côté client, en plus d’être plus ergonomique, nous fait économiser de la bande passante.
Je rajouterai que quelque soit la validation côté client en javascript, la même validation doit exister côté serveur, pour une question d’accessibilité mais aussi pour se prévenir d’éventuels bugs.
C’est l’exemple parfait de la notion de « javascript non-intrusif ».

Par : Felipe

Felipe — Wed, 04 Feb 2009 11:47:32 +0000

Très bon article, je rajouterai 2 précisions:

* l’attribut for des va toujours de pair avec l’id de l’élément de formulaire correspondant
* c’est beaucoup mieux si les messages d’erreur s’affichent à proximité immédiate de l’endroit où il y a l’erreur (pas en début de formulaire) et il ne faut pas se contenter de passer le texte en rouge: tout le monde (ou tous les matériels) ne voit pas le rouge! (mobile N/B, non-voyant, …). Et si l’erreur est explicite alors c’est le nirvana :)

Par : Bertrand Germain

Bertrand Germain — Wed, 04 Feb 2009 10:30:07 +0000

Excellent billet, néanmoins j’aimerais rajouter quelque chose sur les validations en javascript. Il est très important de prendre soin de la validation en javascript car il peut très vite devenir déroutant pour l’utilisateur.

Une approche comme celle de remember the milk est par exemple plutôt mauvaise car l’utilisateur subit des messages d’erreur en cours de saisie du champ. Le moment d’intention est mauvais ici, il vaut mieux attendre que l’utilisateur quitte le champ avant de le valider en général.

Par ailleurs le lieu d’intention est tout aussi important, de manière générale, il est préférable de mettre le message d’erreur avant le champ non validé, cela permet au gens utilisant des aides techniques d’être avertis avant de retomber sur le champ à corriger plutôt que de le passer et devoir revenir en arrière pour remplir le champ mal rempli… ou bien éventuellement il est possible de mettre un label sur le message d’erreur qui renvoi le focus sur le champ invalidé, à ce moment là la lieu d’intention n’est pas aussi important.