Les formulaires

1. Les formulaires HTML

À la base, une application interactive, c’est au minimum des boutons. Mais pour de nombreuses applications, cela ne s’arrête pas là, et il faut y ajouter des champs éditables, des listes de données, des boutons de sélection. Bref, les mêmes possibilités qu’une application classique sur ordinateur.

Il est donc nécessaire d’utiliser des formulaires HTML, ils proposent à peu près tout ce qui est nécessaire pour une WebApp. À la base, le tag form sert de conteneur pour tout formulaire HTML. Avec un site web classique, il est obligatoire, car c’est lui qui contient l’adresse de destination du formulaire dans son attribut action. Dans le cas d’une WebApp, ce tag est moins nécessaire, car il ne sert plus à envoyer le contenu du formulaire, ceci est fait séparément avec AJAX. Malgré tout, cela reste une bonne pratique d’utiliser le tag form comme un conteneur pour le formulaire.

2. Les éléments input

Une grande partie des éléments de formulaire est créée au moyen du tag input, c’est l’attribut type qui permet de les différentier. La liste qui suit présente les différentes valeurs que peut prendre cet attribut. Elle est assez conséquente, et pourtant elle n’est pas exhaustive.

text

Cette valeur permet de définir un champ texte éditable. L’attribut type n’est pas obligatoire, car text est le type par défaut. Il faut néanmoins qu’il soit présent si l’on veut utiliser input[type=text] dans un sélecteur CSS.

password

Cette valeur permet de définir une saisie d’un mot de passe. Le texte est remplacé par des points, ou des étoiles.

number

Cette valeur permet de définir un champ texte pour saisir une valeur numérique. Des boutons + et - sont ajoutés sur le côté du champ. Il est préférable de spécifier la hauteur de ce champ au moyen d’une feuille de style, sinon il peut apparaître moins haut que les boutons. Les attributs min, max et step permettent de paramétrer le comportement de ce champ et permettent également d’effectuer des contrôles de validité.

color

Cette valeur permet...

1. L’accès aux éléments input

Chacun des éléments d’un formulaire nécessite d’être identifié pour pouvoir manipuler son contenu, aussi bien en lecture qu’en écriture. On peut y parvenir au moyen de l’attribut id ou de l’attribut name. Les deux permettent de parvenir au même résultat : accéder au champ input de l’exemple qui suit. Quand on utilise jQuery, c’est aussi simple de faire référence à id ou à name, mais la syntaxe est nettement différente, comme on peut s’en rendre compte si l’on veut adresser le champ input présent dans le code qui suit.

<form id='info'> 
 <input id='id1' name='name1'> 
<form> 

La méthode la plus directe consiste à utiliser id. C’est aussi la méthode qui offre les meilleures performances.

$(‘#id1’)

Si l’on préfère utiliser name, il est nécessaire de spécifier l’identifiant du formulaire s’il y en a plusieurs dans le document.

$("form#info input[name=’name1’]")

Sinon, cette variante allégée peut être utilisée s’il n’y a qu’un seul formulaire à gérer.

$("input[name=’name1’]")

Les attributs id étant uniques, utiliser id pour spécifier un élément de formulaire fait qu’un élément similaire dans un autre formulaire présent sur la même page ne pourra pas porter ce nom. Par contre, si on utilise name pour accéder à un élément de formulaire, il sera possible de réutiliser la même valeur de name pour un autre élément dans un autre formulaire de la page. À noter qu’à l’intérieur d’un même formulaire, seuls les boutons de radio peuvent avoir une valeur identique pour l’attribut name. Dans le cas d’une WebApp, l’utilisation de name est préférable, car une WebApp complète n’est souvent qu’un document unique, où tous les formulaires doivent donc cohabiter ensemble.

L’identifiant du formulaire permet donc de faire la différence lorsque l’on cherche à accéder...

1. Pour l’ergonomie et pour la sécurité

Parce que les validations automatiques ne permettent pas de répondre à tous les cas de figure, il est souvent nécessaire de s’assurer de la validité des données saisies. Cela peut se faire à plusieurs niveaux.

Sur le serveur, la base de données effectue systématiquement un contrôle de la validité des données avant leur enregistrement. Cependant, ce contrôle est assez limité : il y a vérification du type des données pour les nombres et les dates, et de la taille des données pour les nombres et les textes ; on peut aussi utiliser des contraintes CHECK pour contrôler les valeurs avant de valider leur enregistrement dans la base. On ne peut pas se fier qu’à cela pour contrôler les données qui vont être envoyées vers le serveur, des contrôles spécifiques doivent préalablement être effectués.

Toujours sur le serveur, il est possible d’effectuer des contrôles en PHP. Outre une évidente vérification de la validité et de la cohérence des données fournies, c’est aussi l’occasion de protéger la base de données contre des attaques malveillantes. Les données à stocker sous forme numérique sont explicitement converties en nombres et les caractères spéciaux sont convertis dans les données texte. Même si cette étape est nécessaire pour protéger la base de données, elle n’est pas suffisante pour assurer l’interactivité d’une WebApp, car il faut effectuer une communication client-serveur avant d’être informé d’une erreur de saisie.

C’est pour cela qu’il est préférable d’effectuer un contrôle préliminaire côté client, en JavaScript, avant d’envoyer les données au serveur. Ce contrôle peut être effectué au moment de l’envoi du formulaire, mais on préfère maintenant effectuer le contrôle lors de la saisie, ce qui est bien plus agréable pour l’utilisateur qui peut immédiatement corriger ses fautes. Un champ en erreur est généralement entouré...