RAPPORT DE PROJET

Editeur XML

Responsable de projet : Michel Meynard

Universite Montpellier 2 - M1 Informatique S2

CHANTEMESSE FlorianNOYARET Pierre

REY CyrilleVINYES Francois

25 avril 2008

Table des matieres

1 Introduction 2

2 Organisation et repartition du travail 32.1 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . 32.2 Moyens mis en place pour le travail en collaboration . . . . . 52.3 Repartition du travail . . . . . . . . . . . . . . . . . . . . . . 6

3 Mise en œuvre 83.1 Definition du XML . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Modelisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.1 Le modele . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.2 Les vues . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.3 Le controleur . . . . . . . . . . . . . . . . . . . . . . . 103.2.4 Le diagramme de classe . . . . . . . . . . . . . . . . . 11

3.3 Conception de l’interface graphique . . . . . . . . . . . . . . . 123.4 Parsage du fichier XML . . . . . . . . . . . . . . . . . . . . . 14

3.4.1 L’API DOM . . . . . . . . . . . . . . . . . . . . . . . 153.4.2 Thread . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.3 Algorithme de Parsage . . . . . . . . . . . . . . . . . . 16

3.5 La fermeture electrique . . . . . . . . . . . . . . . . . . . . . . 183.6 Les options (Serialisation) . . . . . . . . . . . . . . . . . . . . 183.7 Generation de la DTD . . . . . . . . . . . . . . . . . . . . . . 19

3.7.1 Syntaxe de la DTD . . . . . . . . . . . . . . . . . . . . 203.7.2 L’API SAX . . . . . . . . . . . . . . . . . . . . . . . . 213.7.3 Insertion dans le XML . . . . . . . . . . . . . . . . . . 21

3.8 La completion si DTD . . . . . . . . . . . . . . . . . . . . . . 213.8.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Resultats 23

5 Conclusion 25

1

Chapitre 1

Introduction

Il nous a ete demande lors de ce TER de realiser un editeur XML quicomporte les fonctionnalites suivantes :

– Edition brute du source XML,– edition arborescente (ou mode plan) du document XML,– ouverture et fermeture de sous-arborescences en un clic,– validation en continu grace a des taches multiples en parallele,– aide a l’ecriture d’une DTD (inference de DTD),– visualisation dans un navigateur d’un document XML associe a une

feuille de style,– coloration syntaxique,– completion automatique si DTD,– ecriture electrique.Nous avons donc dans un premier temps cherche a specifier les demandes

de notre responsable de projet, M. Meynard.Nous avons programme cet editeur en Java, conformement a ce que nous

a indique M. Meynard. Ce langage en plus d’etre connu de tout le groupe,est facilement portable sur tous les systemes d’exploitation pourvus de lamachine virtuelle Java.

Nous avons nomme cet editeur “Loligo XML”.Dans notre memoire nous allons decrire comment nous avons procede

et quelles solutions nous avons proposees pour implementer les differentesfonctionnalites a notre outil.

2

Chapitre 2

Organisation et repartitiondu travail

2.1 Analyse de l’existant

Nous avons choisi d’analyser quatre celebres editeurs XML afin de repererles fonctionnalites interessantes propres au langage XML. Parmi ces editeurs,seul Jedit est gratuit (et open source). Le prix des licences des trois autresvarie de 80 a 400 euros.

XML writerFonctionnalites interessantes :– Vue en arbre,– verification de la validite : document bien forme,– TagBar : chargement d’une DTD sous forme d’arbre : permet l’inser-

tion rapide d’elements ou d’attributs par drag’n drop.Inconvenients :– Pas d’interaction entre l’arbre des balises et le code source,– pas de verification en temps reel.Bonus :– Fermeture automatique des balises,– ouverture de fichier a partir d’une URL,– insertion rapide de balises autour d’un bloc selectionne a la souris,– assignation rapide d’une feuille de style (XSLT/CSS) ou d’une DTD

a un document XML,– transformation de un ou plusieurs documents XML en utilisant leur

feuille de style,– preview dans une nouvelle fenetre ou dans un navigateur,– snippets : insertion rapide de balises en la choisissant dans une liste et

possibilite d’en rajouter.

3

oXygenFonctionnalites interessantes :– Vue en arbre,– verification de la validite : document bien forme,– completion automatique si DTD,– editeur d’arbre evolue,– debogeur : xslt et squery,– evaluation d’expression XPath.Inconvenients :– L’editeur d’arbre est une application separee.Bonus :– Fermeture automatique des balises,– erreurs de parsage soulignees,– correcteur orthographique,– client SVN,– comparateur de fichiers,– preview dans une nouvelle fenetre ou dans un navigateur.

XMLSpyFonctionnalites interessantes :– Verification de la validite : document bien forme,– generateur de DTD,– completion automatique si DTD,– evaluation d’expression XPath,– transformation XSL,– conversion XML en BD.Bonus :– Fermeture automatique des balises,– correcteur orthographique,– generateur de fichier XML a partir d’une DTD,– comparateur de fichiers,– preview dans une nouvelle fenetre ou dans un navigateur.

JEdit et son plugin XMLFonctionnalites interessantes :– Vue en arbre,– verification de la validite : document bien forme,– generateur de DTD,– completion automatique si DTD.Inconvenients :– Pas d’onglets pour les fichiers ouverts.Bonus :– Erreurs de parsage soulignees,

4

– editeur de balises.

BilanLes editeurs payants sont beaucoup plus nombreux que les gratuits. La

concurrence etant forte, on s’apercoit alors que ces logiciels sont tres com-plets. Ils permettent de construire un document XML rapidement grace ade nombreuses fonctionnalites. Parmi ces fonctionnalites, on remarque queles plus sollicitees sont :

– La vue en arbre,– le parsage,– la completion,– la fermeture automatique des balises.On remarque par ailleurs que ce sont les fonctionnalites principales qui

nous ont ete demandees d’implementer dans ce TER.

2.2 Moyens mis en place pour le travail en colla-boration

Pour mener a bien ce projet, et travailler en parallele le plus efficace-ment possible, nous avons mis en place sur la plate-forme Eclipse, un pluginpermettant la gestion et l’interactivite avec un serveur SVN.

SVN de son vrai nom Subversion, permet a tous les utilisateurs de pou-voir suivre l’avancement d’un projet avec une coordination optimale : chaquemembre de l’equipe de projet envoie ses ameliorations et le projet avancecar tout est ajoute en continu.

En tant que serveur SVN, nous avons opte pour Assembla.com, qui gracea son interface intuitive sur internet mais aussi sa gratuite, propose un espacede stockage gratuit de 500 Mo. Il propose egalement trac pour documenter etsuivre les bugs, et un service d’upload de fichiers afin que tous les membrespuissent s’echanger et partager toutes les ressources qu’ils jugent necessaires.

La figure 2.1 page suivante represente un apercu de son interface.On observe tous les onglets pouvant etre utiles a une realisation de pro-

jet (Files, Trac/SVN, Team, etc.) efficace et en collaboration avec tous lesmembres du projet sans provoquer de conflit et de mise a jour fastidieuse.Grace a ce serveur, nous avons tres certainement economise une grandequantite de temps qui aurait ete dediee a diverses reunions de chacune denos avancees.

5

Fig. 2.1 – Interface d’Assembla.

2.3 Repartition du travail

En ce qui concerne la repartition du travail, nous avons a peu de chosespres respecte le planning que nous avions prevu lors de l’elaboration ducahier des charges. Ce qui peut justifier les divergences par rapport au cahierdes charges est la reunion de 2 taches en une, par exemple, la validation dusource XML a ete realisee communement avec la validation par la DTD. Deplus certaines fonctionnalites nous ont demande plus de temps que prevu,mais nous avons pu compenser avec d’autres taches qui se sont averees plusrapides a developper.

A part ces quelques divergences nous avons respecte la planning, ce quinous a permis lors de certaines semaines, d’etre en avance et donc de pouvoircontinuer sans probleme les taches suivantes.

La figure 2.2 page suivante rappelle l’emploi du temps que nous avionselabore au debut du projet.

6

Fig. 2.2 – Diagramme de Gantt de notre projet

7

Chapitre 3

Mise en œuvre

3.1 Definition du XML

XML (eXtensible Markup Language) est un langage informatique a ba-lises. Le World Wide Web Consortium (W3C), promoteur de standards fa-vorisant l’echange d’informations sur Internet, recommande la syntaxe XMLpour exprimer des langages de balisages specifiques. De nombreux langagesrespectent la syntaxe XML : XHTML, SVG, XSLT. . .

Son objectif initial est de faciliter l’echange automatise de contenus entresystemes d’informations heterogenes.

Voici un exemple d’une structure XML :

<annuaire><ville nom="Montpellier">

<personne>0123456789</personne><personne>9876543210</personne>

</ville></annuaire>

3.2 Modelisation

Pour la phase d’analyse de notre editeur, nous nous somme bases surl’architecture MVC (Modele-Vue-Controleur) pour organiser l’interface gra-phique.

3.2.1 Le modele

En tant qu’editeur gerant l’ouverture de plusieurs fichiers dans une memefenetre (systeme d’onglets), la base du modele est d’abord constituee d’uneliste de “fichiers ouverts”.

En tant qu’editeur XML, la representation des fichiers dans l’applica-tion necessite l’utilisation de la classe DefaultStyledDocument disponible

8

dans l’API Java. En effet, cette classe permet la manipulation de caracteres(le code source du fichier XML) grace a son implementation de l’interfaceDocument. Mais elle a surtout l’avantage de permettre la decoration dutexte contenu dans le Document par l’application de style. Ainsi, le texte duDocument peut etre decore sans qu’aucune autre donnee concernant cettedecoration ne soit rajoutee dans le code source.

Outre cette instance de la classe DefaultStyledDocument, la classe Fi-chierXML contient un booleen indiquant l’etat de sauvegarde du fichier etune String pour le chemin du fichier sur le disque.

Le deuxieme element important du modele est une reference vers unfichierXML particulier : “le fichier en cours d’edition” (ou “le fichier pourlequel l’onglet associe a le focus”). Logiquement, ce fichier doit figurer dansla liste des fichiers ouverts citee precedemment.

Fig. 3.1 – Schema des modeles dans l’editeur XML.

Afin de synchroniser les vues avec le modele, la classe FichiersOuvertspossede egalement une liste d’ecouteurs. Ainsi, chaque fois qu’une requetede changement de ficher en cours est demandee, la reference fichierEnCoursest mise a jour puis l’ensemble des ecouteurs interesses par le fichier en courssont avertis de la nouvelle valeur.

3.2.2 Les vues

La JFrame principale de l’application contient de nombreux composantsgraphiques permettant l’interaction avec l’utilisateur. Parmi ces composants,trois sont consideres comme des vues du design pattern MVC car ils ontbesoin d’etre tenus au courant de chaque modification du modele.

Ces trois vues correspondent aux trois fonctionnalites :

VueArbre : affichage du document XML sous forme d’un arbre (un JTree)

9

VueCompil : indication des erreurs de parsageVueOnglets : gestion des fichiers ouverts dans un tableau a onglets

Cependant, ces trois vues ne s’interessent pas toutes aux memes elementsdu modele. Ainsi, VueArbre et VueCompil ne repondent que lors d’un chan-gement du fichier en cours, tandis que VueOnglets s’attache principalementaux modifications de la liste des fichiers ouverts.

Par convention, toutes les vues qui desirent ecouter le modele doiventheriter de la classe Vue. Cette classe abstraite sert d’interface avec le controleur.

Fig. 3.2 – Schema des vues dans l’editeur XML.

3.2.3 Le controleur

Il est le chef d’orchestre de l’application. Son instance est unique.Son premier role est de mettre en relation les vues avec le modele. Pour

cela, il ajoute chaque vue dans la liste des ecouteurs du modele.Il sert ensuite d’intermediaire entre les vues et le modele lors de l’execution

de l’application et des actions de l’utilisateur. Il prend en charge la gestiondes evenements de synchronisation pour mettre a jour les vues ou le modeleet les synchroniser. Il recoit tous les evenements de l’utilisateur et enclencheles actions a effectuer. Si une action necessite un changement des donnees,le controleur demande la modification des donnees au modele qui va en-suite avertir les vues concernees que les donnees ont change pour qu’elles semettent a jour. Le controleur n’effectue aucun traitement, ne modifie aucunedonnee. Il analyse la requete du client et se contente d’appeler le modele.

10

Fig. 3.3 – Schema du controleur dans l’editeur XML.

3.2.4 Le diagramme de classe

Nous avons etabli le diagramme de classe 3.4 page suivante.

11

Fig. 3.4 – Diagramme de classe de l’editeur XML.

3.3 Conception de l’interface graphique

M. Meynard nous ayant demande une interface intuitive, nous noussommes mis a la recherche d’exemples d’interfaces les plus communes et

12

conviviales possibles. Pour arriver a un resultat final, nous nous sommesbases sur des applications existantes telles qu’Eclipse (Environnement deDeveloppement Java), NotePad++ (multi-langage) et celles citees dans l’ana-lyse de l’existant, qui nous ont paru les plus interessantes en termes d’intui-tivite et d’interactivite.

Finalement nous avons donc realise l’interface de notre editeur XMLgrace aux composants Swing de la librairie Java. En effet, celle-ci etanttres complete et fonctionnelle, nous avons pu integralement concevoir l’in-terface grace aux composants deja existants, qui sont semblables aussi bienau niveau du fonctionnement que de l’apparence, aux applications que nousavions auparavant selectionnees.

La figure 3.5 represente la hierarchie de confinement de l’interface.

Fig. 3.5 – Hierarchie de confinement de l’interface graphique.

Comme nous pouvons le constater sur cette figure, nous avons integrea la Frame principale, une JMenuBar qui compose notre barre des menus

13

(Fichier, Edition. . .), ainsi qu’un JSplitPane, qui permet de modifier ma-nuellement et assez facilement la taille des composants graphiques.

La figure 3.6 montre un apercu de l’interface concue a partir du schema 3.5page precedente.

Fig. 3.6 – Interface Graphique de l’editeur XML.

On arrive bien a distinguer les differents elements qui composent lafenetre principale, et de ce fait elle se revele assez conviviale et intuitive,car elle reprend les grandes lignes des applications actuelles.

3.4 Parsage du fichier XML

L’une des principales fonctionnalites que devait remplir notre editeurXML, etait de parser le code de maniere “threadee”. Pour faire ce par-sage nous avons utilise une API (Application Programming Interface) dejaexistante dans Java : l’API DOM.

Le parseur (ou analyseur syntaxique) est un outil qui recupere les donneesencapsulees dans le document XML en le parcourant et en extrait les infor-mations qu’il contient.

14

3.4.1 L’API DOM

DOM (Document Object Model) est donc un analyseur utilisant uneapproche hierarchique du document (d’autres API, telles que SAX etc., quenous avons utilisee pour generer la DTD a partir du XML, utilisent uneapproche evenementielle).

Cela signifie que si le parsage reussit, DOM construit une structure dedonnees contenant des objets representants les elements du document, etdont les methodes permettent d’acceder aux proprietes. On transmet ensuitecette structure a d’autres classes qui pourront l’utiliser (notamment pourla creation de l’arbre representant le fichier XML), java implementant pardefaut une interface DOM (org.w3c.dom), et une interface Document quicontiennent les methodes pour acceder aux attributs, aux elements. . .

Si le parsage ne reussit pas, DOM genere des Exceptions de type SAXEx-ception que nous recuperons et traitons de maniere a les afficher dans lafenetre de compilation, au bas de notre interface. Dans ce cas le DOMconstruit aura une valeur null.

Il existe 2 types de parseur :– Les parseurs validants permettant de verifier qu’un document XML

est conforme a sa DTD,– Les parseurs non validants se contentant de verifier que le document

XML est bien forme, c’est-a-dire qu’il respecte la syntaxe XML debase.

Il est possible de specifier a notre parseur DOM quel type de parsage ildoit effectuer.

Pour creer notre document DOM et le parser on doit d’abord recupererle constructeur de documents (javax.xml.parsers.DocumentBuilder) a partird’une fabrique de constructeur (javax.xml.parsers.DocumentBuilderFactory).C’est ce constructeur de document qui va construire le DOM ou Document(org.w3c.Document) a partir de la source XML.

3.4.2 Thread

Un thread (ou Processus leger) est un processus qui du point de vue del’utilisateur, semble se derouler en parallele du programme.

Notre application utilise un thread pour parser le document. C’est a direqu’une fois les constructeurs de document crees, la tache parallele les utilisepour analyser le document en boucle, indefiniment avec un temps de pauseentre chaque analyse pour eviter de saturer la machine. Le fait de faire celadans une tache parallele, permet de valider le source xml tout en continuantson edition.

Java dispode d’une classe Thread (java.lang.Thread) deja implementee.Il suffit de faire heriter notre classe EditeurThread (la classe qui est destineea parser le document) de cette derniere et de surcharger la methode run()

15

qui sera appelee par la methode start() sur l’instance d’EditeurThread.

3.4.3 Algorithme de Parsage

Le principe du parseur threade est donc d’instancier 2 constructeurs dedocument (un qui parsera de maniere validante et l’autre de maniere non va-lidante) et d’appeler en boucle la methode parse() du constructeur adequat.On a besoin de 2 parsers, car si on declare le parser validant, et que l’uti-lisateur n’a pas specifie de DTD, le parser va generer une exception, memesi le document est bien forme. Si le document contient la chaıne de ca-racteres “< !DOCTYPE” (on verifie cela a l’aide d’une expression reguliere)on parsera de maniere validante, sinon on parsera de maniere non validante.Cependant si on parse de maniere non validante, et que l’on rencontre uneexception liee a la DTD, on devra reparser le document de maniere nonvalidante afin de pouvoir creer le Document si le XML est bien forme.

Nous avons egalement cree la classe GestionnaireErreur, afin de traiterles erreurs de parsage.

L’algorithme 1 page suivante definit ce que fait la methode run() deEditeurThread, pour parser le XML.

16

Algorithme 1 Algorithme de parsage XMLconstructeurV alidant← fabriqueV alidante.nouveauConstructeur()constructeurNonV alidant← fabriqueNonV alidante.nouveauConstructeur()constructeurV alidant.affecteGestionnaireErreur(GestionnaireErreur)constructeurNonV alidant.affecteGestionnaireErreur(GestionnaireErreur)boucler

messageErreur ← “”si on a un fichier qui a le focus dans l’interface alors

contenu← codeSourceF ichiersi contenu.contient(“< !DOCTYPE”) alors

document← constructeurV alidant.parser(contenu)sinon

document← constructeurNonV alidant.parser(contenu)finsisi on a une erreur de syntaxe alors

messageErreur ←“Erreur fatale”sinon si on a une erreur de DTD alors

messageErreur ←“Erreur DTD”document← constructeurNonV alidant.parser(contenu)si on a une erreur de syntaxe alors

messageErreur ←“Erreur fatale”finsi

sinonmessageErreur ←“OK”

finsisinon

document← nilmessageErreur ←“Fenetre de compilation”

finsifin boucle

17

3.5 La fermeture electrique

Cette fonctionnalite est utile dans l’edition et la creation de fichier XML.En effet, elle permet a l’utilisateur de gagner du temps au niveau de lafermeture de balise. Ceci permet aux balises ouvrantes (par exemple <test>)de se fermer automatiquement et ainsi, a la suite de la balise ouvrante serajoute la balise fermante (dans l’exemple </test>).

Le probleme de cette fonctionnalite est que cela doit permettre a l’uti-lisateur d’obtenir le plus souvent ce qu’il veut, et que des fermetures debalises automatiques inutiles ne doivent pas avoir lieu. Pour realiser cettefonctionnalite, plusieurs possibilites ont ete envisagees :

Dans un premier temps, on aurait pu realiser cette fermeture a l’aided’un thread, celui-ci parcourant le texte, et en fonction des balises ouvrantespresentes (sans leur homologue fermant), celles-ci seraient automatiquementfermees. Cette methode n’a pas ete retenue pour plusieurs raisons :

– Elle est plutot lourde au niveau de l’utilisation de ressources,– elle n’est pas assez interactive, instantanee avec l’utilisateur, et donc

elle peut ralentir l’utilisateur plutot que de lui faire gagner du temps.Une autre solution, celle qui a ete retenue, consiste a mettre en place

un KeyListener sur le textPane (a savoir le contenu du fichier XML) avecla touche “>”. Plus precisement, a chaque pression de la touche “>” parl’utilisateur, une action va se realiser. Plusieurs tests vont donc avoir lieupour savoir si la balise doit etre fermee automatiquement ou non. Les testseffectues verifient l’etat de la balise qui va etre fermee. Voici un exemple destests effectues lors de la pression de la touche “>” :

– Si la balise balise ouvrante est de type “<test />” elle ne doit pas etrefermee,

– Si on a “<test</test>”, l’ajout du caracteres “>” apres le debut debalise “<test” ne doit pas engendrer une fermeture de balise. . .

Pour gagner du temps, ainsi qu’une meilleure validation, quelques rajoutsde fonctionnalites ont ete effectues. Dans une balise ouvrante, il ne doit pasy avoir d’espace a la suite du caractere “<” pour que le fichier XML soitvalide ; si l’utilisateur en met, ils sont automatiquement supprimes. Unebalise vide ne sera egalement pas fermee automatiquement, cela aurait peud’interet, et peut eviter des erreurs.

L’ecriture electrique peut etre desactivee dans les options (voir para-graphe suivant), pour permettre a l’utilisateur de creer un fichier comme ille souhaite, sans l’assistance de fermeture automatique.

3.6 Les options (Serialisation)

Les options permettent a l’utilisateur d’avoir une application la plusproche de ce qu’il souhaite. Dans notre cas, nous avons prefere mettre des

18

options relatives au fonctionnement de l’application, et non des options su-perflues comme un theme ou couleur de l’application (par manque de temps).Celles que nous avons retenues sont la redefinition de la valeur d’une tabu-lation, l’affichage du numero de ligne, la desactivation de la fermeture au-tomatique de balise, ou encore la sauvegarde de fichiers ouverts lors de lafermeture de l’application.

Un des avantages non negligeable dans les options d’une application estde faire en sorte que celles-ci soient memorisees entre chaque session detravail (persistence des donnees). Pour mettre en place cette fonctionnalite,deux possibilites s’offrent a nous. La serialisation binaire, ou la serialisationXML.

La serialisation binaire est assez contraignante a mettre en place. Eneffet, elle doit implementer l’interface Serializable ou heriter d’une classeelle-meme serialisable, tous les attributs de la classe devant etre memorisesdoivent etre serialisables egalement.

Pour ce qui est de la serialisation XML, la sauvegarde est faite dans undocument XML, le resultat est donc lisible par l’utilisateur et exploitablepar d’autres programmes. En revanche, cette serialisation impose quelquescontraintes, la classe a serialiser doit avoir un constructeur par defaut (sansparametre), les attributs a serialiser doivent posseder des accesseurs / mo-difieurs de la forme JavaBean. Le resultat de la serialisation XML est plusimportant que celui de la serialisation binaire.

Nous avons donc choisi la serialisation XML pour sa reutilisation pluspolyvalente, sa lisibilite, mais aussi car nous faisons un editeur XML, et qu’ilparait donc plus logique de memoriser nos options dans un fichier XML.

3.7 Generation de la DTD

Notre logiciel offre la possibilite de creer une DTD (Document TypeDefinition) a partir du XML. Une DTD est une grammaire permettant deverifier la conformite du document XML, elle n’est pas obligatoire. Elle peutetre declaree de facon interne ou de facon externe. Par exemple le fichierXML suivant :

<annuaire><personne type="etudiant">

<nom>VINYES</nom><prenom>Francois</prenom><email>francois@gmail.com</email>

</personne><personne type="chanteur">

<nom>BRANDT</nom><prenom>Mike</prenom><email>laisse.moi-taimer@wanadoo.fr</email>

19

</personne></annuaire>

Pourra etre valide par la DTD suivante :

<!ELEMENT annuaire (personne*)><!ELEMENT personne (nom,prenom,email+)><!ATTLIST personne type (etudiant | professeur | chanteur)><!ELEMENT nom (#PCDATA)><!ELEMENT prenom (#PCDATA)><!ELEMENT email (#PCDATA)>

Cette fonctionnalite se revele utile, car la creation manuelle de DTDpar l’utilisateur est un processus souvent fastidieux. Pour pouvoir genererla DTD nous allons utiliser l’API SAX.

3.7.1 Syntaxe de la DTD

ElementsDans une DTD les elements sont references de la maniere suivante :“< !ELEMENT nomElement ListeElementsImbriques >”La liste d’elements imbriques peut se presenter sous 2 formes differentes.

C’est cela qui a pose le plus de problemes lors de la realisation de la fonc-tionalite.

Tout d’abord cette liste peut avoir la forme “(elementFils1, element-Fils2 ?, elementFils3+, elementFils4*. . .)”. Les symbole “ ?”, “+” et “*”definissent le nombre d’occurences de chaque element fils dans chaque elementde nom nomElement. Dans notre exemple, elementFils1 est present une foisdans chaque element nomElement, elementFils2 est present 0 ou 1 fois, ele-mentFils3 est present au moins 1 fois et elementFils4 peut etre present uneou plusieurs fois. Cette methode est la plus restrictive, et donc la plus effi-cace pour la creation de DTD, mais elle implique que l’ordre des elementssoit sequentiel dans chaque element parent (Dans notre exemple, la baliseelementFils1 doit obligatoirement se trouver avant elementFils2 qui doit setrouver avant elementFils3. . .).

Cette liste peut egalement prendre la forme “(elementFils1 | element-Fils2 | elementFils3. . .)*”. Cette forme permet d’avoir n’importe quelle oc-curence de chaque element de la liste dans n’importe quel ordre, ce qui sim-plifie. Cependant on perd toute indication sur les occurences des elements.

C’est pour cela que nous allons devoir verifier la sequentialite de chaqueelement dans ses elements parents.

AttributsDans la DTD, on gere les attributs de la maniere suivante “< !ATTLIST

20

Element Attribut Type occurence¿. Dans notre cas le type sera toujours“CDATA” (type litteral) et l’occurence sera soit “#IMPLIED” (si l’attributn’est pas obligatoire) ou “#REQUIRED” (si l’attribut est obligatoire).

3.7.2 L’API SAX

Pour creer la DTD on utilise l’API SAX (Simple API for XML) quicomme l’API DOM parse le code XML, mais a la difference de ce dernieril utilise une approche evenementielle. C’est-a-dire qu’elle permet de reagira des evenements (comme le debut d’un element, la fin d’un element) et derenvoyer le resultat a l’application utilisant cette API.

Notre classe CreationDTD (qui genere le code de la DTD) herite doncde la classe DefaultHandler (pour pouvoir gerer les evenements de SAX).On surchargera 3 methodes de cette classe :

startElement() : Cette methode se lance lorsque l’on rentre dans un ele-ment (une balise). On se sert de cette methode pour gerer les attributset les elements fils.

endElement() : Cette methode se lance lorsque l’on sort d’un element.Elle sert a verifier apres coup si un element est optionnel ou non dansson element pere.

characters() : Cette methode se lance lorsque l’on rencontre un CDATAdans l’element. On s’en servira donc pour notifier l’element qu’il contientun CDATA.

3.7.3 Insertion dans le XML

A la creation de la DTD, on propose a l’utilisateur de l’associer au fi-chier XML. Si tel est son souhait, on l’integrera en tant que DTD externe(en forcant sa sauvegarde). On ajoutera la ligne (ou remplacera si elle est dejaexistante) “< !DOCTYPE elementRacine SYSTEM “cheminAbsoluDTD”>”.

3.8 La completion si DTD

Cette fonctionnalite permet d’accelerer l’ecriture d’un document XMLtout en respectant les regles d’une DTD.

Elle consiste a proposer une liste de balises autorisees a l’utilisateurlorsque celui-ci en effectue la demande (par les touches CTRL+espace). Unesimple selection (a la souris ou au clavier) dans cette liste suffit ensuite pourcompleter la balise en cours d’ecriture.

Une balise est dite autorisee si elle figure dans la liste des balises auto-risees de la balise parente.

La figure 3.7 page suivante represente un apercu de la completion dansl’editeur XML.

21

Fig. 3.7 – Apercu de la completion.

3.8.1 Principe

Voici les objets utilisees pour implementer cette fonctionnalite :– Un Set contenant les elements possibles,– une JList pour afficher le Set,– une JWindow pour afficher la JList a la position du curseur dans le

TextPaneLes differentes etapes du processus appele a la pression des touches

CTR+espace :On remarque d’abord que cette fonctionnalite est justifiee uniquement

si une DTD a ete prealablement declaree au debut du document. Telle estdonc la premiere verification qui stoppe le reste du processus si aucune DTDn’est presente.

La deuxieme etape consiste a construire le Set. Pour cela, il faut d’abordretrouver l’uri de la DTD puis d’en lire le contenu. Or, afin de filtrer lesbalises qui ne doivent pas etre proposees, il est necessaire de determiner labalise parente, c’est a dire la balise ouverte et non-fermee la plus prochequand on remonte en arriere a partir de la position du curseur. Cette re-cherche est realisee par une fonction recurrente. Une fois la DTD et la baliseparente recuperees, il suffit d’extraire la liste correspondante a la balise pa-rente dans le contenu de la DTD.

Au fur et a mesure que l’utilisateur ecrit le nom de la balise, la JListdoit pouvoir se mettre a jour pour n’afficher que les balises autorisees quiont la meme homographie que le mot en cours d’ecriture. Un dernier filtrageest donc effectue en recuperant le debut du mot et ceci, a chaque fois qu’uncaractere est entre ou supprime par l’utilisateur alors que la JList est visible(grace a un DocumentListener sur le TextPane).

Enfin, il ne reste plus qu’a afficher la JList. Celle-ci est integree dans uneJWindow qui a l’avantage d’etre positionnee n’importe ou dans l’ecran eten particulier sous le curseur pour une facilite d’utilisation.

Toutes les recherches effectuees pour cette fonctionnalite sont faites al’aide des expressions regulieres.

22

Chapitre 4

Resultats

La figure 4.1 represente un apercu de notre logiciel termine.

Fig. 4.1 – Editeur XML.

On se rend compte des principales fonctionnalites proposees :– Une navigation dans la fenetre principale du source XML, avec possi-

bilite d’ouvrir plusieurs fichiers en meme temps sous forme d’onglets,

23

– une fenetre de navigation simplifiee sous forme d’arbre a droite,– une fenetre de compilation explicitant les erreurs de syntaxe ou de

DTD en bas.On peut redimensionner les elements manuellement grace a la souris.Des interactions sont possibles entre ces differents elements :– La fenetre de compilation indique les erreurs du source XML de l’on-

glet courant, s’il y en a.– L’arbre se met a jour a partir de l’onglet qui possede le focus, si celui-ci

ne presente pas d’erreur de syntaxe (XML mal forme).– Si on selectionne un item dans l’arbre (element, attribut ou texte),

alors l’item correspondant dans le source est mis en surbrillance dansla fenetre principale (comme sur l’image 4.1 page precedente).

Des fonctionnalites supplementaires sont disponibles quand on edite ma-nuellement le code source :

– Coloration syntaxique du XML (multithread),– indentation automatique,– ecriture electrique (ajout automatique de balise fermante si necessaire),– completion automatique en fonction de la DTD (raccourci ctrl + esp).De plus nous avons cree une barre d’outils qui reprend certaines fonc-

tionnalites des menus “fichier” et “edition” de la barre de menus :– Creer un nouveau fichier,– ouvrir un fichier existant,– enregistrer/enregistrer sous,– couper/copier/coller,– annuler/repeter.De plus la barre d’outils comporte la fonction Rechercher.Pour finir la barre de menus possede, en supplement de la barre d’outils,

les fonctionnalites suivantes :– Imprimer/Quitter dans “fichier”,– creation DTD/Apercu dans le navigateur/Options dans “outils”,– A propos dans “Aide”.Toutes les fonctionnalites de la barre de menus sont accessibles via des

raccourcis clavier.

24

Chapitre 5

Conclusion

Pour conclure nous avons repondu en partie a toutes les exigences definiesdans le cahier des charges en nous assurant de bien respecter les normeslogicielles actuelles, qui impliquent une bonne intuitivite et une efficacite atoute epreuve.

Nous avons fourni un programme proche, aussi bien au niveau de l’inter-face que des fonctionnalites existantes, des logiciels sur lesquels nous noussommes bases au debut du projet, lors de la phase d’analyse.

Ce projet nous a permis d’aborder, avec d’avantage de consistance, lesnouvelles technologies que sont le XML et les API associees (DOM et SAX)qui sont en pleine expansion dans le domaine du web.

Nous avons egalement profite de ce projet pour acquerir une nouvelleexperience dans le travail en equipe et en collaboration. Nous avons du fairepreuve d’organisation et mettre en place les dispositifs de travail collaboratiftel que subversion.

Ce travail en collaboration nous a egalement fais prendre conscience del’importance de programmer lisiblement, en commentant rigoureusement eten respectant des normes predefinies, afin que chacun puisse reutiliser sansdifficulte le code d’un autre.

Nous remercions notre maitre de projet, M. Meynard, pour ses explica-tions claires, qui nous ont permis d’avancer efficacement.

En annexe se trouve la documentation complete (Javadoc) du logicielque nous avons implemente.

25

Table des figures

2.1 Interface d’Assembla. . . . . . . . . . . . . . . . . . . . . . . . 62.2 Diagramme de Gantt de notre projet . . . . . . . . . . . . . . 7

3.1 Schema des modeles dans l’editeur XML. . . . . . . . . . . . 93.2 Schema des vues dans l’editeur XML. . . . . . . . . . . . . . 103.3 Schema du controleur dans l’editeur XML. . . . . . . . . . . . 113.4 Diagramme de classe de l’editeur XML. . . . . . . . . . . . . 123.5 Hierarchie de confinement de l’interface graphique. . . . . . . 133.6 Interface Graphique de l’editeur XML. . . . . . . . . . . . . . 143.7 Apercu de la completion. . . . . . . . . . . . . . . . . . . . . 22

4.1 Editeur XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

26