Summary

  • Le client choisit les espèces : les questions sur sa carte quittent l’écran et le dossier envoyé. XForms 1.0, Recommandation du W3C publiée le 14 octobre 2003, rendait ce résultat possible en séparant modèle, données XML et interface.
  • Dans l’exemple de paiement de la Recommandation, numéro et expiration de carte ne deviennent pertinents que pour le crédit. La propriété relevant agit sur les commandes disponibles et sur les nœuds effectivement sérialisés lors de l’envoi.

Au comptoir, vous annoncez que vous payez en espèces. Le vendeur prend les billets, puis réclame le numéro de votre carte et sa date d’expiration. « Pourquoi ? » Il montre les deux lignes du formulaire. Sur un site, le même entêtement se joue au clavier : après « espèces », la touche Tab vous conduit vers un numéro de carte que vous n’avez aucune raison de donner. La solution de 2003 consistait à faire écouter la réponse au formulaire avant qu’il lance la question suivante.

La Recommandation XForms 1.0 du W3C, datée du 14 octobre 2003, décompose le formulaire en trois parties. Le modèle exprime la structure et les règles. L’instance garde les valeurs recueillies dans un document XML en cours de remplissage. L’interface présente des commandes auxquelles une personne peut répondre. Une liaison, souvent indiquée par ref, rattache chaque commande au nœud de l’instance qu’elle sert. Le dessin du formulaire cesse ainsi de porter à lui seul toute la signification de la transaction.

Le cas pratique de la spécification concerne le mode de paiement. Une instance possède un squelette pour la méthode, le numéro de carte et l’expiration ; un élément submission indique où envoyer le résultat. Dans l’interface, select1 propose de choisir entre espèces et crédit, tandis que deux commandes input recueillent les renseignements de carte. Chaque commande a un élément label qui lui est propre. Le processeur suit les valeurs au fil de la saisie et, au moment prévu, sérialise l’instance en XML.

select1 dit simplement : choisissez une option. Sur un écran, cela peut prendre une forme visuelle. Dans une interface vocale, la même demande se dit à haute voix. La liaison garde le fil entre cette demande et la donnée qu’elle modifie. Le formulaire peut changer de tenue sans perdre l’adresse de la réponse.

Vient alors la petite victoire des espèces. Les liaisons du numéro et de l’expiration portent une expression relevant. Elle vérifie si la méthode vaut cc, le code choisi pour le crédit. Pour ce mode de paiement, required réclame les deux valeurs. Un type précise leur forme : le numéro suit un motif de 14 à 18 chiffres, l’expiration le type xsd:gYearMonth.

Le client passe du crédit aux espèces ? Le processeur réévalue la condition. Le numéro et la date quittent l’ensemble des questions utilisables. La décision vient du modèle et suit les données, quel que soit l’habillage de l’écran.

La définition de relevant dans XForms 1.0 agit à deux endroits. Sur l’écran, la commande liée à une donnée non pertinente devient indisponible : on ne peut ni y saisir une valeur, ni y déplacer le focus. Dans le document envoyé, le nœud correspondant est exclu de la sérialisation. Le client qui choisit les espèces ne voit plus de demande de carte ; l’XML transmis n’emporte pas non plus ces nœuds.

Supposons qu’une carte ait été saisie, puis que le client change d’avis et paie comptant. Son numéro reste dans la mémoire du formulaire. Une simple retouche de l’écran fermerait la case comme on ferme un tiroir sans regarder ce qu’il contient. La règle de XForms atteint aussi le résultat : les nœuds devenus non pertinents sortent de l’XML envoyé. Le changement de paiement retire donc une question du parcours au clavier et les données correspondantes du colis destiné au serveur. Le modèle décide, l’interface change et l’instance suit.

Le communiqué du W3C présentait cette architecture comme une distinction entre la finalité, la présentation et le résultat du formulaire. Dans son exemple de paiement, la finalité est de connaître le mode choisi, la présentation peut changer selon l’appareil et le résultat prend la forme d’un document XML. La meilleure politesse du système tient dans une règle très simple : la question qui ne vous concerne plus vous laisse tranquille.