Utiliser la méthode Ajax pour les formulaires HTML classiques, permet de combler les lacunes de ceux-ci. Par exemple, avec de l'Ajax senteur citron, on peut :

  • Recharger le contenu de certains contrôles (des listbox par exemple) en fonction de valeurs selectionnées dans d'autres. Exemple : on selectionne un département dans un listbox, et une listbox des villes de ce département est remplie au moyen de xmlhttprequest, ce qui évite de recharger la page complète.
  • Envoyer le contenu du formulaire avec xmlhttprequest, et rester sur le formulaire : on peut ainsi faire des sauvegardes des données saisies quand on veut, tout en continuant d'éditer le formulaire (comme dans un logiciel classique quand on fait des CTRL+S réguliers).
  • Édition séquentielle d'un ensemble d'enregistrement. Par exemple, on peut imaginer une application qui permette d'éditer un ensemble de produits les uns aprés les autres, afin de mettre à jour le stock par exemple. On peut alors utiliser ajax pour envoyer les valeurs du produit en cours d'édition pour le sauvegarder sur le serveur, récupérer les valeurs du produit suivant et remplir les champs du formulaire avec celles-ci : pas besoin de recharger la page entière.

N'oublions pas non plus les méthodes classiques DHTML (Javascript + DOM) pour :

  • vérifier la validité des données saisies avant envoi de celles-ci pour enregistrement, et afficher les éventuels messages d'erreurs, mettre en avant au moyen de signes visuels les champs fautifs etc.
  • simuler un système d'onglet, afin d'apporter une meilleure ergonomie pour les gros formulaires
  • réagir à certaines saisies de valeurs, pour activer ou désactiver d'autres champs de saisies
  • ajouter dynamiquement des nouveaux champs de saisie

Avec grand renfort de ligne de code Javascript, on arrive donc à faire des formulaires "potables", comme l'exige bon nombre d'applications professionnelles. Mais il faut reconnaitre qu'il y a un léger souci : ce sont ces tas de lignes de codes à écrire, avec tous les risques de bugs que cela engendre, la complexité que cela ajoute, surtout avec Ajax.

Heureusement, il y a XForms.

XForms permet de faire tout ceci... sans aucune ligne de code javascript ! Juste avec quelques balises déclaratives, et avec l'aide de CSS pour l'aspect visuel.

Tout d'abord, il faut savoir qu'un formulaire XForms est composé de deux choses :

  1. la partie qui déclare la structure des données, leur type et restrictions (balises <bind>), ainsi que la façon dont elles seront envoyées (balise <submission>). Cette partie est encapsulée dans une balise <model>.
  2. l'ensemble des champs de saisie, repartis dans le document qui sert de support au formulaire : cela peut être un document xhtml, XUL etc.. Un formulaire XForms est toujours embarqué dans un document.

Cette séparation entre la déclaration des données ("l'instance") et les champs de saisies permet une plus grande souplesse. En effet, bien que cela soit facultatif, il est possible de décrire dans une balise <instance> le document xml qui sera envoyé au serveur.

 <model>

   <instance><personne xmlns=""><nom/><prenom/></personne></instance>
   <submission action="http://example.com/carnetadresse/person/save" method="post" id="p"/>
 </model>

Si on saisie "Laurent" et "Jouanneau" respectivement dans les champs de saisie du prénom et du nom (que l'on verra plus tard), alors le serveur reçevra le contenu xml :

 <personne xmlns=""><nom>Jouanneau</nom><prenom>Laurent</prenom></personne>

Cela veut dire que l'on peut adapter le formulaire trés facilement en fonction du service web vers lequel on soumet le contenu saisie, sans toucher aux balises de champs de saisies (si on déclare comme il faut le formulaire, mais je ne vais pas rentrer dans les détails). Mieux : ce contenu xml peut être un fichier entier dont seulement une partie sera modifié par le formulaire, comme par exemple... une page xhtml !

 <model>
   <instance src="http://example.com/carnetadresse/laurentjouanneau" />
   <submission action="http://example.com/carnetadresse/laurentjouanneau" method="post" id="p"/>
 </model>

En clair, avec un formulaire XForms, on peut modifier tout ou partie d'un fichier xml existant (ou le créer). Il faut bien sûr que coté serveur, il y ait ce qu'il faut pour prendre en compte les requêtes de type POST sur une url précise, comme des scripts PHP (sachant gérer pourquoi pas du RESTfull). Voilà de quoi se faire un CMS à peu de frais !

Vous aurez remarqué que contrairement à la méthode Ajax, vous n'avez pas de manipulation DOM à effectuer, pas de construction d'un contenu XML à faire, et ni bien sûr de manipulation de cet objet xmlhttprequest qui parait du coup bien compliqué à utiliser ;-). Zéro ligne de code vous dis-je. Vous déclarez, et c'est prêt !

En parlant justement des moyens d'envoi des données, voyons un peu cette balise <submission> :

  • vous pouvez indiquer les methodes http : GET, PUT, POST.
  • vous pouvez aussi indiquer d'autres méthodes : urlencoded-post ou form-data-post. Les données seront envoyées dans les formats classiques plutôt qu'en xml (en php, on recuperera alors les données via $_POST plutôt que dans $HTTP_RAW_POST_DATA ).
  • vous pouvez mettre plusieurs balises <submission>, pour envoyer le contenu vers differentes URL ou l'envoyer de différente façon (selon le bouton cliqué par l'utilisateur par exemple).
  • vous pouvez indiquer ce qu'il faut faire aprés soumission des données :
    • replace='instance' indique que les données en retour remplaceront l'instance, donc concrétement, cela rempli le formulaire avec les données reçues.
    • replace='none' indique que rien n'est fait aprés l'envoi.
    • replace='all' indique d'agir comme dans les formulaires html : le contenu reçu remplace le document courant.

En ce qui concerne les champs de saisie en eux même. On retrouve des balises du même style qu'en HTML: <input>, <submit>,<textarea>, <select1> (choix unique : bouton radio, combobox), <select> (choix multiples : checkbox, listbox..), <upload>, <secret>, <output> (affichage sans saisie), <range> (curseur). Pour chacun de ces champs, on peut spécifier un libéllé (balise <label>), un message d'aide, un message en cas d'erreur, tout ceci s'affichant automatiquement.

Il est possible de regrouper les champs de saisies dans des "panneaux" (balises <switch>, <case> et <toggle>), dont un seul sera affiché à un instant t (et donc faire un formulaire de type "assistant" ou avec des onglets). Avec la balise <repeat>, on peut répéter un ou plusieurs champs de saisie, en fonction des données du formulaire ou des actions de l'utilisateur.

Une particularité de XForms est de pouvoir déclarer quelle action faire sur des évènements précis survenant sur les champs de saisie. XForms possèdent en effet tout un ensemble d'évènements spécifiques au cours desquels il est possible de réagir (dans la plupart des cas, sans faire appel à javascript). On peut dire par exemple assez simplement que tel champs sera désactivé lorsque l'utilisateur aura choisi telle valeur dans un autre.

Enfin, l'autre atout de XForms, c'est la validation des données. Une bonne manière de faire est d'utiliser les balises <bind> que l'on placera dans <model>. Ces balises permettent de spécifier quel est le format attendu sur telle donnée de l'instance, quelles sont les restrictions (intervalle de valeurs par exemple), les calculs à faire une fois la donnée saisie etc.. Et rattacher ces bind aux champs de saisies. Ainsi, si on tape une mauvaise valeur, l'utilisateur est automatiquement averti. Le developpeur n'a quasiement rien à faire, sinon à indiquer le format ou type attendu, les éventuels messages d'erreurs personnalisés, et pourquoi pas styler le controle trés simplement grâce à des pseudos-classes CSS3 :

#nom:invalid { background-color:red; color:blank; }

Le contrôle qui a pour id "nom" aura un fond rouge et une écriture blanche si son contenu est invalide. Pas de setAttribute('class','invalid') ou autre manipulation DOM à faire.

Je vais arrêter cette introduction là. Il y a beaucoup trop de choses encore à dire sur XForms tellement le format est riche. D'ailleurs certains se plaindront sûrement de la complexité (relative à mon sens) de XForms par rapport aux formulaires HTML. Mais à y regarder de plus prés, une fois acquis les bases (qui prennent moins de temps que d'apprendre Ajax, DOM, Javascript &cie), on arrive déjà à faire rapidement des formulaires aussi puissant que ceux en HTML+DHTML+Ajax.

Pour en savoir plus, vous pouvez aller lire cet excellent tutoriel d'introduction sur XForms pour ceux qui ont l'habitude des formulaires HTML. Je précise d'ailleurs que XForms est une recommandation du W3C (dont vous pouvez lire la seconde édition des spécifications, publiée en mars dernier), et qu'il existe des plugins pour IE, une extension pour Firefox, et même une implementation en Flash de XForms. On peut donc utiliser XForms sans trop de problème dans les applications web évoluées.

(Voir aussi la page XForms sur xulfr.org, avec des liens vers des exemples que vous pouvez tester aprés installation de l'extension XForms dans Firefox)