‘XForms for HTML Authors’ (28 octobre 2003) en version française

Statut du document traduit

Ceci est une traduction d'un document du W3C traitant de la transition des formulaires HTML vers les formulaires XForms.

Cependant, il ne s'agit pas de la version officielle en français. Seul le document original en anglais a valeur de référence. On peut l'obtenir à : http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html.

Avertissement

Des erreurs ont pu survenir malgré le soin apporté à ce travail.

Notes sur la traduction

Certains concepts sont difficiles à rendre en français, ou peuvent bénéficier d'une explication. Par moment, les expressions originales en anglais viennent en renfort dans le texte sous cette forme :
ex. traduction [ndt. translation]

D'autres expressions intègrent également les versions originales en anglais, qui apparaissent d'une manière ou d'une autre (selon le navigateur), lorsque l'on laisse le pointeur de la souris au-dessus d'elles. Elles se présentent sous cette forme :
ex. Agent utilisateur

Finalement, les liens menant à d'autres documents du W3C déjà traduits sont discrètement doublés vers leur traduction, comme ceci :
ex. un lien vf  vers un document du W3C.

Archives compressées et autres formats

Cette traduction est disponible au format HTML sous forme d'archive compressée et, le cas échéant, dans d'autres formats à l'adresse http://www.yoyodesign.org/doc/w3c/w3c.html.

Autres documents traduits

On peut consulter les traductions en français d'autres documents du W3C à
http://www.w3.org/2003/03/Translations/byLanguage?language=fr

Avis légal

Copyright © 1994-2004 World Wide Web Consortium,
(Massachusetts Institute of Technology,
European Research Consortium for Informatics and Mathematics,
Keio University).
Tous droits réservés. Consulter la notice de copyright pour les productions du W3C.

W3C

XForms pour les auteurs HTML

Steven Pemberton, W3C/CWI

Date de la version : 28 octobre 2003

Introduction

XForms est le nouveau langage de balisage pour les formulaires sur le Web. Ce document est une rapide introduction à XForms destinée aux auteurs HTML. Il montre comment convertir les formulaires existants dans leur équivalent en XForms. Une connaissance des formulaires HTML est requise, et il ne s'agit donc pas d'un tutoriel destiné aux débutants. Même si des facilités supplémentaires de XForms sont mentionnées (signalées par un astérisque dans le titre), qui vont au-delà de celles permises par les formulaires HTML, il ne s'agit pas non plus d'un tutoriel présentant toutes les fonctionnalités de XForms.

Table des matières

  1. Un formulaire de recherche simple
  2. Les commandes de formulaire
  3. Les valeurs soumises
  4. La soumission
  5. La maîtrise des commandes
  6. Plusieurs formulaires dans un document
  7. Les fonctionnalités absentes de cette présentation

* Fonctionnalités absentes des formulaires HTML

Un formulaire de recherche simple

Considérons ce formulaire HTML simple :

<html>
<head><title>Rechercher</title></head>
<body>
    <form action="http://example.com/rechercher"
          method="get">
         Trouver <input type="text" name="q">
         <input type="submit" value="Chercher">
    </form>
</body>
</html>

La principale différence dans XForms tient au fait que le détail des valeurs collectées et la manière de les soumettre sont rassemblés dans un élément model, dans l'élément head ; seules les commandes de formulaire se placent dans l'élément body. Dans le cas présent, la déclaration minimum nécessaire à placer dans l'élément head se résume à :

<model>
   <submission action="http://example.com/rechercher"
               method="get"
               id="s"/>
</model>

(Les éléments et attributs dans XForms sont en lettres minuscules.)

L'élément form n'est plus nécessaire et les commandes dans l'élément body prennent l'aspect suivant :

<input ref="q"><label>Trouver</label></input>
<submit submission="s"><label>Chercher</label></submit>

On peut en déduire que les commandes de formulaire ont un élément label comme enfant, que l'élément input utilise l'attribut ref au lieu de name et qu'une commande submit séparée relie aux détails de la soumission dans l'en-tête. L'exemple complet est donc :

<h:html xmlns:h="http://www.w3.org/1999/xhtml"
       xmlns="http://www.w3.org/2002/xforms">
<h:head>
    <h:title>Rechercher</h:title>
    <model>
        <submission action="http://example.com/rechercher"
                    method="get" id="s"/>
    </model>
</h:head>
<h:body>
    <h:p>
        <input ref="q"><label>Trouver</label></input>
        <submit submission="s"><label>Chercher</label></submit>
    </h:p>
</h:body>
</h:html>

Les préfixes d'espace de nommage

Une autre différence évidente est l'utilisation d'un préfixe h: avec les éléments HTML. Cela n'a rien à voir avec XForms, mais concerne XML qui est conçu pour vous permettre de combiner différents langages en même temps. XForms est conçu pour se combiner à divers langages, et pas seulement HTML. On doit indiquer aux processeurs XML à quel langage les différents éléments appartiennent, même s'il n'y a qu'un seul langage par défaut. Dans le document précédent, XForms était le langage par défaut, et XHTML aurait aussi bien pu l'être si on avait changé les attributs xmlns dans l'en-tête, par exemple, comme ceci :

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:f="http://www.w3.org/2002/xforms">
<head>
    <title>Rechercher</title>
    <f:model>
        <f:submission action="http://example.com/rechercher"
                      method="get" id="s"/>
    </f:model>
</head>
<body>
    <p>
        <f:input ref="q"><f:label>Trouver</f:label></f:input>
        <f:submit submission="s"><f:label>Chercher</f:label></f:submit>
    </p>
</body>
</html>

La décision vous revient. Vous pouvez tout aussi bien décider de ne pas en faire l'espace de nommage par défaut et de préfixer tous les éléments. Choisissez n'importe quel préfixe : h: ou x: ou html: ou form:, comme vous l'entendez.

Dans le futur, XHTML2 vous permettra d'écrire des formulaires sans préfixe.

Les commandes de formulaire

XForms offre des équivalents de toutes les commandes de formulaire HTML. Néanmoins, les approches sont très différentes : HTML définit principalement comment la commande devrait se présenter et XForms définit ce que la commande devrait faire. Ainsi la spécification HTML dit que l'élément select crée un menu et que l'élément input de type "radio" crée un bouton radio ne permettant qu'un choix unique, tandis que XForms définit les éléments select et select1 qui déterminent seulement l'intention des commandes, à savoir, sélectionner zéro ou plusieurs éléments, ou seulement un seul, à partir d'une liste. Leur présentation à l'utilisateur varie d'un appareil à l'autre, ou en fonction d'une feuille de style. Pour un téléphone portable, dont la taille de l'écran est réduite, les deux pourraient prendre la forme de menus, et au contraire, sur un écran plus grand, prendre la forme de boutons sélectionnables. Vous pouvez fournir une indication de ce que vous souhaitez ou utiliser une feuille de style pour une restitution précise, dans le cas contraire, l'appareil ou une feuille de style s'en chargera.

Voici une équivalence aux commandes de formulaire HTML.

La saisie de texte simple

Prénom : <input type="text" name="prenom">

Cette ligne se traduit en XForms par 

<input ref="prenom"><label>Prénom :</label></input>

Il n'est pas nécessaire d'indiquer que c'est du texte : en l'absence de toute autre information, c'est implicitement du texte (type string dans XForms).

Voir plus loin la section Les valeurs initiales sur la manière de donner une valeur initiale à une commande quelconque.

La zone texte

Message : <textarea name="message" rows="20" cols="80"></textarea>

Cette ligne se traduit en XForms par :

<textarea ref="message"><label>Message :</label></textarea>

L'habillage de style, comme la hauteur et la largeur dans ce cas, intervient au moyen d'une feuille de style. Par exemple, celle-ci :

textarea[ref="message"] { font-family: sans-serif;
                          height: 20em; width: 80em;}

Même si c'est un comportement imité de HTML, il n'est pas obligatoire d'employer une police sans sérif ni de spécifier la largeur des rangées et colonnes ainsi ; vous pourriez utiliser des unités de longueur ou de pourcentage, ou quoique ce soit d'autre :

textarea[ref="message"] { font-family: serif;
                          height: 2cm; width: 20%;}

Si vous souhaitez que toutes vos zones textes aient les mêmes dimensions :

textarea { font-family: sans-serif;
           height: 20em; width: 80em;}

Le moyen le plus facile d'adjoindre une feuille de style à votre document est de lui ajouter au début ceci :

<?xml version="1.0"?>
<?xml-stylesheet href="style.css" type="text/css"?>

Le nom de la feuille de style est "style.css".

Les boutons radios

Les boutons radios déterminent la sélection d'une seule valeur parmi un certain nombre de valeurs possibles :

Genre :
<input type="radio" name="sexe" value="M"> Masculin
<input type="radio" name="sexe" value="F"> Féminin

Ce qui se traduirait en XForms par  :

<select1 ref="sexe">
   <label>Genre :</label>
   <item>
      <label>Masculin</label><value>M</value>
   </item>
   <item>
      <label>Féminin</label><value>F</value>
   </item>
</select1>

Gardez à l'esprit que ceci peut prendre l'aspect de boutons radios, d'une zone de sélection (défilante) ou d'un menu. Vous pouvez fournir une indication appearance='full' sur l'élément select1 pour suggérer une présentation en boutons radios. (Utilisez appearance='compact' pour suggérer une zone de sélection et appearance='minimal' pour suggérer un menu.)

La section Les valeurs initiales dit comment préselectionner une valeur.

Les cases à cocher

Les cases à cocher permettent la sélection de zéro élément ou plus dans une liste.

Parfums :
<input type="checkbox" name="parfum" value="v"> Vanille
<input type="checkbox" name="parfum" value="f"> Fraise
<input type="checkbox" name="parfum" value="c"> Chocolat

Ce qui se traduit en XForms par :

<select ref="parfum" appearance="full">
   <label>Parfums :</label>
   <item>
      <label>Vanille</label><value>v</value>
   </item>
   <item>
      <label>Fraise</label><value>f</value>
   </item>
   <item>
      <label>Chocolat</label><value>c</value>
   </item>
</select>

La section Les valeurs initiales dit comment précocher les valeurs.

En fonction de la présence de l'attribut multiple dans HTML, les menus déterminent la sélection d'un seul élément, ou de zéro ou plus, dans une liste d'options. On utilise soit la commande select1 pour sélectionner un seul élément, soit select pour en sélectionner zéro ou plus.

Mois :
<select multiple name="printemps">
      <option value="mars">Mars</option>
      <option value="avril">Avril</option>
      <option value="mai>Mai</option>
</select>

Ce qui se traduit en XForms par :

<select ref="printemps" appearance="minimal">
<label>Mois :</label>
<item><label>Mars</label><value>mars</value></item>
<item><label>Avril</label><value>avril</value></item>
<item><label>Mai</label><value>mai</value></item>
</select>

Si l'attribut multiple n'apparaît pas sur l'élément HTML select, alors utiliser plutôt l'élément select1.

La section Les valeurs initiales dit comment préselectionner les valeurs.

La sélection de fichier

<form method="post" enctype="multipart/form-data" ...>
 ...
Fichier : <input type="fichier" name="piecejointe">

Ce qui se traduit en XForms par :

<submission method="form-data-post" .../>
...
<upload ref="piecejointe"><label>Fichier :</label></upload>

Les mots de passe

Mot de passe : <input type="password" name="mdp">

Ce qui se traduit en XForms par :

<secret ref="mdp"><label>Mot de passe :</label></secret>

La réinitialisation

Une expérience de dix années avec les formulaires HTML a montré que pratiquement personne n'utilisait les boutons de réinitialisation, et pourtant nombre de formulaires Web en comprennent. Un problème découle de ce que le texte Réinitialiser est plus grand que celui du bouton de soumission souvent intitulé OK, en conséquence de quoi les personnes cliquaient accidentellement sur le bouton de réinitialisation alors qu'elles pensaient cliquer sur OK, anéantissant parfois beaucoup d'effort de saisie (peu de navigateur ou prou proposent une annulation d'action). C'est pourquoi, même s'il est possible de créer un bouton de réinitialisation en XForms, leur création est volontairement difficile afin d'en décourager les auteurs à moins qu'ils ne le veuillent vraiment :

<input type="reset">

Ce qui se traduit en XForms par 

<trigger>
   <label>Effacer tous les champs</label>
   <reset ev:event="DOMActivate"/>
</trigger>

Les boutons

Les boutons n'ont pas de fonctionnement prédéfini, mais un comportement adjoint qui se déclenche lorsque se produit un événement déterminé.

Les boutons de type "button" :

<input type="button" value="Voir" onclick="voir()">

Ce qui se traduit en XForms par :

<trigger><label>Voir</label>
   <h:script ev:event="DOMActivate" type="text/javascript">voir()</h:script>
</trigger>

Ou encore par :

<trigger ev:event="DOMActivate" ev:handler="#voir">
    <label>Voir</label>
</trigger>

Dans lequel la valeur "#voir" localise l'élément (par exemple, un élément script) qui met en œuvre le comportement :

<script id="voir" ...>...

XForms intègre un certain nombre d'actions pouvant être menées par un bouton ; voir l'exemple du bouton de réinitialisation précédent.

L'attribut event ayant un préfixe, cela signifie nécessairement la déclaration de l'espace de nommage suivant dans l'en-tête :

xmlns:ev="http://www.w3.org/2001/xml-events"

Les boutons images

<input type="image" src="..." ...>

Ce qui se traduit en XForms en plaçant une image dans l'élément label :

<trigger...><label><h:img src="..." .../></label></trigger>

Ou encore en la spécifiant dans une feuille de style :

<trigger id="activer" ...>

La feuille de style l'appelant comme ceci :

trigger#activer {background-image: url(bouton.png);
                  background-repeat: none;}

(Idem pour les boutons de type "submit".)

Le groupe d'options

Boisson :
<select name="boisson">
   <option selected value="aucune">Aucune</option>
   <optgroup label="Boissons non alcoolisées">
      <option value="h2o">Eau</option>
      <option value="l">Lait</option>
      <option value="j">Jus</option>
   </optgroup>
   <optgroup label="Boissons alcoolisées">
      <option value="vr">Vin rouge</option>
      <option value="vb">Vin blanc</option>
      <option value="b">Bière</option>
   </optgroup>
</select>

Ce qui se traduit en XForms par :

<select1 ref="boisson">
   <label>Boisson :</label>
   <item><label>Aucune</label><value>aucune</value></item>
   <choices>
      <label>Boissons non alcoolisées</label>
      <item><label>Eau</label><value>h2o</value></item>
      <item><label>Lait</label><value>l</value></item>
      <item><label>Jus</label><value>j</value></item>
   </choices>
   <choices>
      <label>Boissons alcoolisées</label>
      <item><label>Vin rouge</label><value>vr</value></item>
      <item><label>Vin blanc</label><value>vb</value></item>
      <item><label>Bière</label><value>b</value></item>
   </choices>
</select1>

Le regroupement des commandes

<fieldset>
   <legend>Informations personnelles</legend>
   Nom : <input name="nom" type="text">
   Prénom : <input name="prenom" type="text">
   Adresse : <input name="adresse" type="text">
</fieldset>

Ce qui se traduit en XForms par :

<group>
   <label>Informations personnelles</label>
   <input ref="nom"><label>Nom :</label></input>
   <input ref="prenom"><label>Prénom :</label></input>
   <input ref="adresse"><label>Adresse :</label></input>
</group>

Remarquez la cohésion de l'utilisation de label.

Les commandes de sortie*

XForms possède deux commandes que n'a pas HTML : output et range.

La commande output permet d'inclure des valeurs comme du texte dans le document.

Sous-total : <output ref="somme"/>

Ou encore :

<output ref="somme"><label>Total</label></output>

On peut employer cette commande pour permettre à l'utilisateur de prévisualiser les valeurs soumises.

On peut également calculer des valeurs :

Volume hors-tout : <output value="longueur * largeur * hauteur"/>

(Expression dans laquelle les valeurs "longueur", "largeur" et "hauteur" sont collectées par d'autres commandes.)

Les commandes d'étendue*

Cette commande permet de définir une contrainte sur une valeur.

<range ref="volume" start="1" end="10" step="0.5"/>

Un agent utilisateur pourrait représenter ceci comme un curseur ou similaire.

Les commandes cachées

Comme vous le verrez dans la section suivante, les commandes cachées n'ont pas lieu d'être dans XForms.

Les valeurs soumises

L'attribut ref sur chaque commande se rapporte en réalité à un enfant d'un élément instance du modèle, dans lequel les valeurs sont rassemblées avant soumission. Si aucun élément instance ne s'y trouve (comme dans l'exemple de formulaire de recherche précédent), alors il s'en crée un silencieusement.

Rendre explicites les valeurs soumises

Bien qu'il soit parfaitement admis de laisser le système créer l'instance à votre place, c'est quand même une bonne idée de l'inclure soi-même, par exemple, dans le formulaire de recherche, comme ceci :

<model>
    <instance><data xmlns=""><q/></data></instance>
    <submission action="http://example.com/rechercher"
                method="get" id="s"/>
</model>

On voit tout de suite que la seule valeur de donnée soumise est q. L'avantage le plus flagrant réside dans le fait de pouvoir visualiser ce qui est soumis, mais le système va maintenant aussi vérifier si votre déclaration ref='q' correspond réellement à un objet q dans l'instance.

Remarquez qu'il est essentiel, pour des raisons que nous ne développerons pas ici, de placer une déclaration xmlns="" sur vos données d'instance, pour indiquer au processeur que les éléments qui s'y trouvent ne sont ni des éléments XHTML ni des éléments XForms.

(Remarquez que l'on a employé ici une balise data, mais vous pouvez choisir le nom de balise que vous voulez.)

Les valeurs initiales

Pour l'initialisation des commandes, y compris l'initialisation des cases à cocher précochées et des éléments de menu présélectionnés, etc., on fournit simplement une instance contenant des valeurs préremplies. Dans l'exemple du formulaire de recherche :

<instance><data xmlns=""><q>Mot à rechercher</q></data></instance>

Cette déclaration produirait le préremplissage de la commande de texte avec le terme Mot à rechercher.

De la même façon, pour l'exemple dans la section sur les cases à cocher, qui ressemble à ceci :

<select ref="parfum" appearance="full">
   <label>Parfum :</label>
   <item>
      <label>Vanille</label><value>v</value>
   </item>
   <item>
      <label>Fraise</label><value>f</value>
   </item>
   <item>
      <label>Chocolat</label><value>c</value>
   </item>
</select>

On peut présélectionner les cases à cocher Vanille et Fraise ainsi :

<instance><data xmlns=""><parfum>v f</parfum></data></instance>

Et encore, pour l'exemple dans la section sur les menus, qui ressemble à ceci :

<select ref="printemps" appearance="minimal">
<label>Mois :</label>
<item><label>Mars</label><value>mars</value></item>
<item><label>Avril</label><value>avril</value></item>
<item><label>Mai</label><value>mai</value></item>
</select>

On peut présélectionner Mars et Avril ainsi :

<instance><data xmlns=""><printemps>mars avril</printemps></data></instance>

Finalement, pour l'exemple dans la section sur le groupe d'options :

<select1 ref="boisson">
   <label>Boisson :</label>
   <item><label>Aucune</label><value>aucune</value></item>
   <choices>
      <label>Boissons non alcoolisées</label>
      <item><label>Eau</label><value>h2o</value></item>
      <item><label>Lait</label><value>l</value></item>
      <item><label>Jus</label><value>j</value></item>
   </choices>
   <choices>
      <label>Boissons alcoolisées</label>
      <item><label>Vin rouge</label><value>vr</value></item>
      <item><label>Vin blanc</label><value>vb</value></item>
      <item><label>Bière</label><value>b</value></item>
   </choices>
</select1>

On présélectionne Aucune ainsi :

<instance><data xmlns=""><boisson>aucune</boisson></data></instance>

Les valeurs cachées

La raison pour laquelle XForms n'a pas besoin de commandes cachées, c'est que toutes les valeurs dans l'instance qui n'ont pas été attachées par une commande ne sont pas visible, par définition, pour l'utilisateur. Si, par exemple, on veut ajouter une valeur cachée resultats au formulaire de recherche, on change l'instance comme ceci :

<instance><data xmlns=""><q/><resultats>10</resultats></data></instance>

Obtenir les valeurs initiales par ailleurs*

Il n'est pas nécessaire de spécifier l'instance initiale directement dans le document, car on peut la charger depuis une ressource externe, par exemple :

<instance src="http://example.org/formulaire/gabarits/t21.xml"/>

Le document t21.xml contiendra alors les données comme ceci :

<data><L>640</L><l>480</l><h>8</h></data>

(La déclaration xmlns="" n'est pas nécessaires dans les instances externes, mais sa présence n'est pas non plus gênante.)

L'édition d'un document XML*

La possibilité de charger des instances externes représente un pouvoir immense. C'est parce que l'attribut ref des commandes de formulaire ne vous autorise pas à sélectionner uniquement un identificateur, comme l'attribut name de HTML, mais en fait n'importe quelle expression XPath. XPath vous permet de sélectionner n'importe quel élément ou attribut dans un document XML.

Cela signifie, quand vous aurez appris XPath, que vous pourrez renter n'importe quel document XML comme instance, même un document XHTML, lui lier des commandes et le soumettre. Par exemple, pour se lier à l'élément title dans un document XHTML, on peut employer :

<input ref="h:html/h:head/h:title">...

(C'est-à-dire, l'élément title dans l'élément head dans l'élément html, tous étant dans l'espace de nommage XHTML) ou encore :

<input ref="h:html/h:body/@class">...

Ce qui correspond à l'attribut class de l'élément body.

Supposons, par exemple, un atelier dont les heures d'ouvertures sont imprévisibles (cela dépend peut-être du temps) et le responsable souhaite avoir une page Web que les clients peuvent consulter afin de savoir si l'atelier est ouvert. Supposons que la page en question contienne dans l'élément body le seul paragraphe suivant :

<p>L'atelier est <strong>fermé</strong> aujourd'hui.</p>

Donc, plutôt que d'apprendre au personnel de l'atelier comment écrire en HTML pour mettre à jour le message, on peut simplement mettre en place un formulaire qui éditera la page :

<model>
   <instance   src="http://www.example.com/atelier/etat.xhtml"/>
   <submission action="http://www.example.com/atelier/etat.xhtml"
               method="put" id="changer"/>
</model
...
<select1 ref="/h:html/h:body/h:p/h:strong">
<label>L'atelier est maintenant :</label>
<item><label>Ouvert</label><value>ouvert</value></item>
<item><label>Fermé</label><value>fermé</value></item>
</select1>
<submit submission="changer"><label>OK</label></submit>

Remarquez, pour que cela fonctionne, que la page à changer doit être un document XHTML valide (pas un document HTML, car seul un document XHTML est aussi un document XML) et que votre serveur accepte la méthode put (ce n'est pas le cas de tous les serveurs).

La soumission

Les soumissions multiples*

HTML permet seulement la soumission de données à un seul serveur, d'une seule façon.

Au contraire, XForms permet d'avoir des commandes submit différentes liées à des éléments de soumission différents dans l'en-tête, afin de soumettre les données à des serveurs divers et de façons diverses.

Par exemple, depuis l'exemple du formulaire de recherche, on pourrait permettre à l'utilisateur de soumettre la chaîne de requête à des moteurs de recherche différents :

<model>
   <instance><data xmlns=""><q/></data></instance>
   <submission action="http://example.com/rechercher"
               method="get" id="com"/>
   <submission action="http://example.org/rechercher"
               method="get" id="org"/>
</model>

Le corps contiendrait alors :

<submit submission="org"><label>Recherche via example.org</label></submit>
<submit submission="com"><label>Recherche via example.com</label></submit>

Les méthodes de soumission

Tout comme avec HTML, il existe plusieurs façons de soumettre les données. Dans HTML, la soumission s'exprime au moyen de deux attributs : method et enctype ; dans Xforms, seul l'attribut method est utilisé :

Les méthodes de soumission équivalentes de HTML et XForms
HTML XForms
method="get" method="get"
method="post"
enctype="application/x-www-form-urlencoded"		 method="urlencoded-post"
method="post"
enctype="multipart/form-data"		 method="form-data-post"

Deux nouvelles méthodes de soumission apparaissent ; les plus intéressantes sont method='post', qui poste les résultats comme document XML, et method='put', qui place les résultats comme document XML. En voici un usage remarquable :

<submission action="file:resultats.xml" method="put"/>

Laquelle déclaration enregistre vos résultats dans la mémoire fichier locale au moyen du système file:.

Puisqu'on peut avoir plusieurs soumissions par formulaire, comme montré précédemment, cela signifie que, dans le cas d'un grand formulaire, on peut avoir des boutons Enregistrer sur le disque et Envoyer distincts.

La vie après la soumission*

Par défaut, lorsque les valeurs ont été soumises, le résultat renvoyé par le serveur remplace le document entier, comme avec HTML. Toutefois, il existe d'autres options, indiquées par l'attribut replace sur l'élément submission. La déclaration replace='instance' remplace seulement l'instance, la déclaration replace='none' laisse le formulaire tel quel sans le remplacer.

Par exemple, pour un formulaire de changement d'adresse bancaire, on peut fournir des boutons, l'un pour préremplir le formulaire avec le nom et l'adresse déduits du numéro de compte, l'autre pour soumettre les données modifiées :

<model>
    <instance><data xmlns="">
        <numerocompte/><nom/><adresse/>
    </data></instance>
    <submission method="get" action="http://example.com/preremplir"
                id="preremplir" replace="instance"/>
    <submission method="get" action="http://example.com/modifier"
                id="modifier" replace="none"/>
</model>
...
<input ref="numerocompte"><label>Numéro de compte</label></input>
<submit submission="preremplir"><label>Remplir</label></submit>
<input ref="nom"><label>Nom</label></input>
<textarea ref="adresse"><label>Adresse</label></textarea>
<submit submission="modifier"><label>Modifier</label></submit>

Le bouton Remplir remplacera l'instance par une nouvelle contenant les renseignements sur le titulaire du compte bancaire, qui sont maintenant modifiables ; le bouton Modifier renverra l'instance modifiée, en laissant le formulaire tel quel dans le navigateur, ce qui permet d'autres changements ou de saisir un nouveau numéro de compte pour un autre préremplissage.

La maîtrise des commandes

Dans HTML, on peut spécifier que les commandes soient inactives ou bien en lecture seule, toutefois, seul un script peut changer la propriété.

XForms permet de facilement contrôler ces propriétés et possède d'autres propriétés permettant de dire :

Remarquez, dans XForms, que c'est la valeur collectée qui possède la propriété, et non la commande, la propriété apparaissant néanmoins sur toutes les commandes liées à la valeur en question.

Ces propriétés utilisent un élément bind qui se place dans l'élément model. Pour utiliser l'élément bind, on doit déclarer explicitement l'élément instance.

Les commandes inactives

Pour désactiver une commande, on doit utiliser la propriété relevant. Par exemple, pour signifier que le remplissage d'un numéro de carte de crédit doit seulement se produire pour un achat à crédit, on peut écrire :

<model>
   <instance><data xmlns="">
      <montant/><methode/><cc/><expiration/>
   </data></instance>
   <bind nodeset="cc" relevant="../methode='credit'"/>
   <bind nodeset="expiration" relevant="../methode='credit'"/>
</model>

C'est une déclaration selon laquelle les champs cc et expiration sont seulement pertinents lorsque methode a la valeur "credit", elle sera de ce fait inactive pour les autres valeurs de methode. On doit écrire ../methode plutôt que methode, parce que, dans une propriété bind, on parle de la chose appelée par l'attribut nodeset (lequel peut lui-même être un élément structuré). C'est comme si on avait effectué un changement de répertoire vers cet élément. Si on avait juste écrit methode, cela se rapporterait à un élément enfant de cc, ou de expiration. On peut également utiliser un adressage absolu, comme /data/methode, qui produirait le même effet que ../methode dans ce cas.

Un navigateur est libre d'afficher les commandes inactives comme bon lui semble (et il peut aussi laisser ce soin à une feuille de style), sinon elles apparaîtront habituellement en grisé.

On pourrait écrire les commandes de la manière suivante (mais remarquez qu'aucune indication ne vient confirmer qu'elles peuvent être inactives, c'est-à-dire, aucune indication ne peut se déduire de la valeur auquelle elles se rapportent) :

<select1 ref="methode"><label>Méthode de paiement :</label>
   <item><label>Billets</label><value>billets</value></item>
   <item><label>Carte de crédit</label><value>crédit</value></item>
</select1>
<input ref="cc"><label>Numéro de carte :</label></input>
<input ref="expiration"><label>Date d'expiration :</label></input>

Si on utilisait une instance structurée, on pourrait simplifier comme ceci :

<model>
   <instance><data xmlns="">
      <montant/><methode/>
      <cc>
        <numero/><expiration/>
      </cc>
   </data></instance>
   <bind nodeset="cc" relevant="../methode='credit'"/>
</model>

Les commandes appellent ensuite les enfants de cc :

<input ref="cc/numero"><label>Numéro de carte :</label></input>
<input ref="cc/expiration"><label>Date d'expiration :</label></input>

On peut aussi effectuer un regroupement pour rétablir le contexte des attributs ref :

<group ref="cc">
   <input ref="numero"><label>Numéro de carte :</label></input>
   <input ref="expiration"><label>Date d'expiration :</label></input>
</group>

Les commandes en lecture seule

De la même façon que pour l'attribut relevant, on peut spécifier une condition selon laquelle une valeur est en lecture seule. Par exemple :

<model>
   <instance><data xmlns="">
      <variante>basique</variante><couleur>noire</couleur>
   </data></instance>
   <bind nodeset="couleur" readonly="../variante='basique'"/>
</model>

Dans cet exemple, la valeur par défaut de couleur est "noire", et elle ne peut pas se modifier si variante a la valeur "basique".

Les commandes obligatoires*

Une nouvelle fonctionnalité utile dans XForms c'est la possibilité de déclarer qu'une valeur doit être fournie avant que le formulaire ne soit soumis. Le cas le plus simple consiste simplement à dire qu'une valeur est toujours obligatoire. Par exemple, dans l'exemple du formulaire de recherche :

<model>
   <instance><data xmlns=""><q/></data></instance>
   <bind nodeset="q" required="true()"/>
   <submission .../>
</model>

Cependant tout comme les attributs readonly et relevant, on peut utiliser une expression XPath pour rendre une valeur obligatoire conditionnellement :

<bind nodeset="etat" required="../pays='USA'"/>

Laquelle déclaration dit que la valeur de etat est exigée lorsque la valeur de pays est "USA".

Le navigateur a toute latitude sur la manière d'annoncer qu'une valeur est obligatoire, il peut aussi permettre à l'utilisateur de le définir dans une feuille de style.

La propriété constraint*

Cette propriété permet d'ajouter des contraintes supplémentaires sur une valeur. Par exemple :

<bind nodeset="annee" constraint=". &gt; 1970"/>

Ceci contraint l'année après 1970. Remarquez l'utilisation par XPath du caractère point (.), dont la signification est cette valeur-ci. (Le caractère > doit s'écrire &gt; pour respecter les règles de XML, vous devez sans doute y être accoutumé).

La propriété calculate*

On peut indiquer qu'une valeur dans l'instance se calcule à partir d'autres valeurs. Par exemple :

<bind ref="volume" calculate="../longueur * ../largeur * ../hauteur"/>

Quand une valeur se calcule ainsi, elle passe automatiquement en lecture seule.

Nombre de fonctions sont disponibles, comprenant les fonctions arithmétiques, de manipulation de chaîne, de gestion de date et conditionnelles avec le mot-clé if.

Les types*

Une autre nouvelle fonctionnalité utile c'est la possibilité de typer une valeur. Le navigateur peut alors vérifier que les valeurs correspondent au type demandé.

Par exemple, si le formulaire de recherche n'est en réalité destiné qu'à rechercher des nombres (par exemple, dans une base de données de bogues), alors il suffit seulement d'ajouter :

<bind nodeset="q" type="xsd:integer"/>

Ceci empêchera la soumission de la valeur à moins que ce ne soit un entier.

(Il faudra alors rajouter xmlns:xsd='http://www.w3.org/2001/XMLSchema' à l'élément racine.)

Si on souhaite collecter l'URL de la page d'accueil de quelqu'un, alors on peut spécifier :

<bind nodeset="accueil" type="xsd:anyURI"/>

Vous constaterez que certains agents utilisateurs ont des comportements particuliers lorsqu'ils reconnaissent le type de donnée d'une valeur. Par exemple, s'ils savent que la valeur est une date, ils font jaillir un calendrier au lieu de vous obliger à saisir les caractères composant la date.

Vous pouvez employer nombre de types intégrés utiles, comprenant :

La combinaison des propriétés

Si on a plusieurs liaisons se rapportant à la même valeur, on peut les combiner :

<bind nodeset="q" type="xsd:integer" required="true()"/>

Plusieurs formulaires dans un document

Pour avoir plusieurs formulaires dans un document, on a besoin d'un élément model par formulaire et on doit alors identifier le formulaire auquel chaque commande se rapporte. Cela se fait au moyen d'un attribut id sur chaque élément model et au moyen d'un attribut model sur chaque commande :

<model id="recherche">
   <instance><data xmlns=""><q/></data></instance>
   <submission id="s" .../>
</model>
<model id="identifiant">
   <instance><data xmlns=""><utilisateur/><motdepasse/></data></instance>
   <submission id="l" .../>
</model>
...
<input model="recherche" ref="q"><label>Trouver</label></input>
<submit submission="s"><label>Chercher</label></submit>
...
<input model="identifiant" ref="utilisateur"><label>Nom d'utilisateur</label></input>
<secret model="identifiant" ref="motdepasse"><label>Mot de passe</label></secret>
<submit submission="l"><label>S'identifier</label></submit>

L'élément bind au lieu de l'attribut ref

Si un élément bind est présent dans l'élément model, on peut l'appeler depuis la commande, au lieu de passer par la valeur d'instance. Cela permet de changer les détails de la structure de l'instance sans devoir modifier les commandes. Cela veut également dire que l'on n'a pas besoin de spécifier quel élément model est concerné :

<model>
   <instance><data xmlns=""><q/></data></instance>
   <submission id="s" .../>
   <bind id="requete" nodeset="q" required="true()"/>
</model>
...
<input bind="requete"><label>Chercher</label></input>

(Remarquez que l'attribut bind correspond à l'appel d'un attribut id sur un élément bind ; ce n'est pas une expression XPath.)

Les fonctionnalités absentes de cette présentation

Comme indiqué en introduction, ce document n'est pas un tutoriel de XForms. Voici les fonctionnalités principales non traitées ici :