2.1 Un exemple

Selon l'approche XForms, les formulaires se composent d'une section qui décrit ce que fait le formulaire, qu'on appelle le modèle XForms, et d'une autre qui décrit comment le formulaire doit être présenté.

Prenons un formulaire de commerce électronique simple qui pourrait être restitué comme suit :

Clairement, la collecte concerne une valeur représentant le moyen de paiement employé, espèces ou carte de crédit, et s'il s'agit d'une carte de crédit, son numéro et sa date d'expiration.

On peut représenter cette collecte dans un élément XForms model, lequel, dans XHTML, serait typiquement contenu dans la section head :

<xforms:model>
  <xforms:instance>
    <ecommerce xmlns="">
      <methode/>
      <numero/>
      <expiration/>
    </ecommerce>
  </xforms:instance>
  <xforms:submission action="http://example.com/soumettre"
     method="post" id="soumission" includenamespaceprefixes=""/>
</xforms:model>

Cette déclaration annonce simplement que l'on collecte trois bouts d'information (remarquez que rien n'est dit, pour l'instant, à propos de leurs types), lesquels seront soumis en utilisant l'adresse URL de l'attribut action.

XForms 1.0 définit un ensemble de commandes de formulaire, neutre vis-à-vis des appareils et indépendant de la plateforme, qui convient pour une utilisation générale. Les commandes sont liées au modèle XForms via le mécanisme de liaison XForms, dans ce cas simple, au moyen de l'attribut ref sur les commandes. En XHTML, ce balisage apparaîtrait normalement dans la section body (remarquez que le préfixe d'espace de nommage XForms est ici intentionnellement déclaré implicite) :

<select1 ref="methode">
  <label>Choix mode de paiement :</label>
  <item>
    <label>Espèces</label>
    <value>espèces</value>
  </item>
  <item>
    <label>Crédit</label>
    <value>crédit</value>
  </item>
</select1>
<input ref="numero">
  <label>Numéro carte de crédit :</label>
</input>
<input ref="expiration">
  <label>Date d'expiration :</label>
</input>
<submit submission="soumission">
  <label>Envoyer</label>
</submit>

Notez que cette conception présente les caractéristiques suivantes :

• L'interface d'utilisateur n'est pas codée explicitement pour utiliser des boutons radios. Des appareils différents (tels que des navigateurs vocaux) peuvent restituer le concept de sélectionnez un de façon appropriée.

• Les commandes de formulaire ont toujours des étiquettes qui leur sont directement associées comme sous-élément : cette caractéristique clé est destinée à améliorer l'accessibilité.

• Il n'y a pas besoin d'un élément form englobant comme dans HTML. (cf. le chapitre 2.4 Des documents avec plusieurs formulaires pour des précisions sur la façon de créer des formulaires multiples sur un document).

• Le balisage de définition des commandes de formulaire a été simplifié par rapport aux formulaires HTML.

Le fait de pouvoir relier des commandes de formulaire au modèle de cette manière simplifie l'intégration de XForms à d'autres langages hôtes, car on peut utiliser n'importe quel balisage de commande de formulaire pour la liaison au modèle.

2.2 La fourniture des données d'instance XML

Le processeur XForms peut directement soumettre les données collectées sous forme XML. Dans l'exemple, les données soumises auraient cet aspect :

<ecommerce>
  <methode>cc</methode>
  <numero>1235467789012345</numero>
  <expiration>2001-08</expiration>
</ecommerce>

Le traitement XForms assure le suivi de l'état du formulaire partiellement rempli au travers des ces données d'instance. Les valeurs initiales des données d'instance peuvent être fournies ou laissées vides comme dans l'exemple. L'élément instance contient essentiellement un squelette de document XML qui est mis à jour au fur et à mesure que l'utilisateur remplit le formulaire. Il donne à l'auteur le contrôle total de la structure des données XML soumises, y compris l'information d'espace de nommage. Lors de la soumission du formulaire, les données d'instance sont sérialisées comme document XML. Voici une autre version de l'exemple précédent :

<xforms:model>
  <xforms:instance>
    <paiement methode="cc" xmlns="http://commerce.example.com/paiement">
      <numero/>
      <expiration/>
    </paiement>
  </xforms:instance>
  <xforms:submission action="http://example.com/soumettre"
     method="post" includenamespaceprefixes="#default"/>
</xforms:model>

Auquel cas, les données soumises auraient cet aspect :

<paiement methode="cc" xmlns="http://commerce.example.com/paiement">
  <numero>1235467789012345</numero>
  <expiration>2001-08</expiration>
</paiement>

Ce modèle possède des caractéristiques dignes d'être soulignées :

• Il y a une grande flexibilité dans la structure des données d'instance XML, dont l'utilisation d'attributs. Notez que l'on utilise des espaces de nommage XML et qu'un élément d'emballage choisi par l'auteur du modèle contient les données d'instance ;

• Les éléments vides numero et my:paiement servent d'éléments fictifs dans la structure XML : ils seront remplis par les données de formulaire fournies par l'utilisateur ;

• La commande de formulaire reçoit une valeur initiale ("cc") issue des données d'instance, ici un attribut method. Dans le code XML soumis, cette valeur initiale sera remplacée par l'entrée d'utilisateur si l'utilisateur change la commande de formulaire affichant cette donnée.

Pour relier ces données d'instance aux commandes de formulaire, il faut changer les attributs ref des commandes de formulaire, afin qu'ils pointent vers la partie convenable des données d'instance, en utilisant des expressions de liaison :

... xmlns:my="http://commerce.example.com/paiement"
  ...
  <xforms:select1 ref="@methode">...</xforms:select1>
  ...
  <xforms:input ref="my:numero">...</xforms:input>
  ...
  <xforms:input ref="/my:paiement/my:expiration">...</xforms:input>

Les expressions de liaison se fondent sur le langage XPath [XPath 1.0], y compris l'emploi du caractère arobase @ pour appeler des attributs, comme c'est le cas ici. Remarquez que, pour les besoins de l'illustration, les deux premières expression utilisent le nœud de contexte XPath, lequel indique implicitement l'élément de niveau supérieur (ici l'élément my:paiement). La troisième expression montre un chemin absolu.

2.3 La contrainte des valeurs

XForms permet la validation des données au fur et à mesure du remplissage du formulaire. En l'absence d'information spécifique concernant les types des valeurs collectées, toutes les valeurs sont renvoyées en tant que chaînes, mais il est possible d'assigner des types aux valeurs dans les données d'instance. Dans cet exemple, l'élément numero ne devrait accepter que des chiffres et avoir entre 14 et 18 chiffres, et l'élément expiration ne devrait accepter que des combinaisons mois/date valides.

En outre, les commandes de formulaires numero et expiration, renseignant sur la carte de crédit, ne sont pertinentes que pour le choix "cc" de l'attribut methode, et elles sont obligatoires dans ce cas.

En définissant un composant supplémentaire, des propriétés d'élément de modèle, les auteurs peuvent inclure des informations de validation déclaratives riches dans les formulaires. Ces informations peuvent provenir de schémas XML tout comme d'ajouts propres à XForms, ainsi l'élément relevant. Ces propriétés apparaissent sur les éléments bind, tandis que les contraintes de schéma s'expriment dans un fragment de schéma XML direct ou bien externe. Par exemple :

... xmlns:my="http://commerce.example.com/paiement"...
        
  <xforms:model>
    ...
    <xforms:bind nodeset="/my:paiement/my:numero"
                 relevant="/my:paiement/@methode = 'cc'"
                 required="true()"
                 type="my:numerocc"/>
    <xforms:bind nodeset="/my:paiement/my:expiration"
                 relevant="/my:paiement/@methode = 'cc'"
                 required="true()"
                 type="xsd:gYearMonth"/>
    <xsd:schema ...>
      ...
      <xsd:simpleType name="numerocc">
        <xsd:restriction base="xsd:string">
          <xsd:pattern value="\d{14,18}"/>
        </xsd:restriction>
      </xsd:simpleType>
      ...
    </xsd:schema>
  </xforms:model>

2.4 Des documents avec plusieurs formulaires

Le traitement XForms ne fixe aucune limite au nombre de formulaires qui peuvent être placés dans un seul document conteneur. Lorsqu'un seul document contient plusieurs formulaires, chaque formulaire utilisera un élément model avec un attribut id, de sorte qu'on puisse les appeler depuis ailleurs dans le document conteneur.

En outre, les commandes de formulaire devraient indiquer quel élément model contient les données d'instance auxquelles elles se lient. On réalise cette opération au travers d'un attribut model appartenant à la catégorie des attributs de liaison. Si aucun attribut model n'est indiqué sur l'élément de liaison, on utilisera l'attribut model de l'élément de liaison ancêtre le plus proche, et sinon, le premier modèle XForms dans l'ordre du document. Cette technique, appelée résolution dans la visibilité, est fréquemment employée dans XForms.

L'exemple suivant ajoute un sondage d'opinion à notre formulaire de commerce électronique ;

<xforms:model>
  <xforms:instance>
    ...données d'instance de paiement...
  </xforms:instance>
  <xforms:submission action="http://example.com/soumettre" method="post"/>
</xforms:model>
        
<xforms:model id="opinion">
  <xforms:instance>
    <utilite/>
  </xforms:instance>
  <xforms:submission id="soumettreopinion" .../>
</xforms:model>

En outre, le balisage suivant apparaîtrait dans la section du corps du document :

<xforms:select1 ref="/utilite" model="opinion">
  <xforms:label>Avez-vous trouvé cette page utile ?</xforms:label>
  <xforms:item>
    <xforms:label>Pas du tout utile</xforms:label>
    <xforms:value>0</xforms:value>
  </xforms:item>
  <xforms:item>
    <xforms:label>Peu utile</xforms:label>
    <xforms:value>1</xforms:value>
  </xforms:item>
  <xforms:item>
    <xforms:label>Utile en quelque sorte</xforms:label>
    <xforms:value>2</xforms:value>
  </xforms:item>
  <xforms:item>
    <xforms:label>Très utile</xforms:label>
    <xforms:value>3</xforms:value>
  </xforms:item>
</xforms:select1>
        
<xforms:submit submission="soumettreopinion">
  <xforms:label>Envoyer</xforms:label>
</xforms:submit>

La différence principale ici c'est l'emploi de l'attribut model="opinion" pour identifier l'instance. Remarquez que l'élément submit se rapporte à l'élément submission par un ID et ne nécessite pas d'attribut de liaison.

On trouvera des exemples XForms plus complexes dans G Exemples XForms complets.