TD-Conception et implémentation d’un outil d’édition de formulaire à base de la norme XForms

Il est temps de penser au rapport…

atuscher — Mon, 27 Nov 2006 19:44:18 +0000

J’ai terminé à présent de commenter tout le code et j’ai également apporté quelques modifications au niveau de la structure, il restait en effet quelques aberrations que j’avais laissé passer.

Il faut à présent que je me concentre sur la rédaction du rapport qui, mine de rien, demande un travail conséquent! Il reste en effet une dizaine de jours avant de rendre tout le travail…

Dernières retouches du code

atuscher — Fri, 24 Nov 2006 17:19:36 +0000

Ces deux derniers jours ont été utilisés pour fignoler encore un petit peu le code, le rendre plus lisible et lui ajouter des en-têtes, commentaires, etc…

Bien que n’ayant pas forcément eu tout ce que je m’étais fixé au départ, il faudra bien y mettre un point final car il reste encore une importante partie à réaliser : la rédaction du rapport.

Implémentation (partielle) du bouton XForms

atuscher — Wed, 22 Nov 2006 17:39:39 +0000

Je me suis en fait rendu compte que l’implémentation du bouton n’était pas du tout terminée vu qu’aucune action ne lui était associée une fois placé! J’ai mis alors un moment à comprendre un peu mieux le fonctionnement de ce composant et le problème majeur est qu’il y a plein de moyen différent de lui intégrer une action. En effet, un clic sur le bouton fait appel à un des événements que la norme XForms définit…du coup il s’avère être très compliqué à implémenter complétement. J’ai alors opté pour la solution suivante : l’interface ne propose d’associer un bouton qu’à un seul type d’événement, l’événement “setvalue” qui permet de changer la valeur d’un champ lorsque l’utilisateur clique sur le bouton. Cet événement attend une expression XPath et peut par exemple tout à fait donner une valeur par défaut à un composant, effacer son contenu ou même effectuer des calculs (ajouter une unité à un champ qui contient un chiffre par exemple).

J’ai opté pour ce choix parce que cet événement est relativement intéressant et permet de faire pas mal de choses. Faute de temps je doute que je puisse en faire beaucoup plus sur le bouton XForms…comme dit précédemment il est difficile d’être tout à fait exhaustif!

Validation des XPath

atuscher — Tue, 21 Nov 2006 15:43:43 +0000

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 ‘>’ et ‘<’. 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.

Refactorisation du code

atuscher — Thu, 16 Nov 2006 16:52:01 +0000

Ces deux derniers jours je n’ai pas ajouté grand chose de visuel mais j’ai surtout travaillé sur la conception. J’ai par exemple factorisé des bouts de codes récurrents ou alors rendu l’utilisation de certaines méthodes plus souples en se servant typiquement de constantes globales à toute l’application. A présent une constante contient par exemple le nom du dossier correspondant à l’endroit où les différents fichiers uploadés (formulaire final compris) seront enregistrés sur le serveur. Ainsi, le fait de changer le chemin n’interviendra plus qu’à un seul endroit dans le code!

Nouvel outil : déplacer un composant

atuscher — Tue, 14 Nov 2006 15:36:24 +0000

J’ai estimé qu’il serait une bonne idée de pouvoir déplacer ces composants dans le tableau une fois ceux-ci disposés. En effet, il suffit que l’utilisateur l’ait mis au mauvais endroit pour qu’il doive le supprimer et en recréer un dans la bonne cellule. Ceci n’étant clairement pas souple et pratique, il était donc important de lui offrir cette possibilité! L’utilisateur peut à présent choisir une nouvelle option dans les outils en marge de l’éditeur. Il doit alors tout d’abord cliquer sur la cellule qui contient un composant pour le sélectionner puis cliquer sur une autre cellule (vide!) pour le déplacer dans celle-ci.

Spanning horizontal intégré mais problèmes avec spanning vertical

atuscher — Tue, 14 Nov 2006 15:32:07 +0000

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!

Tous les composants sont implémentés

atuscher — Thu, 09 Nov 2006 22:35:54 +0000

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!

Implémentation des listes

atuscher — Tue, 07 Nov 2006 16:27:35 +0000

L’éditeur permet à présent de placer deux nouveaux composants : les combobox et les listbox. La majeur différence de ces composants par rapport aux autres est qu’ils contiennent une liste de valeurs qui doivent être affichées et proposées à l’utilisateur. Cette liste de valeur n’est cependant pas entrée dans l’éditeur directement mais elle existe dans un fichier XML externe. L’utilisateur a alors la possibilité de joindre un de ces fichiers (qu’il aura créé au préalable), ce qui aura pour effet de l’uploader sur le serveur et également d’ajouter les bons tags dans le formulaire afin que les données puissent être correctement récupérées une fois que le formulaire final sera ouvert et affiché dans le browser.

Séance du 3 novembre 2006

atuscher — Tue, 07 Nov 2006 16:21:52 +0000

J’ai retrouvé Stéphane à St Roch où nous avons passé la matinée à discuter de mon avancement et des quelques problèmes que j’ai rencontrés. Je lui ai typiquement évoqué le fait que le binding ne soit pas effectué dynamiquement…il pense que le problème vient d’une fonction automatique de “refresh” qui (pour des raisons d’optimisation certainement) ne recharge que le corps (body) et non pas tout le document (head inclus)! Du coup, les éléments bind dans le tag head ne sont pas pris en compte! Pour l’instant je continue donc sur la solution que j’ai commencée (voir quelques messages plus tôt) et si j’ai le temps je reverrai tout ça si une autre possibilité se montre…

Dans l’ensemble, le travail que j’ai accompli a satisfait Stéphane. Dans l’état actuel je pouvais faire une démonstration de placement de composants (sauf radio, checkbox et listbox), la modification des propriétés et la création des fichiers.

Deux points seront encore à effectuer :

Créer une autre feuille de style complètement dissociée de celle utilisée pour l’édition. Cette deuxième feuille de style sera utilisée sur le formulaire final créé
Ajouter un bouton de “preview” à l’interface qui permet de visualiser l’état effectif du formulaire en cours de création. Cette option serait principalement utile afin de compenser le problème avec les bindings dynamiques. L’idée serait de poster sur le serveur l’état du formulaire en l’état actuel de modification et de l’afficher dans le browser. L’utilisateur a ainsi mieux la possibilité de voir à quoi ressemblera son formulaire (avec par exemple les listes déroulantes qui contiennent les données du fichier externe spécifié, etc)