SELFHTML/Aides à la navigation HTML/XHML Formulaires |
Définir des formulaires |
|
Généralités sur les formulaires |
|
HTML donne la possibilité d'établir des formulaires grâce à certaines commandes. Dans des formulaires l'utilisateur peut compléter des champs de saisie, dans des champs texte entrer plusieurs ligne de texte, faire des choix dans des listes et cliquer sur des boutons. Quand le formulaire est rempli complètement L'utilisateur peut cliquer sur un bouton pour envoyer le formulaire.
Pour cela mentionnez lors de l'établissement d'un formulaire ce qui doit se passer avec les données du formulaire rempli. Vous pouvez vous faire envoyer les données par courrier électronique ou les faire traiter par un programme CGI sur l'ordinateur serveur.
Des formulaires peuvent avoir de multiples fonctions. Ainsi on les emploie par exemple:
Un fabricant de logiciels pourrait par exemple mettre un formulaire à disposition dans lequel l'utilisateur pourrait indiquer quels produits de la firme il a en sa possession, comment il a connu les produits, quel métier il exerce, sur quel type d'ordinateur le logiciel tourne chez lui etc. De cette façon il pourrait obtenir un écho des utilisateurs uniformément structuré et par là même facilement comparable.
Beaucoup de moteurs de recherche sur Internet proposent aux navigateurs WWW qui y font appel, des formulaires de saisie écrits en HTML et dans lesquels l'utilisateur peut spécifier la recherche qu'il désire faire. Sans de tels formulaires une recherche ne serait pas du tout possible. La plupart des moteurs de recherche proposent en plus la possibilité d'entrer sa propre adresse Internet dans la base de données. La prise de renseignements qui y sont nécessaires se passe de la même façon à l'aide de formulaires.
Toujours plus nombreux sur Internet les services de commandes en ligne. Cela peut être des tickets, des pizzas ou des sous vêtements peu importe -pour réaliser de tels services de commande, les formulaires sont indispensables pour permettre à l'utilisateur de mentionner exactement ce qu'il veut commander.
Si vous ne désirez proposer à l'utilisateur qu'une possibilité d'entrer directement en contact avec vous sur vos pages WWW suffit aussi de toutes façons un simple lien à une adresse électronique.
Nombreux sont ceux qui essaient par des formulaires de rassembler les adresses d'utilisateurs, pour les vendre ensuite ou bien pour prendre des renseignements que l'utilisateur n'est pas tenu de donner. Pour ce faire, on utilise souvent comme appât le désir de l'utilisateur - par exemple une loterie ou la possibilité de télécharger gratuitement la version d'essai d'un logiciel coûteux.
Cet abus a mis sur la brèche quelques gardiens auto-proclamés de la protection des données qui malheureusement se fourvoient et ne s'adressent pas aux chasseurs de données qui sont la plupart du temps bien protégés sur le plan juridique, mais à des détenteurs de page d'accueil, qui tombent des nues, qui parce qu'ils proposent un petit formulaire sur la toile, se voient soudain infliger un avertissement. Pour cela, sont avancés des arguments, tel le principe de ce qu'on appelle l'"économie de données" (voir aussi les remarques sur la Commission Nationale de l'Informatique et des Libertés (CNIL) dans la partie traitant des Lois pour les "nouveaux médias" (en France)). N'essayez donc pas de pressurer l'utilisateur comme un citron avec des formulaires. Limitez vous aux champs de formulaire qui sont clairement utiles à sa destination.
Vous pouvez définir un formulaire à un endroit de votre choix dans le corps d'un fichier HTML.
<form action="http://www.votre-estimable-nom.fr/cgi-bin/retour.pl" method="get"> <!-- ici suivent les éléments de formulaires --> </form> |
<form action="mailto:tetedeuf@quelque.part" method="post" enctype="text/plain"> <!--ici suivent les éléments de formulaires --> </form> |
Avec <form>...</form>
vous définissez un formulaire (form = Formulaire). Tout ce qui se trouve entre ce repère d'ouverture <form>
et le repère de fermeture </form>
fait partie du formulaire. Ce sont principalement des éléments du formulaire comme des champs de saisie, des listes de choix ou des boutons . Pour placer les éléments et leur affecter une inscription, vous pouvez bien sûr noter entre eux d'autres éléments HTML. Pour le faire, il vous faut cependant veiller à ceci: d'après la variante HTML "Strict" vous ne pouvez noter dans un formulaire que des
éléments de bloc (et des passages Script), donc par exemple des titres, des paragraphes, des passages communs ou des tableaux. Dans la variante HTML "Transitional" il est par contre en outre permis de noter entre <form>
et </form>
également un contenu fait de texte et d' éléments incorporés. Pour contourner cette restriction un peu pénible dans la variante "Strict" dont les motifs échappent à cet endroit, vous pouvez vous tirer d'affaire en structurant le formulaire de la façon suivante:
<form><div> <!-- contenu du formulaire --> </div></form>
.
Dans l'élément div
qui est noté là en plein milieu du formulaire, vous avez aussi dans la variante "Strict" les libertés offertes par la variante "Transitional". Une autre possibilité consiste à travailler avec l'élément fieldset
plutôt qu'avec l'élément div
et d'y inclure les contenus de formulaires - même dans l'élément fieldset
vous avez toute liberté (voir à ce sujet Grouper des éléments).
Dans le repère d'ouverture <form>
vous indiquez avec l'attribut obligatoire action=
ce qui doit se passer avec le formulaire rempli quand l'utilisateur l'envoie (action = action). La mention qui suit action=
est soit une adresse électronique (en principe la votre) précédée de mailto:
- comme dans le deuxième
exemple ci-dessus (mailto = envoie à). Ensuite les données du
formulaire rempli sont envoyées à cette adresse électronique, dans la mesure où c'est possible.
Ou bien vous faites appel à un programme sur l'ordinateur serveur, le plus
souvent un programme CGI qui travaille les données - comme dans le premier
exemple ci-dessus.
Vous pouvez aussi mentionner pour action=
un fichier HTML. Celui-ci sera appelé à l'envoi du formulaire et peut continuer à traiter les données du formulaire par exemple avec JavaScript . Ce qui est par exemple intéressant pour un formulaire de plusieurs pages. Tenez compte pourtant pour le faire que JavaScript n'a accès aux données que si la méthode get
a été employée. Pour quelques navigateurs, Opéra par exemple, la passation de données de formulaires entre fichiers HTML ne fonctionne que dans un environnement HTTP, donc pas localement sans communication serveur.
Pour l'affectation de valeur à action=
s'appliquent les règles pour référencer en HTML. Le référencement avec des mentions de chemins relatives ou absolues est donc possible comme la référence avec une URI absolue de l'exemple 1 par exemple:
<form action="/cgi-bin/evalue.pl">
.
<form action="../../cgi-bin/recherche.cgi">
Un autre attribut important pour la définition de formulaires est l'attribut method=
. Il vous sert à déterminer d'après quelle méthode de transmission HTTP les données du formulaire atteindront leur cible. Deux possibilités sont offertes pour la transmission:
method="get"
les données du formulaire rempli sont jointes comme paramètres à l'adresse appelée (cette mention n'est d'ailleurs pas strictement nécessaire étant donné que get
est défini par défaut). La demande qui arrive au serveur pourrait par exemple avoir l'aspect suivant:http://www.votre-estimable-nom.fr/cgi-bin/retour.cgi?Nomdutilisateur=Serge+Fran%E7ois&courriel=selfhtml@fr.selfhtml.org&Texte=c+est+un+petit+texte
. Le script qui traite peut lire celles-ci comme chaîne de caractères transmise comme paramètre et les scinder pour les traiter. Si vous vous intéressez de plus près à ce sujet, vous pouvez lire la partie traitant des formulaires HTML et CGI.method="post"
les données du formulaire rempli sont mises à la disposition par le serveur Web par l'intermédiaire du canal d'entrée standard, et un script d'évaluation CGI doit traiter les données qui lui arrivent comme une saisie utilisateur qui serait faite sur la ligne d'invite (post = envoyer). Pour les scripts CGI, vous devez en tout état de cause utiliser cette méthode quand le script traite la méthode POST et que les données du formulaire sont trop abondantes pour la méthode GET.Le consortium W3 recommande d'employer la méthode get
quand le programme d'évaluation n'a besoin des données que comme entrée (Input) (par exemple pour une recherche), tandis que la méthode post
est recommandée pour les cas où le programme d'évaluation exécute des "effets de page" tels que le stockage des données dans une base de données.
Quand vous vous faîtes envoyer les données de formulaire par courriel, comme le montre le deuxième exemple, alors employez toujours method="post"
. Par ailleurs vous devez mentionner enctype="text/plain"
dans le repère d'ouverture <form>
pour la réception par courriel de données de formulaire. Car les données de formulaire sont normalement codées d'après un schéma qui n'est pas agréable à lire pour l'homme. Grâce aux mentions indiquées vous recevez des courriels formatés proprement, tout au moins quand ils proviennent d'utilisateurs qui remplissent leur formulaire avec un navigateur Web moderne.
Pour les formulaires-courriel, le succès n'est pas garanti. Cela dépend du navigateur et d'autres réglages sur l'ordinateur de l'utilisateur pour que l'envoi de formulaire fonctionne. Les formulaires-courriel passent pour cette raison pour peu propres à plus forte raison quand il y a des alternatives. Plus de détails à ce sujet dans la partie sur l' exploitation des formulaires.
Si vous travaillez avec des cadres (frames) et que dans un cadre vous avez un formulaire; vous désirez qu'après l'envoi de ce formulaire la réponse du serveur (par exemple le tirage d'un script CGI) soit affichée dans un autre cadre vous pouvez mentionner la fenêtre cible pour la réponse du serveur.
<form action="/cgi-bin/evalue.pl" method="get" target="Donnees"> <!-- ici suivent les éléments du formulaire --> </form> |
Avec l'attribut target=
vous pouvez mentionner dans le repère
d'ouverture <form>
le nom de la fenêtre cadre dans laquelle la réponse du serveur doit être sortie. Il doit s'agir soit d'un nom de fenêtre attribué pour une fenêtre cadre à l'attribut name
dans le repère d'ouverture <frame>
, soit de l'un de ces noms de fenêtres réservés:
_self
, pour sortir la réponse du serveur dans la fenêtre actuelle,
_parent
, pour fermer le jeu de cadres actuel pour la réponse du serveur dans le cas de jeu de cadres imbriqués,
_top
, pour fermer tous les jeux de cadres actuels pour la réponse du serveur dans le cas de jeu de cadres imbriqués.
L'attribut target
n'est certes pas classé en cours d'abandon, pourtant pour le mettre en œuvre, vous devez utiliser la variante HTML "Transitional". La raison en est que cet attribut est avant tout conçu pour des liens lors de l'emploi de cadres et que les cadres ont une variante HTML qui leur est propre et qui correspond d'après le classement à la variante HTML "Transitional" (en bon français: ne correspond pas aux "dogmes").
Vous pouvez mentionner d'après quel jeux de caractères doivent être interprétées les données saisies dans le formulaire. Pour cela, vous pouvez mentionner un ou plusieurs jeux de caractères.
<form action="/cgi-bin/evalue.pl" method="get" accept-charset="ISO-8859-1, ISO-8859-2"> <!-- ici suivent les éléments du formulaire --> </form> |
Avec l'attribut accept-charset=
vous pouvez mentionner des jeux de caractères. Séparez plusieurs mentions avec des virgules et/ou des espaces. Sont permises les mentions de jeux de caractères telles qu'elles sont mentionnées à l'adresse Web http://www.iana.org/assignments/character-sets.
Dans le sommaire de référence HTML vous trouverez des données précisant où le repère form
peut être mis, quels attributs il peut avoir et ce à quoi il faut veiller pour ces différents attributs:
référence pour les éléments pour les formulaires (<form>...</form>
)
référence pour les attributs pour les formulaires (<form>...</form>
)
Pour le traitement des données d'un formulaire à l'aide de scripts CGI, il y a dans la présente documentation le chapitre sur CGI/Perl.
Champs et domaines de saisie | |
Graphiques composés de liens (Image Maps: cartes cliquables) | |
SELFHTML/Aides à la navigation HTML/XHML Formulaires |
© 2001 Stefan Münz / © 2003 Traduction Serge François, 13405@free.fr
selfhtml@fr.selfhtml.org