09.29.06

Contenu d’un fichier XML (suite)

Posted in Avancement, Problème at 7:13 pm by atuscher

Je me suis rendu compte que je n’avais pas appliqué un traitement pour les différents attributs rencontrés dans une instance XML. A présent toutes les informations nécessaires sont affichées et permettront ainsi de montrer à l’utilisateur les noms des tags qu’il utilisera pour effectuer le binding de ses composants XForms.

J’ai également intégré le tout dans l’interface déjà créée. Afin d’offrir plus d’interactivité, j’ai rajouté un formulaire permettant à l’utilisateur de choisir le fichier XML qu’il souhaite charger. Je n’ai pas trouvé le moyen de charger un fichier sur un serveur à partir de Javascript ou plus particulièrement AJAX. J’ai donc dû me tourner vers un autre langage et j’ai trouvé un petit script PHP qui fait l’affaire. Pour ce faire, j’utilise un serveur Apache installé sur ma machine. Je ne sais pas si le fait de se trourner vers le PHP est la meilleure solution, il faudra encore en discuter avec Stéphane. Peut-être y’a-t’il une autre manière de faire… N’ayant pas beaucoup de connaissances en PHP, j’ai de la peine à savoir d’où provient un problème. En effet, l’upload semble ne pas fonctionner à chaque fois!

09.28.06

Afficher le contenu d’un fichier XML

Posted in Avancement, Problème at 9:33 pm by atuscher

Comme dit précédemment, une des parties de l’interface devra contenir l’instance XML que le formulaire à créer manipulera.
J’ai fait de longues recherches sur internet pour voir s’il existait déjà quelque chose qui permet facilement d’effectuer une copie d’un fichier XML dans une page web. Je n’ai malheureusement rien trouvé de tel, j’ai donc effectuer cela avec un script Javascript en utilisant l’objet XMLHttpRequest. J’ai eu énormément de problèmes pour arriver à afficher ce que je désirais, il a fallu que je comprenne mieux les propriétés et méthodes du DOM pour manipuler des noeuds. De plus, un bug (connu apparemment) dans le DOM de Firefox m’a fait tourner en rond. Ce bug a tendance à rajouter des noeuds textuels entre chaque noeud réel, ce qui avait pour effet de donner de drôles de résultats!

Le résultat que j’obtiens n’est pas des plus esthétiques mais il permet dans un premier temps d’afficher les différents noeuds qu’une instance XML contient. Rien ne m’empêchera (si ce n’est le temps), d’améliorer l’apparence avec par exemple un menu evanescent qui permet de fermer et ouvrir un noeud.

Ce script permet à l’utilisateur de voir, au sein de la même interface, les noms des noeuds qu’il devra utiliser pour les tags de binding. Un énorme avantage de cette possibilité est que l’utilisateur ne doive pas jouer avec plusieurs fenêtres pour passer de l’interface vers l’instance XML par exemple.

Voici une capture (Instance XML.jpg) d’un résultat.

Première étape de l’interface

Posted in Avancement at 9:10 pm by atuscher

J’ai réalisé une infime partie de l’interface, puisque je me suis principalement attelé au positionnement des différents cadres que cette interface devra contenir (voir message précédent). J’ai d’ailleurs réutilisé le test que j’ai fait l’autre jour et l’ai intégré dans la partie layout. Il s’agit d’un tableau qui est mis en forme par une feuille de style CSS séparée. Le but serait ensuite de pouvoir changer à volonté l’apparence du formulaire à créer en chargeant l’une ou l’autre des feuilles de styles prédéfinies.

Concernant la conception de l’interface, j’ai décidé d’utiliser un outil que je n’ai jamais encore eu l’occasion de tester : Macromedia Dreamweaver 8. J’ai donc passé un moment à comprendre comment l’utiliser…bien que je n’ai pas exploré les 3/4 de ses possibilités!

09.26.06

Croquis de l’interface et premier test

Posted in Avancement at 7:04 pm by atuscher

J’ai dans un premier temps réalisé un croquis sur papier représentant l’interface principale du futur éditeur.
Cette interface devra contenir les parties suivante :

  • une liste des différents composants XForms représentée sous forme d’icones
  • une partie représentant le layout sur lequel les composants prendront place
  • une partie contenant les options du composant sélectionné (nom, label, id, bind, etc)
  • une partie contenant le contenu de l’instance XML que le formulaire manipulera (il faut au préalable avoir désigné le fichier XML contenant cette instance)
  • une partie contenant les différents types simples contus dans un schéma XML, fichier qui doit également avoir été chargé au préalable

L’interface comme elle a été pensée ne reste pas statique et il se peut très bien que d’autres parties viennent s’ajouter au fur et à mesure.
Le but étant d’avoir une interface le plus simple possible, à priori tout sera directement accessible par l’interface principale. Il se peut toutefois que certaines actions nécessitent l’affichage du boîte de dialogue demandant une saisie ou une confirmation.

Dans un deuxième temps, j’ai réalisé une petite page de test représentant un tableau HTML créé dynamiquement à partir d’un script et ayant une apparence décrite dans une feuille de style séparée. Ce tableau représentera à terme le layout de l’interface. Mon but était de pouvoir ajouter des composants XForms dynamiquement dans les cellules du tableau une fois cliquées. Pour l’instant, seul une sorte de composant XForms est ajouté mais par la suite le composant à ajouter sera défini par l’icone sur laquelle l’utilisateur a cliqué dans l’interface.
J’ai passé énormément de temps pour réaliser ce petit test, j’ai perdu un temps fou à comprendre certains problèmes. Ceux-ci viennent surtout du fait que je ne suis pas encore tout à fait au point avec toutes les technologies, particuliérement le DOM. J’ai également perdu beaucoup de temps à essayer de comprendre pourquoi mes composants XForms ne s’affichaient pas pour finalement me rendre compte que l’extension de mon fichier était .html et non pas .xhtml!

Il reste sinon encore quelques points sur lesquels je ne veux pas trop m’attarder, principalement en ce qui concerne l’apparence via les feuilles de style. J’ai par exemple réussi à forcer une taille fixe pour les cellules du tableau (en mettant à chaque fois une balise div dans un td) mais par contre si le label d’un bouton (par exemple) est plus grand que la taille de la cellule, ce label ainsi que le composant sortent des bords de la cellule…ceci devra encore être corrigé mais j’estime que ce n’est pas une priorité à l’heure qu’il est.

09.25.06

Séance du 22 septembre 2006

Posted in Séance at 1:05 pm by atuscher

Nous nous sommes retrouvé dans les locaux de St Roch afin de discuter sur ce début de projet de diplôme. Cette rencontre a permis de mettre au clair beaucoup de points et ainsi de partir d’un bon pied dès le début.

Nous avons discuté longuement avec Stéphane sur les possibilités que l’éditeur devra offrir ainsi que les différentes contraintes à prendre en compte. La règle de base est que l’éditeur soit simple et ergonomique pour l’utilisateur final. Un travail de conception devra alors intervenir afin de penser comment l’interface se présentera, la disposition des boutons, options, etc.

Nous avons également précisé la notion de “layout”. Il faut voir cela comme un tableau constitué de nxm cases avec une mise en page contenue dans une feuille de style (CSS) séparée. L’utilisateur a alors la possibilité de placer ses composants dans les différentes cases du tableau afin de créer l’aspect du formulaire désiré. Les options de chaque composant comprendront entre autre l’id, les contraintes de type, le tag de l’instance XML manipulée auquel il se réfère, le nombre de cellules sur lequel le composant s’étale.

Il faut également que le tout soit le plus générique possible en départageant clairement les différentes parties d’un formulaire XForms, c’est-à-dire :
- Fichier XHTML contenant les composants XForms
- Fichier XML représentant l’instance manipulée
- Schéma XML utilisé (éventuellement) afin de contraindre le contenu de certains champs
- Fichier XML contenant les différentes ressources du formulaire, à savoir l’identificateur du composant, son label, le message d’aide, etc. Cette manière de faire aura l’avantage d’avoir très peu d’information dans le fichier XHTML contenant le formulaire et offre ainsi une plus grande souplesse s’il faut par exemple changer le nom d’un label. Une autre raison de l’existence de ce fichier XML externe est pour appliquer différentes langues à un même formulaire. Le fichier XHTML ne changerait alors pas, il faudrait simplement utiliser un fichier de ressource contenant les informations avec la langue souhaitée.

Aucun détail technique n’a réellement été discuté si ce n’est que le code devra suivre un modèle orienté objet. Pour la création de l’éditeur ou les actions de l’utilisateur (tel que le drag ‘n drop des différents composants sur le layout par exemple) il serait possible d’utiliser une librairie déjà existante telle que la Dojo Toolkit.

09.21.06

Dernière ligne droite

Posted in Uncategorized at 10:26 pm by atuscher

Et voilà nous y sommes, la séance d’information de début de projet de diplôme s’est déroulée ce mardi 19 septembre. Nous y avons reçu le réglement ainsi que trois exemplaires du cahier des charges qu’il faut retourner auprès du secrétariat.

C’est donc parti pour 12 semaines de XForms et de Javascript à haute dose!!!