version 1.14, dernière mise à jour le 20 mai 2009.
Les formulaires sont depuis plusieurs années une composante essentielle des sites Internet. Ils permettent en effet, à moindres frais, d'apporter une touche d'interactivité à l'internaute. Néanmoins, les formulaires disponibles à l'aide des balises en HTML
présentent des limitations qui sont maintenant gênantes :
une mauvaise intégration en XML : certains de ces éléments (comme <input>
, par exemple), sont des balises vides non fermées ;
des fonctionnalités limitées : pour réaliser de nombreuses actions, comme pré-remplir dynamiquement certains éléments du formulaire, ou bien vérifier la validité d'une saisie (comme une adresse électronique, par exemple), il est nécessaire de passer par un langage de script ;
un codage mêlant présentation et information ;
un support des éléments affichables dépendant fortement de l'outil utilisé.
Afin de répondre à ces exigences de la communauté, le W3C a mis sur pied un groupe de travail, dont le résultat fut la publication en octobre 2003 de la recommandation pour le langage XForms
. Une seconde édition a été publiée en mars 2006. La troisième version est sortie le 29 octobre 2007.
Un formulaire collecte des données ; la représentation interne au navigateur de ces données est une instance data, basée sur XML
.
Les relations entre les données au sein de ces représentations sont plus complexes qu'en HTML
où, on le rappelle, on ne rencontre que des paires nom_variable=valeur
. Dans le cas de XForms
, deux champs de formulaires peuvent être interdépendants.
À une saisie de l'utilisateur correspond une instance data, traitée en mémoire, qui en retour agit sur le formulaire qui lui a donné « naissance », ce qui conditionne la saisie de l'utilisateur, etc. La soumission elle-même n'a lieu qu'à la toute fin du processus. Cette soumission est effectuée selon un formatage de données précis, conforme par exemple à un Schéma, et permettant un envoi au format XML
, déjà acceptable sans traitement par le serveur.
Afin d'alléger encore la charge du serveur, XForms
permet de réaliser des calculs sur les données avant leur soumission. En fait, il est possible de réaliser tout ce que
XPath
permet, ainsi que des calculs plus aboutis, des vérifications en temps réel du formatage des données saisies, la gestion de champs de formulaires obligatoires, etc.
Le but des membres du groupe de travail était de remplacer 80% des scripts nécessaires dans les formulaires en HTML
, par seulement 20% de fonctionnalités. Cela est réalisé par un recours intensif :
à XPath
pour les calculs et manipulations de chaînes de caractères ;
à XML Schema
pour les vérifications de formatage des données saisies ;
à des fonctions de calcul supplémentaires telles que average()
, min()
, max()
, etc.
Les éléments de formulaire HTML
ont été remplacés par quelques équivalents XForms
. D'autres sont nouveaux.
Élément |
Élément |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pas d'équivalent |
|
pas d'équivalent |
|
Table 1. Équivalents (X)HTML
des nouveaux éléments XForms
.
Les éléments <input>
, <textarea>
et <secret>
, appliquées à des données de type chaîne de caractères, ont le même comportement qu'en HTML
. Lorsqu'ils sont appliqués à une donnée d'un autre type, le comportement peut être adapté. On peut par exemple imaginer un champ de saisie d'une donnée de type date
(voir les types prédéfinis dans le cours sur les Schémas), qui se présente non comme un champ de saisie de texte, mais comme un calendrier interactif.
Les saisies de texte prévoient aussi des « modes d'entrée », du formatage automatique (par exemple, un champ ne peut accepter les numéros de téléphone que sous une certaine forme, grâce à un type de donnée défini dans un schéma), mais aussi des fonctionnalités simples de formatage au moment de la soumission (par exemple, une conversion majuscule vers minuscule automatique).
L'élément <select>
dispose d'un attribut, appearance
, qui permet de spécifier si le champ doit se présenter sous la forme minimale (minimal
), compacte (compact
) ou complète (full
).
L'élément <output>
permet l'affichage des données saisies en temps réel dans le formulaire. Par exemple (les données saisies dans le formulaire sont mises en valeur) :
Vous êtes en train de commander
3756 briques
en
porcelaine de Chine
. En êtes-vous sûr
e
?
L'élément <range>
peut s'afficher comme une sorte de curseur coulissant le long d'une règle graduée, ou bien un bouton que l'on peut tourner. L'avenir dira l'interface qui deviendra la plus habituelle.
L'élément <upload>
va au-delà de la simple boîte de dialogue d'ouverture de fichier, puisque le groupe de travail XForms prévoit qu'il soit possible de gérer par ce genre d'interface la capture à partir d'un scanner ou d'un appareil photo numérique connecté à la machine, un micro, etc.
XForms
offre aussi d'autres possibilités : champs de formulaires copiés (par exemple, pour entrer plusieurs fois des produits dans chariot électronique), affichage/masquage de portions du formulaire, gestion de formulaires s'étendant sur plusieurs pages HTML
.
En fait, il apparaît que XForms
peut être interprété comme un langage de réalisation d'interface pour des applications Web.
En HTML
, certains événements n'étaient accessibles que par des appels à des scripts (par exemple, les événements onfocus
, onblur
, onselect
...). XForms
fait appel au modèle XML events, qui peut prendre en charge :
la « focalisation » sur un élément de formulaire
l'affichage d'un message
le chargement d'une nouvelle URL (dans la fenêtre courante ou une autre)
des calculs, des vérifications de conformité à un format prédéfini, des rafraîchissements d'écran...
la soumission ou la remise à zéro d'un formulaire
le défilement automatique le long d'un formulaire...
XForms
est un langage nouveau et, en tant que tel, n'est pas encore supporté nativement par les navigateurs. Il est néanmoins d'ores et déjà possible de tester son code :
soit avec un plug-in d'Internet Explorer 6, FormsPlayer ;
soit avec un petit navigateur Java dédié aux formats XML
, X-Smiles (ce navigateur implémente notamment en natif SVG
, SMIL
).
soit avec l'extension Mozilla XForms pour FireFox
Orbeon et Chiba sont deux implémentations Open Source utilisant Ajax.
Une liste plus complète d'implémentations est disponible au W3C.
Via les espaces de nom, XForms
peut être intégré dans n'importe quel fichier XML
. Mais l'utilisation la plus répandue est dans un fichier XHTML
.
Un exemple simple donne les principes de base : il est disponible en téléchargement. On notera :
l'appel à des espaces de nom pour l'insertion des éléments de formulaire ;
un modèle dans l'entête du fichier HTML
, et les balises non insérées dans un élément particulier dans le corps du fichier (il n'y a pas de balise <form>
) ;
la présence obligatoire d'éléments label
, qui permettent à la fois de décrire chaque élément de formulaire, mais aussi de fournir le texte destiné à être affiché sur les boutons.
Sous réserve de correctement libeller le modèle (ce qui n'est pas le cas ici), la chaîne de caractères envoyée par le formulaire lors de la soumission est le fichier XML
suivant :
<instanceData>
<numero>(...)</numero>
</instanceData>
Le deuxième exemple, disponible lui aussi en téléchargement, présente quelques autres principes de base en plus de ceux précédemment évoqués :
Le modèle doit répondre à deux tâches :
il doit définir la structure de l'instance data, dans la balise <instance>
;
il doit aussi définir ce qui arrive lors de la soumission du formulaire.
La balise <instance>
définit les éléments XML
qui figureront dans la soumission du formulaire. Il est possible, au lieu de simplement écrire, dans l'ordre, la liste de ces éléments, de faire référence à un schéma externe, à l'aide d'un attribut src
. Cette possibilité permet d'appliquer plus de contraintes aux données qui doivent être saisies.
La balise <submission>
possède beaucoup d'attributs ; les trois plus importants sont id
, action
et method
, comme en HTML
. L'exemple donné en propose deux illustrations :
Comme en HTML
, id
permet d'... identifier le modèle de soumission ;
la création d'un fichier local (méthode "put"). On peut se servir de cette méthode si on doit réaliser l'interface d'une application Web destinée à aider des utilisateurs novices à produire des fichiers XML
selon un format précis.
l'envoi "classique" (méthode "post"). Cette méthode est particulièrement adaptée à l'utilisation de Services Web.
Dans le formulaire lui-même, dans le corps du document, on note pour chaque champ l'utilisation de quelques attributs :
L'attribut model
"pointe" vers le modèle d'instance data utilisé ;
L'attribut ref
pointe, pour l'instance data sélectionnée, vers la balise à remplir ;
L'attribut class
permet de faire référence à une propriété CSS
gérant l'apparence de l'élément.
L'élément <submit>
, enfin, possède un attribut submission
désignant le type de soumission à employer. Cet attribut fait référence à la balise <submission>
d'identifiant correspondant.
Le troisième exemple en téléchargement ajoute quelques éléments :
Une balise <repeat>
permet d'indiquer une collection d'éléments de formulaire répétables.
L'élément <trigger>
, qui désigne un bouton, permet de spécifier une action de répétition. Pour cela, lorsque l'événement indiqué par l'attribut ev:event
est activé, le formulaire s'ajoute (sans script, balise <insert>
) un élément <order>
(nodeset=order
, après le dernier élément de même nom dans l'instance data (at="last()" position="after"
)
Outre ses indéniables avantages par rapport aux formulaires HTML
en termes d'allègement de code (en limitant le recours aux langages de script, notamment), XForms
est un langage qui semble spécifiquement dédié à la réalisation d'interface pour des applications Web, mais aussi pour des Services Web.
Il s'agit néanmoins d'un langage complexe -on n'a rien sans rien.
Le plus simple, pour un auteur habitué aux formulaires HTML
et désireux d'explorer ce nouveau langage, est de jeter un oeil sur le document du W3C intitulé XForms for HTML Authors.
Cette création est mise à disposition par Gilles Chagnon sous un contrat Creative Commons.