RAPPORT DE PROJET Editeur XML Responsable de projet : Michel Meynard

RAPPORT DE PROJET Editeur XML Responsable de projet : Michel Meynard Université Montpellier 2 - M1 Informatique S2 CHANTEMESSE Florian NOYARET Pierre REY Cyrille VINYES François 25 avril 2008

Table des matières 1 Introduction 2 2 Organisation et répartition du travail 3 2.1 Analyse de l existant....................... 3 2.2 Moyens mis en place pour le travail en collaboration..... 5 2.3 Répartition du travail...................... 6 3 Mise en œuvre 8 3.1 Définition du XML........................ 8 3.2 Modélisation........................... 8 3.2.1 Le modèle......................... 8 3.2.2 Les vues.......................... 9 3.2.3 Le contrôleur....................... 10 3.2.4 Le diagramme de classe................. 11 3.3 Conception de l interface graphique............... 12 3.4 Parsage du fichier XML..................... 14 3.4.1 L API DOM....................... 15 3.4.2 Thread.......................... 15 3.4.3 Algorithme de Parsage.................. 16 3.5 La fermeture électrique...................... 18 3.6 Les options (Serialisation).................... 18 3.7 Génération de la DTD...................... 19 3.7.1 Syntaxe de la DTD.................... 20 3.7.2 L API SAX........................ 21 3.7.3 Insertion dans le XML.................. 21 3.8 La completion si DTD...................... 21 3.8.1 Principe.......................... 22 4 Resultats 23 5 Conclusion 25 1

Chapitre 1 Introduction Il nous a été demandé lors de ce TER de réaliser un éditeur XML qui comporte les fonctionnalités suivantes : Edition brute du source XML, édition arborescente (ou mode plan) du document XML, ouverture et fermeture de sous-arborescences en un clic, validation en continu grâce à des tâches multiples en parallèle, aide à l écriture d une DTD (inférence de DTD), visualisation dans un navigateur d un document XML associé à une feuille de style, coloration syntaxique, complétion automatique si DTD, écriture électrique. Nous avons donc dans un premier temps cherché à spécifier les demandes de notre responsable de projet, M. Meynard. Nous avons programmé cet éditeur en Java, conformément à ce que nous a indiqué M. Meynard. Ce langage en plus d être connu de tout le groupe, est facilement portable sur tous les systèmes d exploitation pourvus de la machine virtuelle Java. Nous avons nommé cet éditeur Loligo XML. Dans notre mémoire nous allons décrire comment nous avons procédé et quelles solutions nous avons proposées pour implémenter les différentes fonctionnalités à notre outil. 2

Chapitre 2 Organisation et répartition du travail 2.1 Analyse de l existant Nous avons choisi d analyser quatre célèbres éditeurs XML afin de repérer les fonctionnalités intéressantes propres au langage XML. Parmi ces éditeurs, seul Jedit est gratuit (et open source). Le prix des licences des trois autres varie de 80 à 400 euros. XML writer Fonctionnalités intéressantes : Vue en arbre, vérification de la validité : document bien formé, TagBar : chargement d une DTD sous forme d arbre : permet l insertion rapide d éléments ou d attributs par drag n drop. Inconvénients : Pas d interaction entre l arbre des balises et le code source, pas de vérification en temps réel. Bonus : Fermeture automatique des balises, ouverture de fichier à partir d une URL, insertion rapide de balises autour d un bloc sélectionné à la souris, assignation rapide d une feuille de style (XSLT/CSS) ou d une DTD à 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 possibilité d en rajouter. 3

oxygen Fonctionnalités intéressantes : Vue en arbre, vérification de la validité : document bien formé, complétion automatique si DTD, éditeur d arbre evolué, débogeur : xslt et squery, évaluation d expression XPath. Inconvénients : L éditeur d arbre est une application séparée. Bonus : Fermeture automatique des balises, erreurs de parsage soulignées, correcteur orthographique, client SVN, comparateur de fichiers, preview dans une nouvelle fenetre ou dans un navigateur. XMLSpy Fonctionnalités intéressantes : Vérification de la validité : document bien formé, générateur de DTD, complétion automatique si DTD, évaluation d expression XPath, transformation XSL, conversion XML en BD. Bonus : Fermeture automatique des balises, correcteur orthographique, générateur de fichier XML à partir d une DTD, comparateur de fichiers, preview dans une nouvelle fenetre ou dans un navigateur. JEdit et son plugin XML Fonctionnalités intéressantes : Vue en arbre, vérification de la validité : document bien formé, générateur de DTD, complétion automatique si DTD. Inconvénients : Pas d onglets pour les fichiers ouverts. Bonus : Erreurs de parsage soulignées, 4

éditeur de balises. Bilan Les editeurs payants sont beaucoup plus nombreux que les gratuits. La concurrence étant forte, on s aperçoit alors que ces logiciels sont très complets. Ils permettent de construire un document XML rapidement grâce à de nombreuses fonctionnalités. Parmi ces fonctionnalités, on remarque que les plus sollicitées sont : La vue en arbre, le parsage, la complétion, la fermeture automatique des balises. On remarque par ailleurs que ce sont les fonctionnalités principales qui nous ont été demandées d implémenter dans ce TER. 2.2 Moyens mis en place pour le travail en collaboration Pour mener à bien ce projet, et travailler en parallèle le plus efficacement possible, nous avons mis en place sur la plate-forme Eclipse, un plugin permettant la gestion et l interactivité avec un serveur SVN. SVN de son vrai nom Subversion, permet à tous les utilisateurs de pouvoir suivre l avancement d un projet avec une coordination optimale : chaque membre de l équipe de projet envoie ses améliorations et le projet avance car tout est ajouté en continu. En tant que serveur SVN, nous avons opté pour Assembla.com, qui grâce à son interface intuitive sur internet mais aussi sa gratuité, propose un espace de stockage gratuit de 500 Mo. Il propose également trac pour documenter et suivre les bugs, et un service d upload de fichiers afin que tous les membres puissent s échanger et partager toutes les ressources qu ils jugent nécessaires. La figure 2.1 page suivante représente un aperçu de son interface. On observe tous les onglets pouvant être utiles à une réalisation de projet (Files, Trac/SVN, Team, etc.) efficace et en collaboration avec tous les membres du projet sans provoquer de conflit et de mise à jour fastidieuse. Grâce à ce serveur, nous avons très certainement économisé une grande quantité de temps qui aurait été dédiée à diverses réunions de chacune de nos avancées. 5

Fig. 2.1 Interface d Assembla. 2.3 Répartition du travail En ce qui concerne la répartition du travail, nous avons à peu de choses près respecté le planning que nous avions prévu lors de l élaboration du cahier des charges. Ce qui peut justifier les divergences par rapport au cahier des charges est la réunion de 2 tâches en une, par exemple, la validation du source XML a été réalisée communément avec la validation par la DTD. De plus certaines fonctionnalités nous ont demandé plus de temps que prévu, mais nous avons pu compenser avec d autres tâches qui se sont avérées plus rapides à développer. A part ces quelques divergences nous avons respecté la planning, ce qui nous a permis lors de certaines semaines, d être en avance et donc de pouvoir continuer sans problème les tâches suivantes. La figure 2.2 page suivante rappelle l emploi du temps que nous avions élaboré au début du projet. 6

Fig. 2.2 Diagramme de Gantt de notre projet 7

Chapitre 3 Mise en œuvre 3.1 Définition du XML XML (extensible Markup Language) est un langage informatique à balises. Le World Wide Web Consortium (W3C), promoteur de standards favorisant l échange d informations sur Internet, recommande la syntaxe XML pour exprimer des langages de balisages spécifiques. De nombreux langages respectent la syntaxe XML : XHTML, SVG, XSLT... Son objectif initial est de faciliter l échange automatisé de contenus entre systèmes d informations hétérogènes. Voici un exemple d une structure XML : <annuaire> <ville nom="montpellier"> <personne>0123456789</personne> <personne>9876543210</personne> </ville> </annuaire> 3.2 Modélisation Pour la phase d analyse de notre éditeur, nous nous somme basés sur l architecture MVC (Modèle-Vue-Contrôleur) pour organiser l interface graphique. 3.2.1 Le modèle En tant qu éditeur gérant l ouverture de plusieurs fichiers dans une même fenêtre (système d onglets), la base du modèle est d abord constituée d une liste de fichiers ouverts. En tant qu éditeur XML, la représentation des fichiers dans l application nécessite l utilisation de la classe DefaultStyledDocument disponible 8

dans l API Java. En effet, cette classe permet la manipulation de caractères (le code source du fichier XML) grâce à son implémentation de l interface Document. Mais elle a surtout l avantage de permettre la décoration du texte contenu dans le Document par l application de style. Ainsi, le texte du Document peut être décoré sans qu aucune autre donnée concernant cette décoration ne soit rajoutée dans le code source. Outre cette instance de la classe DefaultStyledDocument, la classe FichierXML contient un booleen indiquant l état de sauvegarde du fichier et une String pour le chemin du fichier sur le disque. Le deuxième élément important du modèle est une référence vers un fichierxml particulier : le fichier en cours d édition (ou le fichier pour lequel l onglet associé a le focus ). Logiquement, ce fichier doit figurer dans la liste des fichiers ouverts citée précedemment. Fig. 3.1 Schéma des modèles dans l éditeur XML. Afin de synchroniser les vues avec le modèle, la classe FichiersOuverts possède également une liste d écouteurs. Ainsi, chaque fois qu une requête de changement de ficher en cours est demandée, la référence fichierencours est mise à jour puis l ensemble des écouteurs intéressés par le fichier en cours sont avertis de la nouvelle valeur. 3.2.2 Les vues La JFrame principale de l application contient de nombreux composants graphiques permettant l interaction avec l utilisateur. Parmi ces composants, trois sont considérés comme des vues du design pattern MVC car ils ont besoin d être tenus au courant de chaque modification du modèle. Ces trois vues correspondent aux trois fonctionnalités : VueArbre : affichage du document XML sous forme d un arbre (un JTree) 9

VueCompil : indication des erreurs de parsage VueOnglets : gestion des fichiers ouverts dans un tableau à onglets Cependant, ces trois vues ne s intéressent pas toutes aux mêmes éléments du modèle. Ainsi, VueArbre et VueCompil ne répondent que lors d un changement du fichier en cours, tandis que VueOnglets s attache principalement aux modifications de la liste des fichiers ouverts. Par convention, toutes les vues qui désirent écouter le modèle doivent hériter de la classe Vue. Cette classe abstraite sert d interface avec le contrôleur. Fig. 3.2 Schéma des vues dans l éditeur XML. 3.2.3 Le contrôleur Il est le chef d orchestre de l application. Son instance est unique. Son premier rôle est de mettre en relation les vues avec le modèle. Pour cela, il ajoute chaque vue dans la liste des écouteurs du modèle. Il sert ensuite d intermédiaire entre les vues et le modèle lors de l exécution de l application et des actions de l utilisateur. Il prend en charge la gestion des évènements de synchronisation pour mettre à jour les vues ou le modèle et les synchroniser. Il reçoit tous les évènements de l utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des données, le contrôleur demande la modification des données au modèle qui va ensuite avertir les vues concernées que les données ont changé pour qu elles se mettent à jour. Le contrôleur n effectue aucun traitement, ne modifie aucune donnée. Il analyse la requête du client et se contente d appeler le modèle. 10

Fig. 3.3 Schéma du contrôleur dans l éditeur XML. 3.2.4 Le diagramme de classe Nous avons établi le diagramme de classe 3.4 page suivante. 11

Fig. 3.4 Diagramme de classe de l éditeur XML. 3.3 Conception de l interface graphique M. Meynard nous ayant demandé une interface intuitive, nous nous sommes mis à la recherche d exemples d interfaces les plus communes et 12

conviviales possibles. Pour arriver à un résultat final, nous nous sommes basés sur des applications existantes telles qu Eclipse (Environnement de Développement Java), NotePad++ (multi-langage) et celles citées dans l analyse de l existant, qui nous ont paru les plus intéressantes en termes d intuitivité et d interactivité. Finalement nous avons donc réalisé l interface de notre éditeur XML grâce aux composants Swing de la librairie Java. En effet, celle-ci étant très complète et fonctionnelle, nous avons pu intégralement concevoir l interface grâce aux composants déjà existants, qui sont semblables aussi bien au niveau du fonctionnement que de l apparence, aux applications que nous avions auparavant sélectionnées. La figure 3.5 représente la hiérarchie de confinement de l interface. Fig. 3.5 Hiérarchie de confinement de l interface graphique. Comme nous pouvons le constater sur cette figure, nous avons intégré à la Frame principale, une JMenuBar qui compose notre barre des menus 13

(Fichier, Edition...), ainsi qu un JSplitPane, qui permet de modifier manuellement et assez facilement la taille des composants graphiques. La figure 3.6 montre un aperçu de l interface conçue à partir du schéma 3.5 page précédente. Fig. 3.6 Interface Graphique de l éditeur XML. On arrive bien à distinguer les différents éléments qui composent la fenêtre principale, et de ce fait elle se révèle assez conviviale et intuitive, car elle reprend les grandes lignes des applications actuelles. 3.4 Parsage du fichier XML L une des principales fonctionnalités que devait remplir notre éditeur XML, était de parser le code de manière threadée. Pour faire ce parsage nous avons utilisé une API (Application Programming Interface) déjà éxistante dans Java : l API DOM. Le parseur (ou analyseur syntaxique) est un outil qui récupère les données encapsulées dans le document XML en le parcourant et en extrait les informations qu il contient. 14

3.4.1 L API DOM DOM (Document Object Model) est donc un analyseur utilisant une approche hiérarchique du document (d autres API, telles que SAX etc., que nous avons utilisée pour générer la DTD à partir du XML, utilisent une approche évènementielle). Cela signifie que si le parsage réussit, DOM construit une structure de données contenant des objets représentants les éléments du document, et dont les méthodes permettent d accèder aux propriétés. On transmet ensuite cette structure à d autres classes qui pourront l utiliser (notamment pour la création de l arbre représentant le fichier XML), java implémentant par défaut une interface DOM (org.w3c.dom), et une interface Document qui contiennent les méthodes pour accéder aux attributs, aux éléments... Si le parsage ne réussit pas, DOM génère des Exceptions de type SAXException que nous récupérons et traitons de manière à les afficher dans la fenêtre de compilation, au bas de notre interface. Dans ce cas le DOM construit aura une valeur null. Il existe 2 types de parseur : Les parseurs validants permettant de vérifier qu un document XML est conforme à sa DTD, Les parseurs non validants se contentant de vérifier que le document XML est bien formé, c est-à-dire qu il respecte la syntaxe XML de base. Il est possible de spécifier à notre parseur DOM quel type de parsage il doit effectuer. Pour créer notre document DOM et le parser on doit d abord récupérer le constructeur de documents (javax.xml.parsers.documentbuilder) à partir d une fabrique de constructeur (javax.xml.parsers.documentbuilderfactory). C est ce constructeur de document qui va construire le DOM ou Document (org.w3c.document) à partir de la source XML. 3.4.2 Thread Un thread (ou Processus léger) est un processus qui du point de vue de l utilisateur, semble se dérouler en parallèle du programme. Notre application utilise un thread pour parser le document. C est à dire qu une fois les constructeurs de document créés, la tâche parallèle les utilise pour analyser le document en boucle, indéfiniment avec un temps de pause entre chaque analyse pour éviter de saturer la machine. Le fait de faire cela dans une tâche parallèle, permet de valider le source xml tout en continuant son édition. Java dispode d une classe Thread (java.lang.thread) déjà implémentée. Il suffit de faire hériter notre classe EditeurThread (la classe qui est destinée à parser le document) de cette dernière et de surcharger la méthode run() 15

qui sera appelée par la méthode start() sur l instance d EditeurThread. 3.4.3 Algorithme de Parsage Le principe du parseur threadé est donc d instancier 2 constructeurs de document (un qui parsera de manière validante et l autre de manière non validante) et d appeler en boucle la methode parse() du constructeur adéquat. On a besoin de 2 parsers, car si on déclare le parser validant, et que l utilisateur n a pas spécifié de DTD, le parser va générer une exception, même si le document est bien formé. Si le document contient la chaîne de caractères <!DOCTYPE (on vérifie cela à l aide d une expression régulière) on parsera de manière validante, sinon on parsera de manière non validante. Cependant si on parse de manière non validante, et que l on rencontre une exception liée à la DTD, on devra reparser le document de manière non validante afin de pouvoir créer le Document si le XML est bien formé. Nous avons également créé la classe GestionnaireErreur, afin de traiter les erreurs de parsage. L algorithme 1 page suivante définit ce que fait la méthode run() de EditeurThread, pour parser le XML. 16

Algorithme 1 Algorithme de parsage XML constructeurv alidant f abriquev alidante.nouveauconstructeur() constructeurn onv alidant f abriquen onv alidante.nouveauconstructeur() constructeurv alidant.affectegestionnaireerreur(gestionnaireerreur) constructeurn onv alidant.affectegestionnaireerreur(gestionnaireerreur) boucler messageerreur si on a un fichier qui a le focus dans l interface alors contenu codesourcef ichier si contenu.contient( <!DOCTYPE ) alors document constructeurv alidant.parser(contenu) sinon document constructeurn onv alidant.parser(contenu) finsi si on a une erreur de syntaxe alors messageerreur Erreur fatale sinon si on a une erreur de DTD alors messageerreur Erreur DTD document constructeurn onv alidant.parser(contenu) si on a une erreur de syntaxe alors messageerreur Erreur fatale finsi sinon messageerreur OK finsi sinon document nil messageerreur Fenetre de compilation finsi fin boucle 17

3.5 La fermeture électrique Cette fonctionnalité est utile dans l édition et la création de fichier XML. En effet, elle permet à l utilisateur de gagner du temps au niveau de la fermeture de balise. Ceci permet aux balises ouvrantes (par exemple <test>) de se fermer automatiquement et ainsi, à la suite de la balise ouvrante se rajoute la balise fermante (dans l exemple </test>). Le problème de cette fonctionnalité est que cela doit permettre à l utilisateur d obtenir le plus souvent ce qu il veut, et que des fermetures de balises automatiques inutiles ne doivent pas avoir lieu. Pour réaliser cette fonctionnalité, plusieurs possibilités ont été envisagées : Dans un premier temps, on aurait pu réaliser cette fermeture à l aide d un thread, celui-ci parcourant le texte, et en fonction des balises ouvrantes présentes (sans leur homologue fermant), celles-ci seraient automatiquement fermées. Cette méthode n a pas été retenue pour plusieurs raisons : Elle est plutôt lourde au niveau de l utilisation de ressources, elle n est pas assez intéractive, instantanée avec l utilisateur, et donc elle peut ralentir l utilisateur plutôt que de lui faire gagner du temps. Une autre solution, celle qui a été retenue, consiste à mettre en place un KeyListener sur le textpane (à savoir le contenu du fichier XML) avec la touche >. Plus précisément, à chaque pression de la touche > par l utilisateur, une action va se réaliser. Plusieurs tests vont donc avoir lieu pour savoir si la balise doit être fermée automatiquement ou non. Les tests effectués vérifient l état de la balise qui va être fermée. Voici un exemple des tests effectués lors de la pression de la touche > : Si la balise balise ouvrante est de type <test /> elle ne doit pas être fermée, Si on a <test</test>, l ajout du caractères > après le début de balise <test ne doit pas engendrer une fermeture de balise... Pour gagner du temps, ainsi qu une meilleure validation, quelques rajouts de fonctionnalités ont été effectués. Dans une balise ouvrante, il ne doit pas y avoir d espace à la suite du caractère < pour que le fichier XML soit validé ; si l utilisateur en met, ils sont automatiquement supprimés. Une balise vide ne sera également pas fermée automatiquement, cela aurait peu d intérêt, et peut éviter des erreurs. L écriture électrique peut être désactivée dans les options (voir paragraphe suivant), pour permettre à l utilisateur de créer un fichier comme il le souhaite, sans l assistance de fermeture automatique. 3.6 Les options (Serialisation) Les options permettent à l utilisateur d avoir une application la plus proche de ce qu il souhaite. Dans notre cas, nous avons préféré mettre des 18

options relatives au fonctionnement de l application, et non des options superflues comme un thème ou couleur de l application (par manque de temps). Celles que nous avons retenues sont la redéfinition de la valeur d une tabulation, l affichage du numéro de ligne, la désactivation de la fermeture automatique de balise, ou encore la sauvegarde de fichiers ouverts lors de la fermeture de l application. Un des avantages non négligeable dans les options d une application est de faire en sorte que celles-ci soient mémorisées entre chaque session de travail (persistence des données). Pour mettre en place cette fonctionnalité, deux possibilités s offrent à nous. La sérialisation binaire, ou la sérialisation XML. La sérialisation binaire est assez contraignante à mettre en place. En effet, elle doit implémenter l interface Serializable ou hériter d une classe elle-même sérialisable, tous les attributs de la classe devant être mémorisés doivent être sérialisables également. Pour ce qui est de la sérialisation XML, la sauvegarde est faite dans un document XML, le résultat est donc lisible par l utilisateur et exploitable par d autres programmes. En revanche, cette sérialisation impose quelques contraintes, la classe à sérialiser doit avoir un constructeur par défaut (sans paramètre), les attributs à sérialiser doivent posséder des accesseurs / modifieurs de la forme JavaBean. Le résultat de la sérialisation XML est plus important que celui de la sérialisation binaire. Nous avons donc choisi la sérialisation XML pour sa réutilisation plus polyvalente, sa lisibilité, mais aussi car nous faisons un éditeur XML, et qu il parait donc plus logique de mémoriser nos options dans un fichier XML. 3.7 Génération de la DTD Notre logiciel offre la possibilité de créer une DTD (Document Type Definition) à partir du XML. Une DTD est une grammaire permettant de vérifier la conformité du document XML, elle n est pas obligatoire. Elle peut être déclarée de façon interne ou de façon externe. Par exemple le fichier XML suivant : <annuaire> <personne type="étudiant"> <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 être validé par la DTD suivante : <!ELEMENT annuaire (personne*)> <!ELEMENT personne (nom,prenom,email+)> <!ATTLIST personne type (étudiant professeur chanteur)> <!ELEMENT nom (#PCDATA)> <!ELEMENT prenom (#PCDATA)> <!ELEMENT email (#PCDATA)> Cette fonctionnalité se révèle utile, car la création manuelle de DTD par l utilisateur est un processus souvent fastidieux. Pour pouvoir générer la DTD nous allons utiliser l API SAX. 3.7.1 Syntaxe de la DTD Elements Dans une DTD les éléments sont référencés de la manière suivante : <!ELEMENT nomelement ListeElementsImbriqués > La liste d éléments imbriqués peut se présenter sous 2 formes différentes. C est cela qui a posé le plus de problèmes lors de la réalisation de la fonctionalité. Tout d abord cette liste peut avoir la forme (elementfils1, element- Fils2?, elementfils3+, elementfils4*...). Les symbole?, + et * définissent le nombre d occurences de chaque élément fils dans chaque élément de nom nomelement. Dans notre exemple, elementfils1 est présent une fois dans chaque élément nomelement, elementfils2 est présent 0 ou 1 fois, elementfils3 est présent au moins 1 fois et elementfils4 peut être présent une ou plusieurs fois. Cette méthode est la plus restrictive, et donc la plus efficace pour la création de DTD, mais elle implique que l ordre des éléments soit séquentiel dans chaque élément parent (Dans notre exemple, la balise elementfils1 doit obligatoirement se trouver avant elementfils2 qui doit se trouver avant elementfils3...). Cette liste peut également prendre la forme (elementfils1 element- Fils2 elementfils3...)*. Cette forme permet d avoir n importe quelle occurence de chaque élément de la liste dans n importe quel ordre, ce qui simplifie. Cependant on perd toute indication sur les occurences des éléments. C est pour cela que nous allons devoir vérifier la séquentialité de chaque élément dans ses éléments parents. Attributs Dans la DTD, on gère les attributs de la manière 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 attribut n est pas obligatoire) ou #REQUIRED (si l attribut est obligatoire). 3.7.2 L API SAX Pour créer la DTD on utilise l API SAX (Simple API for XML) qui comme l API DOM parse le code XML, mais à la différence de ce dernier il utilise une approche évènementielle. C est-à-dire qu elle permet de réagir à des événements (comme le début d un élément, la fin d un élément) et de renvoyer le résultat à l application utilisant cette API. Notre classe CreationDTD (qui génère le code de la DTD) hérite donc de la classe DefaultHandler (pour pouvoir gérer les évènements de SAX). On surchargera 3 méthodes de cette classe : startelement() : Cette méthode se lance lorsque l on rentre dans un element (une balise). On se sert de cette méthode pour gérer les attributs et les éléments fils. endelement() : Cette méthode se lance lorsque l on sort d un élément. Elle sert à vérifier après coup si un élément est optionnel ou non dans son élément père. characters() : Cette méthode se lance lorsque l on rencontre un CDATA dans l élément. On s en servira donc pour notifier l élément qu il contient un CDATA. 3.7.3 Insertion dans le XML A la création de la DTD, on propose à l utilisateur de l associer au fichier XML. Si tel est son souhait, on l intègrera en tant que DTD externe (en forçant sa sauvegarde). On ajoutera la ligne (ou remplacera si elle est déjà existante) <!DOCTYPE elementracine SYSTEM cheminabsoludtd >. 3.8 La completion si DTD Cette fonctionnalité permet d accélérer l écriture d un document XML tout en respectant les règles d une DTD. Elle consiste à proposer une liste de balises autorisées à l utilisateur lorsque celui-ci en effectue la demande (par les touches CTRL+espace). Une simple sélection (à la souris ou au clavier) dans cette liste suffit ensuite pour compléter la balise en cours d écriture. Une balise est dite autorisée si elle figure dans la liste des balises autorisées de la balise parente. La figure 3.7 page suivante représente un aperçu de la complétion dans l éditeur XML. 21

Fig. 3.7 Aperçu de la completion. 3.8.1 Principe Voici les objets utilisées pour implémenter cette fonctionnalité : Un Set contenant les éléments possibles, une JList pour afficher le Set, une JWindow pour afficher la JList à la position du curseur dans le TextPane Les différentes étapes du processus appelé à la pression des touches CTR+espace : On remarque d abord que cette fonctionnalité est justifiée uniquement si une DTD a été préalablement déclarée au début du document. Telle est donc la première vérification qui stoppe le reste du processus si aucune DTD n est présente. La deuxième étape consiste à construire le Set. Pour cela, il faut d abord retrouver l uri de la DTD puis d en lire le contenu. Or, afin de filtrer les balises qui ne doivent pas être proposées, il est nécessaire de déterminer la balise parente, c est à dire la balise ouverte et non-fermée la plus proche quand on remonte en arrière à partir de la position du curseur. Cette recherche est réalisée par une fonction récurrente. Une fois la DTD et la balise parente récupérées, il suffit d extraire la liste correspondante à la balise parente dans le contenu de la DTD. Au fur et à mesure que l utilisateur écrit le nom de la balise, la JList doit pouvoir se mettre à jour pour n afficher que les balises autorisées qui ont la même homographie que le mot en cours d écriture. Un dernier filtrage est donc effectué en récupérant le début du mot et ceci, à chaque fois qu un caractère est entré ou supprimé par l utilisateur alors que la JList est visible (grâce à un DocumentListener sur le TextPane). Enfin, il ne reste plus qu à afficher la JList. Celle-ci est intégrée dans une JWindow qui a l avantage d être positionnée n importe où dans l écran et en particulier sous le curseur pour une facilité d utilisation. Toutes les recherches effectuées pour cette fonctionnalité sont faites à l aide des expressions régulières. 22

Chapitre 4 Resultats La figure 4.1 représente un aperçu de notre logiciel terminé. Fig. 4.1 Editeur XML. On se rend compte des principales fonctionnalités proposées : Une navigation dans la fenêtre principale du source XML, avec possibilité d ouvrir plusieurs fichiers en même temps sous forme d onglets, 23

une fenêtre de navigation simplifiée sous forme d arbre à droite, une fenêtre de compilation explicitant les erreurs de syntaxe ou de DTD en bas. On peut redimensionner les éléments manuellement grâce à la souris. Des interactions sont possibles entre ces différents éléments : La fenêtre de compilation indique les erreurs du source XML de l onglet courant, s il y en a. L arbre se met à jour à partir de l onglet qui possède le focus, si celui-ci ne présente pas d erreur de syntaxe (XML mal formé). Si on sélectionne un item dans l arbre (élément, attribut ou texte), alors l item correspondant dans le source est mis en surbrillance dans la fenêtre principale (comme sur l image 4.1 page précédente). Des fonctionnalités supplémentaires sont disponibles quand on édite manuellement le code source : Coloration syntaxique du XML (multithread), indentation automatique, écriture électrique (ajout automatique de balise fermante si nécessaire), complétion automatique en fonction de la DTD (raccourci ctrl + esp). De plus nous avons créé une barre d outils qui reprend certaines fonctionnalités des menus fichier et édition de la barre de menus : Créer un nouveau fichier, ouvrir un fichier existant, enregistrer/enregistrer sous, couper/copier/coller, annuler/répéter. De plus la barre d outils comporte la fonction Rechercher. Pour finir la barre de menus possède, en supplément de la barre d outils, les fonctionnalités suivantes : Imprimer/Quitter dans fichier, création DTD/Aperçu dans le navigateur/options dans outils, A propos dans Aide. Toutes les fonctionnalités de la barre de menus sont accessibles via des raccourcis clavier. 24

Chapitre 5 Conclusion Pour conclure nous avons répondu en partie à toutes les exigences définies dans le cahier des charges en nous assurant de bien respecter les normes logicielles actuelles, qui impliquent une bonne intuitivité et une efficacité à toute épreuve. Nous avons fourni un programme proche, aussi bien au niveau de l interface que des fonctionnalités existantes, des logiciels sur lesquels nous nous sommes basés au début du projet, lors de la phase d analyse. Ce projet nous a permis d aborder, avec d avantage de consistance, les nouvelles technologies que sont le XML et les API associées (DOM et SAX) qui sont en pleine expansion dans le domaine du web. Nous avons également profité de ce projet pour acquérir une nouvelle expérience dans le travail en équipe et en collaboration. Nous avons du faire preuve d organisation et mettre en place les dispositifs de travail collaboratif tel que subversion. Ce travail en collaboration nous a également fais prendre conscience de l importance de programmer lisiblement, en commentant rigoureusement et en respectant des normes prédéfinies, afin que chacun puisse réutiliser sans difficulté le code d un autre. Nous remercions notre maitre de projet, M. Meynard, pour ses explications claires, qui nous ont permis d avancer efficacement. En annexe se trouve la documentation complète (Javadoc) du logiciel que nous avons implémenté. 25

Table des figures 2.1 Interface d Assembla........................ 6 2.2 Diagramme de Gantt de notre projet.............. 7 3.1 Schéma des modèles dans l éditeur XML............ 9 3.2 Schéma des vues dans l éditeur XML.............. 10 3.3 Schéma du contrôleur dans l éditeur XML............ 11 3.4 Diagramme de classe de l éditeur XML............. 12 3.5 Hiérarchie de confinement de l interface graphique....... 13 3.6 Interface Graphique de l éditeur XML.............. 14 3.7 Aperçu de la completion..................... 22 4.1 Editeur XML............................ 23 26