L’utilisateur est amené à entrer plusieurs expressions XPath lors de l’édition de son formulaire, que ce soit pour le nodeset ou pour les champs “required”, “relevant”, “readonly” et “constraint”. Afin d’avoir au final un formulaire avec le moins d’aberrations possibles, il est bien de pouvoir contrôler lors de l’édition si l’expression XPath entrée est valide ou non. Il existe en javascript une méthode qui permet d’évaluer une telle expression et une exception est levée dans le cas où l’expression présente une erreur.

A chaque fois que l’utilisateur renseigne un de ces champs, une méthode est donc tout d’abord appelée afin de vérifier l’expression et dans le cas où elle est correcte, l’expression est insérée dans le bon attribut de l’objet courant.

Au départ j’ai offert cet outil de manière automatique et transparente aux yeux de l’utilisateur mais finalement je me suis rendu compte d’un problème. La norme XForms propose des fonctions (très pratiques) utilisables dans des expressions XPath et il est bien clair que lors de la validation de l’expression, la méthode javascript va considérer l’expression comme invalide car elle contient une fonction que la norme XPath de définit pas! Pour remédier à ce problème, j’ai à présent ajouté sur l’interface une checkbox qui permet d’activer/désactiver la validation XPath. Typiquement lorsque l’utilisateur saura qu’il va entrer une expression qui fait appel à une fonction spécifique à la norme XForms, il faudra alors qu’il veille à ce que la fonction de validation soit désactivée afin que son expression soit prise correctement en compte. Cette façon de faire est certes moins souple car elle nécessite une action de l’utilisateur mais ce choix permet tout de même de conserver cet outil de validation qui peut s’avérer être fort pratique dans certains cas.

J’ai encore quelques problèmes avec les expressions XPath. J’ai lu qu’il fallait éviter d’utliser les signes ‘<’ et ‘>’ et d’opter plutôt pour ‘&gt;’ et ‘&lt;’. Cependant lorsque un des champs d’un composant contient un de ces deux derniers, le formulaire n’est pas créé correctement sur le serveur. En effet, l’écriture du fichier se termine prématurément lorsque le caractère ‘&’ est rencontré…je me demande si ce problème vient du script PHP ou alors à quel niveau ça coince.

J’ai à présent intégré l’outil permettant de fusionner plusieurs cellules verticalement. Il a fallu que j’adapte le code en conséquence d’ailleurs.

En ce qui concerne le spanning vertical, j’ai buté pendant un moment sur un problème qui n’en était pas vraiment un : lors de la fusion de 2 ou plusieurs cellules verticalement, rien ne se passait au niveau du formulaire. Pourtant, une fois le formulaire enregistré sur le disque et affiché dans un browser, le spanning s’affichait tout à fait correctement! Preuve donc que le code que j’avais réalisé jusque là était correct!

J’ai mis alors un moment à comprendre d’où provenait le problème. Il s’avère finalement que ce phénomène vient du fait que le tableau est créé dynamiquement (lors du chargement de la page) et que ce tableau ne se trouve pas en dur dans le code XHTML! Le simple fait de mettre le tableau en dur dans le code “résout” le problème…mais je ne suis pas convaincu de cette option car le but était justement de pouvoir créer un tableau dynamiquement en spécifiant le nombre de colonnes et de lignes. N’étant pas certain que le fait de mettre le code du tableau en dur dans le fichier soit une bonne solution, je laisse cette partie de côté pour l’instant.

Cependant, le plus étrange c’est que le spanning horizontal fonctionne, lui, très bien même sur un tableau généré dynamiquement!

L’éditeur permet à présent de placer tous les types de composants que je m’étaient fixés. Je ne suis cependant pas pleinement satisfait de l’aspect visuel de certains, je pense surtout au boutons radios et cases à cocher. Etant donné que leurs valeur proviennent d’un fichier externe que l’utilisateur doit définir comme propriété du composant et de part le problème avec le binding dynamique, l’utilisateur n’a pas la possibilité de voir en temps réel le nombre de boutons radio ou cases à cocher qui s’afficheront dans son formulaire! Uniquement un seul bouton radio ou une seule case à cocher sont en effet affichés, juste dans le but de montrer à l’utilisateur qu’à cet endroit viendront se greffer un ensemble de composants dépendant de la liste contenue dans le fichier externe.

Cela dit, je doute fort que je pourrai rendre cet aspect meilleur qu’actuellement. En effet, tout le problème réside dans ce problème de binding!