11.01.06
Binding des ressources et création des fichiers
A présent le programme permet de constituer de A à Z un formulaire avec ses différentes ressources (label, hint, help, alert). Comme dit précédemment, lors de la création du formulaire les différentes ressources sont incrustées dans les composants (ceci afin que l’utilisateur puisse voir immédiatement les changements apportés). Par contre, au final nous voulons obtenir deux fichiers :
- Un fichier XHTML contenant le formulaire
- Un fichier XML contenant toutes les ressources du formulaire
Il faut alors qu’au niveau du fichier XHTML, les ressources ne soient plus directement intégrées mais que le composant pointe vers ces données qui se trouvent dans le fichier XML externe au document! Pour y arriver, lors de la soumission du formulaire, une copie de l’arbre DOM représentant le formulaire est créée et différents changements sont effectués sur cette copie. Typiquement tous les composants sont effacés et réinséré en suivant leur nouvelle représentation, c’est-à-dire avec leur attributs “bind”.
A l’heure qu’il est, ces deux fichiers sont donc correctement créés, il subsiste cependant encore un problème d’encodage. Le fichier de ressources contient bien les signes accentués mais étant donné que son encodage est du ANSI, lors de l’affichage du formulaire dans un browser, les signes accentués ne sont plus représentés correctement! Il s’agit certainement d’une modification à apporter dans le script PHP lors de la création du fichier sur le disque…je ne sais cependant pas encore comment y remédier.
Ajoutons que pour que les bindings se fassent correctement, des identificateurs uniques doivent être spécifiés auprès de chaque composant. Avant de soumettre le formulaire, le programme vérifie donc que tous les identificateurs ont été renseignés. Dans le cas contraire, la cellule qui n’a pas encore reçu d’identificateur est alors sélectionnée et l’utilisateur peut directement en introduire un!
Toujours au niveau des identificateurs, étant donné que ceux-ci doivent être uniques, une méthode contrôle (à chaque fois qu’un identificateur est ajouté) que l’identificateur n’a pas déjà été utilisé pour un autre composant. Cependant cette fonctionalité ne fonctionne pas encore complètement comme désiré, il reste donc encore quelques modifications à apporter…
10.27.06
Création du formulaire sur le serveur
J’ai déjà implémenté la partie qui consiste à créer physiquement le formulaire sur le disque. Lors de l’édition et de la création de ce formulaire, celui-ci est en fait contenu en mémoire et une fois la création terminée ce contenu doit être inséré dans un fichier sur le disque.
Pour ce faire je me suis servi d’AJAX afin d’envoyer l’arbre DOM contenant tout le formulaire (avec la méthode POST) vers un script PHP qui se charge de récupérer ce contenu, de créer un fichier sur le disque et d’y insérer le contenu XHTML.
Problème avec le fichier de ressources à créer
Le fichier de ressources est sensé contenir toutes les données relatives à l’affichage d’un composant tels que son label, la bulle d’aide (hint), etc. Dans un souci de généricité il est bien de faire apparaître toutes ces données quelque part d’autre que dans les composants directement. Ainsi, s’il faut réaliser plusieurs changements, ceux-ci seront effectués uniquement dans le fichier de ressources et non pas dans le code source du formulaire où il peut être fastidieux de trouver ce que l’on cherche.
Au niveau des composants il n’y a alors plus qu’un attribut de binding qui pointe sur le bon tag du fichier de ressources. L’attribut bind du tag label d’un composant pointera alors vers la description textuel que ce label devra contenir. (cette description se trouvant dans le fichier de ressources). Nous voyons donc que l’affichage des bonnes données se fais par un chaînage entre le composant et le fichier de ressources.
J’ai donc essayé d’implémenter cela dans mon application mais je me suis heurté à un problème : bien que tout le code soit correct, le binding n’est pas effectué dynamiquement. C’est-à-dire que si l’utilisateur place un composant sur le layout et qu’il spécifie un label pour ce composant, le label est alors ajouté dans le fichier de ressources et au niveau du composant un lien pointe le bon tag dans le fichier de ressources. Seulement ce lien ne semble pas fonctionner lorsqu’il est effectué dynamiquement! Après de nombreux tests j’en suis donc venu à la conclusion que cette façon de faire n’était pas envisageable.
J’ai alors décidé de procéder comme ceci : les différentes ressources seront incrustées dans le composant lors de l’édition du formulaire, ainsi l’utilisateur a la possibilité de voir en temps réel les changements visuels qu’il apporte à son formulaire. Ensuite lorsque le formulaire sera terminé et qu’il sera soumis en vu d’être créé physiquement sur le disque, les différentes données incrustées au niveau des composants devront être exportées vers un fichier de ressources. Cette façon de faire apportera le même résultat au final mais le seul problème est qu’il faut passer par une étape supplémentaire qui consiste justement à enlever les données se trouvant à un endroit et à la déplacer vers un autre endroit!
10.24.06
Modification d’une propriété d’un composant
Il est à présent possible de modifier la valeur contenue dans une des propriétés d’un composant sélectionné dans le layout. L’utilisateur a donc la possibilité de changer la valeur de son choix, un événement onchange est alors levé sur l’input et a pour effet de modifier les attributs de l’objet correspondant et également de modifier l’arbre DOM contenant le layout et ses composants. Ceci signifie que le changement est directement répercuté sur le layout et l’utilisateur a donc la possibilité de voir l’effet de son changement (pour autant qu’il s’agisse d’une modification visuelle telle que le nom du label, etc).
Pour l’instant, seules quelques propriétés sont éditables. La majorité des propriétés sera ensuite des propriétés liées au binding tels que le fait de spécifier un composant comme required, son identificateur, etc… Ces modifications auront pour effet de modifier le head du document qui lui-même contient le modèle et l’instance de données.
10.19.06
Affichage des propriétés d’un composant
J’ai à présent ajouté la fonctionnalité permettant d’afficher les différentes propriétés d’un composant tels que son label, son id, etc. Pour ce faire, j’ai dû repenser un petit peu la structure globale des différentes classes que j’ai déjà créées (par exemple, certains classes composants héritent d’une autre classe étant donné que les propriétés sont à peu de chose prêt les mêmes) et j’ai dû ajouter une nouvelle méthode par classe représentant un composant. Cette méthode permet de créer un tableau XHTML composé de deux colonnes. La première colonne contient les labels (descriptions) des différentes propriétés et la deuxième colonne contient les valeurs associées. La méthode retourne alors le tableau créé et celui-ci est ajouté dans la partie de l’interface permettant justement de visualiser les propriétés d’un composant.
Pour l’instant il est juste possible de consulter les propriétés, l’étape suivante sera de mettre à jour les attributs de l’objet lorsque une ou plusieurs de ses propriétés est/sont modifiées par l’utilisateur. De plus, il faudra que je liste sur papier les différentes propriétés de chaque composant en vue de les ajouter dans les classes correspondantes…pour l’instant je me suis contenté d’une ou deux propriétés juste pour effectuer les tests.
10.17.06
Premières interactions avec l’interface
Suite au choix de la technologie (voir message précédent), j’ai refait le contrôleur entiérement en DOM.
J’ai également créé les premières versions des différents objets qui représentent les différents composants XForms possibles. Pour l’instant, chaque classe permet de créer un noeud composé des bons tags XForms en fonction du composant. A présent, l’utilisateur a alors la possibilité de choisir un composant dans la palette à gauche et lorsqu’il clique sur une cellule du layout, une instance du bon composant est créée et affichée.
De plus, l’utilisateur a la possibilité après coup de sélectionner une cellule qui contient déjà un composant en vue de récupérer ses différentes propriétés. Celles-ci seront alors affichées dans une autre partie de l’interface et seront ainsi consultables et modifiables (cette partie n’est pas encore faite).
Voici donc la première étape dans l’interaction entre l’utilisateur et l’interface. Le résultat est assez satisfaisant vu que l’on a directement quelque chose de visible et qui fonctionne comme l’utilisateur le souhaite.
Choix de la technologie suite à la séance –> DOM
Suite à la séance de vendredi, j’ai pesé le pour et le contre de chacune des deux technologies possibles et proposées par Stéphane pour modifier le layout. La première solution était d’utiliser E4X afin de pouvoir ajouter facilement de nouveaux composants dans une variable représentant le contenu XML du layout. La deuxième solution était de n’utiliser que le DOM.
Après quelques tests j’ai eu énormément de difficultés avec E4X, plusieurs transformations sont nécessaires (représentation DOM vers E4X et inversément) et je n’ai par exemple pas été capable d’ajouter un composant préfixé (xf en l’occurrence) bien que E4X semble gérer les namespaces. En ce qui concerne le DOM, une méthode createElementNS() existe et fait le travail très facilement.
Dans un deuxième temps je n’ai pas non plus trouvé de méthode capable de supprimer un noeud en E4X alors que cette méthode existe dans le DOM (removeChild()).
Pour toutes ces raisons mon choix se porte donc sur le DOM. Il est clair que sa manipulation demande plusieurs lignes mais il faut avouer qu’il s’agit d’une technologie éprouvée et qui fonctionne bien. De plus, E4X reste une technologie jeune et très peu de documentation existe…ce qui fait qu’il est extrêmement difficile d’avancer à un rythme correct!
10.16.06
Séance du 13 octobre 2006
J’ai retrouvé Stéphane à l’école histoire de faire le point sur l’avancement du projet.
Il m’a par exemple appris que les noeuds textuels vides de l’arbre DOM ne sont pas une spécialité de Firefox et ce phénomène vient apparemment des tabulations effectuées dans le code avant les balises. Il m’a également donné une autre piste pour effectuer le spanning vertical…si ça se trouve, ma fonction utilitaire permettant de nettoyer un arbre DOM ne sera même pas utilisée…j’ai encore quelques tests à effectuer donc!
Sinon au niveau du projet total, je lui ai montré l’interface et il m’a conseillé de la partager en deux parties :
- Une partie constituant les options de l’éditeur (ex. : choisir un composant, propriétés d’un composant, etc)
- Une partie contenant uniquement le tableau représentant le futur formulaire créé
Ceci se fait en utilisant une iframe dans la page principale qui se charge d’importer et d’afficher le contenu d’un autre fichier XHTML qui contient, lui, uniquement le formulaire en phase de création et/ou modification. Cette manière de faire est beaucoup plus simple vu que ce fichier sera ensuite directement posté sur le serveur et le formulaire qu’il contiendra peut directement être affiché dans un navigateur.
En effet, j’avais en tête l’idée de modifier le formulaire qui se trouvait dans la même page que le reste de l’éditeur. Il aurait alors fallu, au moment de la validation, parser tout le fichier et ne récupérer que cette partie en vue d’être postée sur le serveur. Cette méthode était beaucoup moins souple.
Du coup à présent l’application suit en quelque sorte de pattern MVC où le modèle représente le fichier XHTML contenant le formulaire, la vue étant l’éditeur (intégrant le modèle) et finalement le contrôleur est un script (orienté objet) qui fait le lien.
Stéphane m’a également proposé une solution faisant intervenir E4X. Le contrôleur se charge de modifier un objet XML en fonction des manipulations de l’utilisateur sur l’interface puis par l’intermédiaire d’une fonction et en utilisant le DOM, cet objet XML est utilisé pour mettre à jour le formulaire affiché dans l’interface. Le fait de travailler avec E4X apporte quelques avantages, comme par exemple la manipulation facilitée de noeuds XML (tel que l’ajout ou la recherche) mais s’avère être assez compliqué. C’est alors à moi de juger si cette façon de faire est possible et exploitable ou alors si il serait plus simple de ne travailler qu’avec le DOM…
10.12.06
Enormément de problèmes…
Comme l’indique le titre, cette journée a été marquée par une suite de problèmes. Je me suis attelé à continuer la partie que je décrivais hier. Après de longs tests et de longues réflexions je tenais enfin le bon bout mais c’était sans compter sur des comportements plus qu’aléatoires! En effet, le script permettant de normaliser un arbre DOM sous Firefox ne s’exécute pas de manière équivalente d’une fois à l’autre : il suffit typiquement d’ajouter un simple message d’alerte pour que le script fasse n’importe quoi, alors que le code n’a absolument pas changé! Je suis dans une situation où je ne sais vraiment pas quoi faire. Le plus rageant est que tout le temps que j’ai passé depuis hier est uniquement dû à un comportement particulier du browser Firefox!
J’ai en fait compris d’où venaient ces noeuds textuels vides (cf message de hier) : ceux-ci apparaissent lorsqu’il y a un retour à la ligne dans le code source du fichier XHTML. Ex.:
<tr>
<td />
</tr>
…donnera l’arbre DOM suivant :
tr
---" "
---td
Il n’est bien évident pas une solution de vouloir alors changer le code source et de coller tout les tags HTML… En résumé je suis dans une situation sans issue sur cette partie du problème. Le rendez-vous de demain avec Stéphane permettra peut-être d’y voir plus clair!
10.11.06
Spanning des cellules (2ème partie)
Je me suis attelé au spanning vertical cette fois-ci.
Comme je l’ai déjà évoqué plus tôt, l’arbre DOM est représenté bizarrement sous Firefox ce qui le rend pas du tout standard! Je ne sais pas pourquoi il y a ce phénomène mais il faut apparemment faire avec. Pour rappel, Firefox ajoute des noeuds textuels vides entre chaque noeud normal. Ex.:
|–root
|–” “
|–personne
|—|–” “
|—|–nom
|——-|–”Alain”
|—|–” “
|—|–id
|——-|–”1″
|—|–” “
|–” “
|–personne
|—|–” “
|—|–nom
|——-|–”Benoit”
|—|–” “
|—|–id
|——-|–”2″
|—|–” “
|–” “
On peut voir des noeud textuels vides ajoutés dans l’arbre. Il est évident que ceci fausse complétement le parsing d’un arbre et ça peut devenir un vrai casse-tête pour réussir à s’en sortir et à savoir ce que l’on fait! J’ai alors décidé d’écrire un petit script utilitaire qui permet de “nettoyer” un arbre DOM passé en paramètre afin de renvoyer une version de l’arbre sans aucun noeud textuel parasite. J’ai passé la journée entière sur l’écritue de celui-ci et je ne suis toujours pas à un résultat satisfaisant. Il me reste un bug à corriger qui apparemment vient d’un problème de références entre deux objets qui pointent vers la même chose. J’ai beau avoir essayé tout ce qui était en mon pouvoir mais je dois avouer que je ne peux plus rien en faire pour aujourd’hui…relire les mêmes lignes de code pendant des heures m’embrouille encore plus à la longue.
Ceci étant, le spanning vertical n’est pas encore complétement fonctionnel. J’ai codé une partie de celui-ci en partant du principe que l’arbre DOM est “propre”. Il m’est du coup impossible pour l’instant de tester si les bases du spanning vertical fonctionnent… J’espère vraiment pouvoir avancer là-dessus dès demain!
