CCAHIERAHIER DESDES CHARGESCHARGES

TER Gestionnaires de contenu en ligneTER Gestionnaires de contenu en ligne

Introduction...............................................................................................................................2Objectifs..............................................................................................................................................2

Contexte...............................................................................................................................................3

Organisation...............................................................................................................................4Processus.............................................................................................................................................4

Organisation structurelle...................................................................................................................5Présentation.....................................................................................................................................................5Objectifs et priorités........................................................................................................................................7Hypothèses et dépendances.............................................................................................................................8Limites et Interfaces........................................................................................................................................9Contraintes non fonctionnelles......................................................................................................................11Risques..........................................................................................................................................................12

Moyens de contrôle..................................................................................................................13Communication................................................................................................................................13

Gestion de versions...........................................................................................................................14

Tests...................................................................................................................................................14

Techniques utilisées.................................................................................................................15Choix techniques..............................................................................................................................15

Editeur WYSIWYG.......................................................................................................................................15Outil de refactoring........................................................................................................................................15Service Web...................................................................................................................................................16

Logiciels de développement.............................................................................................................16

Documentation..................................................................................................................................17

Planification(s)..................................................................................................................................18

Glossaire...................................................................................................................................19

Annexes....................................................................................................................................22Annexe A1 : Description des lots concernant l’éditeur WYSIWYG...........................................22

Annexe A2 : Fichier de test (en syntaxe TWiki) pour l'éditeur WYSIWYG..............................24

Annexe A3 : Analyses XUL.............................................................................................................26Rapport étude Composer et XUL dans page Web (03/2004)........................................................................26Rapport Nvu (03/2004)..................................................................................................................................28

Introduction

L’objectif du projet est de réaliser deux applications qui viendront compléter l’outil TWiki1. Il s’agit d’un outil informatique de collaboration entre utilisateurs qui partagent des informations. TWiki est notamment utilisé dans les réseaux d’entreprise (intranet) pour permettre la collaboration et la coordination des équipes.

Pour composer des documents, la syntaxe de TWiki est assez simple, cependant certains utilisateurs peuvent être rebuté par ce mode d’écriture. Cela nous conduit au premier but du projet :

Réaliser un éditeur de type WYSIWYG* qui permettra l’édition en mode graphique des pages écrites en syntaxe TWiki. Nous reviendrons plus loin sur le contexte et les modalités de mise en œuvre d’une telle approche.

D’autre part, un site TWiki est composé d’un ensemble de pages (les topics) regroupés en dossiers appelés webs. Il est possible de déplacer et renommer les topics (et les webs ?), via l’interface textuelle de TWiki, depuis un navigateur web. Cependant, tout comme pour l’écriture de documents, l’interface proposée peut sembler inadéquate à l’utilisation par des utilisateurs peu formés aux outils informatique. Le deuxième but est donc le suivant :

Réaliser un outil de refactoring* qui permettra le déplacement d’une page ou d’un groupe de page dans l’arborescence d’un site TWiki. Cela sera fait par l’intermédiaire d’une application qui représentera graphiquement cette structure arborescente.

Ce projet est encadré par Colas Nahaboo, membre de l’équipe de développement de TWiki et Michel Buffa.

ObjectifsVoici les objectifs fixés :

Réaliser un projet abouti et extensible, réutilisable pour des développements futurs. Par abouti, nous entendons le fait que les fonctionnalités offertes doivent être fonctionnelles et réalisées avec soin (documentation et lisibilité du code, dans l’hypothèse d’une continuation du projet). Nous souhaitons que la structure logicielle anticipe les développements futurs.

L’application réalisée s’appliquera à innover pour un projet relatif à TWiki. En effet, une approche Web Service* sera employée pour communiquer entre les clients développés et le serveur TWiki. Cela sera développé en détail par la suite car cela constitue un des trois pôles de développement. Voici une représentation schématique de l’architecture envisagée :

1 Dans ce document, les mots ou acronymes marqués par un astérisque sont défini dans le glossaire, nous encourageons le lecteur à consulter ces définitions au fur et à mesure de la lecture. Twiki est défini dans le glossaire.

2

Colas Nahaboo est également responsable du maintien de TWiki dans l’intranet de son entreprise, ILOG. Ce projet répond à un besoin de la part d’ILOG et tout sera mis en œuvre pour y répondre.

ContexteLa société ILOG (à Sophia Antipolis) utilise avec succès TWiki dans son intranet. Le contexte d’utilisation est donc isolé de l’extérieur.

Dans le contexte de la collaboration entre l’université et ILOG, un projet étudiant portant sur TWiki à déjà vu le jour (filière MIAGE). Une partie de ce projet sera réutilisée, comme nous le verrons par la suite.

La communauté TWiki s’intéresse au projet, Peter Thoeny (auteur de TWiki) à déjà pris contact avec nous par l’intermédiaire d’un topic sur le site officiel www.twiki.org, il figure donc parmi les objectifs d’apporter notre contribution à cette communauté.

3

Organisation

ProcessusNous avons divisé l’organisation générale de ce projet en deux phases, une phase d’analyse logicielle commune, afin de déterminer les échanges entre TWiki et nos clients, et une phase d’implémentations qui seront détaillées dans la partie « organisation structurelle ».Ces analyses interviendront donc en début de projet et feront l’objet de diagrammes de cas d’utilisations, de classes et de séquences UML*. Les diagrammes de classes nous permettront de spécifier les objets qui vont être échangés, les diagrammes de séquence et cas d’utilisations, les services à fournir depuis TWiki. Ceci définira en quelque sorte un contrat entre clients et serveur, les uns s’engageant à développer leur application sur ce modèle, l’autre à fournir ce qui est spécifié. Une fois ceci effectué, les tâches seront divisées.L’équipe service aura pour tache initiale d’écrire une description WSDL*, qui est la spécification du service Web en XML. L’intérêt de l’écrire si tôt est que les clients pourront l’intégrer dans leur IDE* dès le départ et travailler avec une image du service en local même si l’implémentation côté serveur n’est pas faite (ou que très peu). Aucun « branchement » clients/service ne devra être fait à la fin, tout sera fait dès le départ.

4

Organisation structurelle

Présentation

EditeurWYSIWYGL’objectif est de réaliser un éditeur WYSIWYG standalone* en Java pour répondre au problème de l’édition de page en syntaxe TWiki. Concernant l’intégration de l’outil à l’environnement final de l’utilisateur, il sera possible de créer des pages à partir de rien mais le réel objectif consistera à permettre l’édition d’une page « au vol » lors de sa consultation par un navigateur. Cela sera rendu possible par l’utilisation de la technologie Java Web Start*.La particularité du projet est qu’il s’agit d’une application indépendante du navigateur, contrairement à l’approche déjà explorée notamment par les étudiants de MIAGE mais également par des membres de la communauté TWiki. Cela pose immédiatement le problème de la communication avec le serveur pour récupérer le contenu d’une page à éditer et pour y mettre à jour une page. La solution passe par le développement d’un service Web qui permettra la communication entre les clients et le serveur.

Outil de refactoringLa plupart des environnements de programmation professionnels, tels que JBuilder, Eclipse ou Dreamweaver, possèdent un gestionnaire de ficher qui permet de gérer un projet. En effet, lorsqu’un ficher est créé, renommé, déplacé ou supprimé, la modification est prise en compte dans toute l’arborescence du projet : c’est ce qu’on appelle le « refactoring ».Dans TWiki, un outil de refactoring primaire existe. Lorsqu’on renomme ou déplace une page, les modifications appropriées sont effectuées dans les autres pages concernées. Néanmoins, dans le cas du déplacement de fichiers par exemple, l’administrateur ne peut déplacer qu’un fichier à la fois et doit fixer manuellement la destination. On s’aperçoit aisément qu’il est fastidieux pour l’administrateur de déplacer un groupe de fichier important.

Notre outils de refactoring doit donc permettre, de façon simple et intuitive, d’effectuer des opérations élémentaires sur l’arborescence des fichiers de TWiki. L’utilisateur cliquera sur un lien, dans son navigateur, qui lancera l’application grâce à la technologie « Java Web Start ».L’application affichera deux arbres du type « explorateur de fichier ». Le premier représentera l’arborescence initiale et le second, le résultat des modifications apportées à l’arborescence initiale. Il suffira à l’utilisateur de sélectionner un fichier ou un groupe de fichiers dans le premier arbre, de choisir une destination dans le second et de cliquer sur un bouton, pour déplacer les fichiers choisis.

Service Web et implémentation côté serveur1 : Présentation d’un Web Service :

1.1 : Définition :

Un service Web est une technologie permettant à des applications de dialoguer à distance via Internet (par le protocole HTTP), et ceci indépendamment des plates-formes et des langages sur lesquelles elles reposent. Pour ce faire, les services Web s'appuient sur un ensemble de protocoles standardisant les modes d'invocation mutuels de composants applicatifs. On parle alors de WSDL, de message SOAP et d’annuaire UDDI :

5

La WSDL ou Web Service Description Language fournit un modèle et un format XML pour décrire les Web Services. Elle permet de décrire précisément les fonctionnalités offertes par le service, en nous indiquant, par exemple, comment et où les appeler.

SOAP ou Simple Object Acces Protocol permet de définir les messages que l’on va pouvoir envoyer et recevoir du Service Web. Cette spécification encapsule des messages XML. C’est pour cette raison que les applications peuvent être écrite dans des langages différents.

L’UDDI représente un annuaire électronique référençant les services Web. C’est par cet annuaire qu’on arrive connaître l’Id (ou adresse) des Services Web disponible qui va nous permettre de les appeler dans nos applications.

1.2 : Fonctionnement :

Maintenant que nous savons ce qu’est un service Web, nous allons voir comment cela fonctionne.

Un client recherche un service dans l’annuaire UDDI Il appelle le Service Web à partir de son application le serveur traite la demande et renvoie le résultat au client le client utilise le résultat

Le schéma ci-dessous illustre ce fonctionnement :

6

2 : Rôle du Service Web dans notre application :

2.1 : Intérêt d’un Service Web :

Si on reprend la vue de notre projet, on a d’un coté le serveur TWiki, et de l’autre des applications clientes, lancé sur les machines clientes. Il faut donc trouver un moyen de les faire communiquer entre elles. C’est précisément là qu’interviennent les Services Web.

2.2 : Les acteurs du Service Web :

On se référençant au schéma ci-dessus, on va donc avoir TWiki jouant le rôle du Serveur, et les applications clientes, jouant le rôle … des clients. Comme cette application ne fonctionnera qu’en interne (au niveau des membres d’une entreprise par exemple), il n’y aura pas de référencement dans un annuaire UDDI. Les applications clientes connaîtront déjà les spécifications des messages SOAP et du contrat WSDL. Il s’en dégage un travail de collaboration entre l’équipe du Service Web et les équipes des applications clientes.

2.3 : Fonctionnement dans notre application :

Le fonctionnement est donc assez simple. Le client appelle des services comme si il appelait des méthodes sur un objet local. La différence est que le corps des méthodes n’est pas en local, mais sur le serveur.

2.4 : Conclusion 

On peut donc dire que le Service Web joue le rôle d’interface entre les applications clientes et le serveur TWiki.

Objectifs et priorités

Editeur WYSIWYGEn annexe A1 figure le découpage en lots du projet. Etant donné le degré de difficulté relatif à la réalisation d’un projet qui s’adresse à des non informaticiens, la priorité est d’atteindre le lot n° 3. L’intégration dans TWiki via Web Start s’impose également comme priorité car c’est cela qui fera de l’application une application utilisable.

Outil de refactoringL’objectif de notre outil est de fournir les opérations élémentaires suivantes :

Modification du nom d’un fichier Suppression d’un fichier ou d’un groupe de fichiers Déplacement d’un fichier ou d’un groupe de fichiers Ajout d’un lien de parenté entre deux topics Mise en évidence des liens morts (les pages qui ne sont pas référencées par d’autres

pages)

Cet objectif doit être atteint puisque la société ILOG désire l’utiliser à la suite de notre projet.

7

D’autres fonctionnalités peuvent être ajoutées en fonction de l’avancement du projet : Possibilité d’annuler des opérations avant des les appliquer Mise en évidence des cycles : la hiérarchie des fichiers est en réalité un graphe*. Nous

représentons en fait un arbre couvrant* de ce graphe. Il s’agit ici de faire apparaître les arêtes qui ont été enlevées.

Mise en évidence des derniers topics modifiés Mise en évidence des derniers topics visualisés

Il est possible qu’à la suite de notre projet, ILOG veuille ajouter d’autres fonctionnalités ou des fonctionnalités que nous n’aurons pas le temps de développer. Il faut donc que les sources de l’application soient bien documentées afin de permettre à un autre informaticien de poursuivre le sujet sans trop de difficultés.

Service Web et implémentation serveurComme on a vu précédemment, le développement entre les applications clientes et le Service Web se fera en parallèle. Pour assurer un aboutissement optimal, on doit étudier les étapes d’avancement du projet. Cette étude devra être faite dès le départ, avant tout codage.

1 : Objectifs premier

L’étape primordiale est de définir une description complète des services offerts par le Service Web, ainsi que les différentes structures qui vont permettre à nos applications de communiquer. Il s’agit clairement ici, de se mettre d’accord sur la WSDL. Une fois cette étape terminée, les équipes de développements peuvent se séparer pour commencer leur travail respectif.

2 : Priorités

Notre priorité est de fournir dans un délai le plus restreint possible une première version du Service Web, afin que les équipes de développements clientes puissent intégrer les appels aux services. Le délai de ce développement est déterminent dans l’avancement du projet, car c’est le service Web qui joue le rôle charnière de l’application. Sans cette partie le projet est inutilisable. Cette première version devra être livré dans un délai de 10 jours (cf. Planification)

Hypothèses et dépendances

Editeur WYSIWYGL’éditeur WYSIWYG sera développé grâce aux facilités offertes par l’API* Java concernant les traitements HTML*. L’idée est de réaliser un petit éditeur HTML en Swing* limité aux objectifs d’édition qui figure en annexe A1. On fait donc l’hypothèse que l’API Java est adaptée pour atteindre ce but.

Par ailleurs, pour lire et produire de la syntaxe TWiki, on utilisera le traducteur Twiki <-> HTML de Frédéric Luddeni (étudiant en MIAGE). Le bon fonctionnement de l’éditeur est dépendant de la fiabilité de ce traducteur.

8

Enfin, pour permettre à l’éditeur standalone de communiquer avec le serveur TWiki, le service Web développé dans le projet devra être fonctionnel.

Outil de refactoringLa communication avec le serveur TWiki se fait à travers le « Web Service ». Il faut donc que celui-ci soit opérationnel pour que l’application fonctionne convenablement. De plus, l’application s’appuie sur la technologie « Java Web Start », ce qui suppose qu’un version récente du JRE (Java Runtime Environment) de SUN (version 1.4 au moins), soit installé sur la machine cliente.

Service Web et implémentation côté serveurNous pouvons distinguer deux types d’hypothèses et de dépendances dans les services web :

Hypothèses et dépendances concernant la communicationo La boîte à outils que nous allons utiliser pour développer notre service web

nous permettra de respecter notre description WSDL.o Perl et Java sont inters opérables via service web.

Hypothèses et dépendances concernant l’intégration avec TWikio Dépendance vis-à-vis des fonctionnalités de TWiki que nous allons devoir

utiliser, afin d’y intégrer le service.

Limites et Interfaces

Editeur WYSIWYGConformément aux attentes de ILOG, le champ d’action de l’éditeur sera volontairement limité. En effet, il n’est pas souhaitable de laisser trop de libertés aux utilisateurs concernant la mise en forme de leur production. Lorsqu’on écrit sur TWiki, l’accent doit être mis sur la structure et la sémantique des documents.

L’éditeur devra intégrer le traducteur déjà mentionné, l’interfaçage entre les deux sera un enjeu.

Il est en est de même avec le service Web développé au sein du projet.

Outil de refactoringToutes les fonctionnalités de l’application ne pourront pas être développées en raison des contraintes de temps. La mise en évidence de certaines caractéristiques des topics comme la taille ou la date de création, par exemple, ou d’autre fonctionnalité ne seront pas abordées.

Service Web et implémentation côté serveurLe fait que notre projet se greffe sur une application existante implique certaines limites de développement.

9

1 : Gestion des annulations

Lorsqu’un utilisateur décide d’annuler une modification (au niveau refactoring voire peut être WYSIWYG), ce sont aux applications clientes de les gérer. Une fois une opération du service invoquée, aucune annulation n’est gérée.

2 : Limitations des tests

Le Service Web sera développé en Perl pour une meilleure intégration avec le serveur (ce dernier étant développé dans ce langage). Les applications clientes seront développées en Java. On effectuera tous les tests nécessaires au bon déroulement de la communication entre ces deux langages, mais on n’effectuera aucun test pour s’assurer de l’interopérabilité de notre programme avec d’autres plateformes. (Même si théoriquement, il ne doit pas y en avoir : principe des Services Web). Cela est en partie du au manque de temps dont on dispose.

3 : Notion de sécurité

3.1 SSL

3.1.1 : Description

Le Service Web utilisant le protocole HTTP, nous avons étudié le protocole SSL afin de sécuriser les envois de messages. Ce protocole, très utilisé au niveau des transactions boursières est basé sur le principe d’encryptage des données : SSL crypte un message envoyé par le client puis le transmet au serveur. Lorsque le serveur reçoit le message, SSL le décrypte et vérifie qu'il provient de l'expéditeur correct. L’inconvénient majeur de SSL est qu’il est assez gourmand au niveau bande passante.

3.1.2 : Limite au Projet

La sécurisation d’un Web Service ne se contente pas d’implémenter un protocole, il y a des tas de configurations à effectuer, et rien ne garantit la robustesse de cette sécurité. En d’autre terme, d’implémenter nous même la sécurité du Service Web représenterait un trou de sécurité pour l’entreprise, ce qui n’est pas permis.De plus notre projet est soutenu par la société ILOG possédant leur propre système de sécurité, notamment un réseau VPN.

3.2 VPN

Un réseau privé virtuel (VPN) est une extension d'un réseau privé qui assure des connexions sur des réseaux partagés ou publics comme Internet. Via un VPN, on peut envoyer des données d'un ordinateur à un autre sur une connexion sécurisée. Semblable par bien des côtés au protocole SSL, le VPN est une connexion point-à-point à long terme.

Les interfaces les plus importantes avec lesquelles nous allons interagir sont celles de TWiki. Il y a trois fonctionnalités majeures qui y sont déjà implémentées :

Gestion des autorisations d’accès via Apache*

10

Des droits d’accès peuvent être requis pour éditer ou visualiser certaines pages. Dans un premier temps, notre service ne les gèrera pas afin de se concentrer sur l’essentiel. Ensuite, nous devrons réutiliser ce qui est déjà implémenté dans TWiki (et qui utilise le système d’Apache) afin de les gérer.

Gestion de la concurrence à l’échelle des pages

Si plusieurs utilisateurs veulent éditer une page en même temps, il est nécessaire de gérer la concurrence. TWiki dispose d’un système de verrou à l’échelle d’une page. Dès qu’un verrou est déposé sur un topic, un autre utilisateur ne peut pas l’éditer (excepté après un certain délai « timeout »). L’objectif sera que l’édition WYSWIG comme certaines opérations de refactoring utilisent ce même verrou, pour que le service soit parfaitement intégré au système TWiki.

Gestion des commit (attachements, pages) via RCS*

Uploader* un attachement comme modifier ou créer une page implique un empilement de la nouvelle version sur la précédente, afin notamment de visualiser les différences et de pouvoir revenir en arrière. TWiki gère cela via RCS. Pour être intégré, notre service devra lui aussi l’utiliser.

Contraintes non fonctionnelles

Service Web et implémentation côté serveurLa contrainte non fonctionnelle majeure est sans conteste la concurrence. Si plusieurs personnes veulent administrer un TWiki en parallèle ou en éditer des mêmes pages, notre service devra gérer cela. On peut distinguer deux types de concurrence :

Concurrence à l’échelle des pages

La granularité de la concurrence se limite à une page donc on peut réutiliser le mécanisme de verrous de TWiki. C’est ce qui devra être géré pour l’édition WYSIWYG et (peut-être) pour certaines opérations d’administration.

Concurrence pour refactoring

Le verrou peut être appliqué au refactoring. Par exemple, si on veut déplacer un sous arbre de topics dans un autre topic, on met d’un côté des verrous sur chaque élément de l’arbre, et de l’autre on regarde si il y en a un qui a été déposé sur la destination. Mais une contrainte réside encore :Nous travaillons en mode déconnecté (contrairement à l’édition WYSIWIG), toutes les opérations sont faites en local avant de mettre à jour TWiki. Si par exemple, deux utilisateurs travaillent en parallèle en faisant des manipulations sur des morceaux de l’arborescence qui sont liés, l’un va faire un « commit* » de son travail avant l’autre et tout se passera bien. L’autre utilisateur va vouloir faire de même, et ses modifications seront incompatibles avec le nouvel état actuel de l’arbre. Nous avons envisagé deux manières d’aborder ce problème :

Verrou préventif Validation intelligente

11

Dans un premier temps, nous allons développer un verrou préventif spécifique au refactoring, recouvrant toute l’arborescence. Pour verrouiller, le client devra indiquer qu’il s’apprête à administrer. Une fois terminé, il déverrouillera ou un timeout (en cas de plantage par exemple) le fera à sa place.La validation intelligente sera envisagée plus tardivement, si les résultats sont satisfaisants et s’il nous reste du temps. Tout serait fait de manière transparente, excepté en cas de conflit ou on demanderait explicitement à l’utilisateur de régler le problème (à la manière de CVS).

Risques

Editeur WYSIWYG

Problèmes de développement liés à l’API Java concernant HTMLo Réaction possible : Réutiliser un éditeur existant

Difficulté de mise en œuvre de Java Web Starto Réaction possible : Demander de l’aide, se focaliser sur la partie édition

Retard de la part de l’équipe qui réalise le service Web pour la communication avec le serveur

o Réaction possible : Se focaliser sur la partie édition

Outil de refactoringLe risque principal de cette partie est le non respect des délais. En effet, ILOG veut qu’une application utilisable lui soit fournie. Deux raisons peuvent ralentir le déroulement de l’application :

L’état d’avancement du « Web Service » sur lequel se base l’application Les difficultés d’apprentissage et de maîtrise de la technologie « Java Web Start »

Service Web et implémentation côté serveurEvaluation des risques et présentation de solutions :

Légende :

5 - Interopérabilité entre Java et Perl* :Risque très important. La cause possible est de laisser la boîte à outils générer elle-même la description WSDL depuis l’implémentation. Qui plus est, celle que nous allons utiliser a quelques problèmes avec WSDL.

Faire nous-mêmes les schémas XML et description WSDL. Basculer dans une autre implémentation (dans le pire des cas).

5 - Difficultés au niveau de l’intégration du service dans TWiki. Demander de l’aide chez ILOG où ils ont bien connaissance du domaine. Demander de l’aide à la communauté TWiki.

12

4 - Problème de communication SOAP*/XMLRetourner des données conformes à la description du service n’est pas forcément trivial et peut nécessiter du temps (surtout dans le cas de données complexes). Perl est un langage atypé, peut être cela implique-t-il quelques difficultés supplémentaires.

Se réserver suffisamment de temps pour debugger les échanges.

4 - Retour tardif sur l’analyse/conceptionDurant la phase d’implémentation, il se peut que certains points aient été omis concernant l’analyse et la spécification des méthodes et données.

Mettre à jour la description WSDL et répercuter les changements sur nos implémentations (plus ou moins délicat suivant les modifications).

2 - Entente entre les deux membres de l’équipe serviceCes deux personnes ont des caractères très différents et sont souvent en conflit. L’expérience des projets passés a montré que cela s’était toujours bien passé, mais cela implique des difficultés.

Planning élaboré en conséquence.

Moyens de contrôle

CommunicationLe fait que notre projet repose sur des phases de développement parallèle, et que nous ne travaillons pas dans les mêmes locaux, nous allons devoir utiliser différents moyens de communications.

1 : Entre les différentes équipes de développements

L’un des outils que nous utiliserons pour communiquer est MSN Messenger. Ce logiciel nous permet de faire des conférences vocales, écrites ou visuelles en utilisant uniquement la connexion Internet (aucun coût supplémentaire). Nous pouvons également nous transmettre nos documents. Ces derniers seront publiés au fur et à mesure sur la page twiki de notre étude.De plus, nous organiserons des réunions hebdomadaires afin de nous tenir à jour des avancements de notre développement. Au niveau de l’application, les sources seront placées sur un Serveur CVS facilitant la mise à jour et l’évolution du produit au niveau développement. (cf. Gestion de Versions).

2 : Entre les encadrantes et les développeurs

Suite aux réunions hebdomadaires, nous écrirons un rapport reprenant l’évolution du développement effectué. Ce rapport sera publié sur TWiki de notre étude mais sera également envoyé à nos encadrants respectifs pour qu’ils soient au courant de notre évolution ainsi que de la tournure de notre projet. Si cela ne leurs convient pas, on prendra alors rendez vous, et on discutera des différentes solutions possibles. De plus, l’équipe de développement sera à la disposition de leur encadreurs si ils désirent une présentation de l’évolution du projet (dans ce cas, il serait préférable de les prévenir dans un délai suffisant).

13

3 : Suivi du projet par le jury

Le jury pourra également suivre l’évolution de notre projet à travers le suivi personnalisé sur la page TWiki qui nous est consacrée. De plus, il sera libre de renter en contact avec nous ou nos encadreurs. Tous les moyens pour communiquer avec nous, sont décrits sur la page.

4 : Intérêt

Même si l’organisation et la traçabilité de notre développement nous prend du temps, cela nous permet de savoir en grande partie ce que font les différentes équipes. De plus, cela permet de voir les éventuels conflits de compatibilité entre les différentes applications.

Gestion de versionsNotre projet implique donc un travail collaboratif. Pour faciliter les multiples intégrations, empaquetages de codes, nous allons utiliser un serveur CVS (berliOS, lien sur TWiki).Cela nous permettra en plus d’avoir les différentes versions de notre projet en fonction de l’avancement de ce dernier.

Tests

1 : Au niveau de la robustesse du logiciel

La première chose est de vérifier le bon déroulement du programme en testant tous les scénarios possibles afin de détecter si une séquence d’actions n’engendre pas de conflits.

La deuxième approche repose sur la robustesse du programme. En effet, il faut vérifier que si des données non valides sont émises depuis le client, ceci n’engendre pas d’erreur au niveau serveur (donc filtrage) mais aussi que l’utilisateur ne soit pas bloqué par la suite.

Enfin, la dernière approche réside dans le déploiement de l’application. Il aurait été intéressant de tester et analyser son comportement sur différentes machines. Java nous garantit peu de risques côté client. Il est peu probable qu’on n’aie le temps de faire des tests côté serveur.

2 : Au niveau accessibilité

En effet, l’outil TWiki pourra être utilisé par des non informaticiens qui ne seront pas forcement à l’aise avec cet outil. Pour ces raisons, le déroulement de l’application doit être le plus intuitif possible. Pour ce faire, nous devrons effectuer des tests, avec tout type de personnes.

Lors de ce test, ils seraient intéressant d’être présent afin d’analyser le comportement des gens face aux événements engendrés par le programme. On pour ainsi adapter en fonction des différents utilisateurs.

En annexe A2 vous trouverez un fichier de test écrit en syntaxe Twiki qui pourra servir à tester l’éditeur WYSIWYG.

14

Techniques utiliséesChoix techniques

Editeur WYSIWYGNotre projet a dans un premier temps consisté à développer uniquement un éditeur WYSIWYG pour TWiki (avec d’avantage de contraintes que maintenant). Beaucoup de nos analyses se sont focalisées sur les technologies utilisables pour faire cet éditeur. Avant la réorientation du projet qui a amené à faire un projet tel qu’on vous le présente maintenant, nous envisagions deux technologies :

- Java- XUL + Mozilla Composer

XUL est une technologie assez récente basée sur XML, et Mozilla Composer est un composant - éditeur WYSIWYG déjà existant. Après la réorientation qui a eu lieu sur notre projet, cette piste a été écartée (difficultés et risques). En annexe A3, figurent deux rapports sur l’élaboration d’un WYSIWYG basé sur XUL et l’éditeur de Mozilla (écrits courant Mars 2004, l’un sur un éditeur dans une page Web, l’autre standalone).

Voici les choix que nous avons effectués dans le cadre du projet actuel, et qui découlent en partie des analyses faites auparavant :

Langage Java pour l’écriture de l’éditeur API Swing pour l’écriture de l’interface utilisateur Technologie Java Web Start pour le lancement dynamique et l’installation de

l’application Langage HTML comme langage de traitement intermédiaire Traducteur de F. Luddeni écrit en Java et utilisant les expressions régulières Invocation de service Web pour les communications client-serveur

Outil de refactoringNous utiliserons le langage Java pour développer l’outil de refactoring puisqu’il nous permet d’utiliser la technologie Java Web Start et parce qu’il est indépendant du système d’exploitation utilisé par l’utilisateur.

Au niveau de l’implémentation, il n’est pas possible de charger la totalité de la hiérarchie des fichiers dans l’application. En effet, ILOG possède plusieurs milliers de topics au sein de son intranet. Tout charger prendrait beaucoup trop de temps. Nous chargerons donc la hiérarchie au fur et à mesure que l’utilisateur progressera dans l’arborescence.

15

Service WebEn ce qui concerne le développement des fonctionnalités du service, nous allons utiliser le langage Perl. La raison principale de notre choix est d’être homogène avec notre environnement (TWiki est implémenté dans ce langage) et de pouvoir accéder à ses ressources de manière la plus aisée possible. L’interfaçage avec l’existant en sera simplifié.Côté communication, nous avons le choix entre XML-RPC sans SOAP* et avec SOAP. Ce dernier faisant l’objet de recommandations de la part du W3C*, étant de plus en plus populaire, et faisant l’objet de beaucoup d’attentions et de suivi, c’est cette solution que nous préférons. Le protocole de transport choisi est HTTP*, car c’est lui qui constitue un des atouts des services web. En outre, il permet de passer au travers des firewalls*.

En ce qui concerne la boîte à outils pour faire du service web coté serveur, nous avons le choix entre SOAP et SOAP:Lite. Le premier a pour défauts d’être légèrement plus complexe que SOAP:Lite et d’être moins régulièrement mis à jour. Nous allons donc utiliser SOAP:Lite.Un autre élément que l’on peut envisager ultérieurement dans le projet est d’utiliser mod_perl pour Apache. SOAP:Lite nous permet de séparer répartiteur de requêtes et implémentations du service vers lesquels les rediriger :

Par défaut, le répartiteur fait l’objet d’un script CGI*, mais il est possible avec mod_perl d’en faire un daemon*. Le but étant d’accélérer le traitement des requêtes.Côté client, il est possible que nous utilisions Apache SOAP pour invoquer le service en Java. Nous verrons ce que nous proposent nos IDEs pour invoquer le service.

Logiciels de développement

Pour le développement de notre projet nous utiliserons les logiciels suivants : JBuilderX enterprise pour les applications standalone DzPerl Editor pour les fonctionnalités du service web XMLSpy pour debugger tout ce qui concerne le XML

Nous n’utiliserons pas de logiciels pour la partie UML puisqu’elle n’est pas destinée à être publiée.

16

Documentation

Nous fournirons une documentation détaillée de chaque application standalone pour les utilisateurs. Notre projet étant amené à être publié au sein de la communauté TWiki, différents informaticiens se plongerons sans doute dans nos sources pour apporter des modifications. Nous devons donc fournir des sources claires et bien documentées pour les développeurs futurs.

17

Planification(s)

18

Glossaire

Apache  :Apache est à la fois un projet et un logiciel. Le logiciel est le serveur Web le plus populaire dans le monde. Le projet Apache est piloté par un petit groupe de volontaires dispersé à travers le monde : l'Apache Group. Ses membres utilisent Internet pour communiquer, prévoir et développer le logiciel ainsi que sa documentation.

API « Application and Programming Interface » :Ensemble de bibliothèques permettant une programmation plus aisée car les fonctions deviennent indépendantes du matériel.

Arbre couvrant  :L’arbre couvrant d’un graphe est un arbre qui permet d’accéder à tous les sommets du graphe à partir de sont sommet

CGI  (script CGI) « Common Gateway Interface » :Petit programme informatique, écrit en langage de script, qui permet de réaliser des pages dynamiques, d'interagir avec le serveur Web et de gérer notamment les données issues des formulaires que l'internaute envoie à partir d'une page Web.

CVS  « Concurrent Versions System » :CVS est un outil de gestion de sources. Tout projet qui manipule des fichiers texte, que ce soit la gestion d'un serveur Web, l'écriture d'un livre ou bien la réalisation d'un programme peut profiter de CVS. CVS garde trace automatiquement des différentes versions d'un même fichier et permet de récupérer les vieilles versions.

Daemon  :Vocabulaire Unix. Programme réalisant des tâches de fond du système.

Firewall  :Dispositif informatique qui permet le passage sélectif des flux d'information entre un réseau interne et un réseau public, ainsi que la neutralisation des tentatives de pénétration en provenance du réseau public.

Graphe  :Un graphe est un ensemble d’éléments pouvant être reliés entre eux par des arêtes. Les éléments sont, dans notre cas, les topics et les arêtes sont les liens de parenté qu’il existe entre eux.

HTML « HyperText Mark-up Language »Langage de description des pages Web dérivé du SGML. Il est composé d'une suite de signe ASCII, dans laquelle sont inclues les commandes spéciales concernant le formatage des pages, la police de caractères et les multimédia.

HTTP  « HyperText Transfert Protocol » :Protocole régissant les communications entre les serveurs du Web. Sa fonction première est d'établir la connexion avec un serveur, qui contient la page que l'on veut voir afficher, et de rapatrier cette page sur le poste de l'internaute.

19

IDE « Integrated Development Environment » :Environnement de développement intégré.

Java Web Start :Nouvelle technologie de déploiement pour les applications fondées sur la technologie Java. Il agit comme un lien entre l'ordinateur et Internet permettant a l'utilisateur de lancer et de gérer des applications a partir du Web. Avec Java Web Start, il est possible d'activer des applications d'un simple clic de la souris. En outre, le logiciel charge toujours les versions les plus récentes et permet ainsi d'éviter les procédures complexes d'installation ou de mise a niveau.

Perl  « Practical Extraction Report Language » :Langage de programmation qui combine la syntaxe de plusieurs utilitaires et systèmes Unix.

RCS « Revision Control System » :Système de contrôle des différentes versions d'un projet. A la base de CVS.

Service Web  :Technologie intervenant dans le domaine des applications réparties. Son but est de proposer des mécanismes afin de faire communiquer des applications hétérogènes (comme CORBA). La clef de son succès : reposer sur XML.

SOAP « Simple Object Access Protocol »Protocole standard destiné aux services web. Lancé par IBM et Microsoft, il permet d'utiliser des applications invoquées à distance par Internet.

Standalone Une application est dite standalone si elle est autonome dans le contexte considéré. Dans notre cas, il s’agit de l’autonomie vis à vis du navigateur web.

Swing Classes faisant partie des JFC et proposant des composants graphiques élaborés entièrement dessinés par Java, ce qui permet d'obtenir une interface graphique dont l'apparence n'est pas liée au système d'exploitation sur laquelle elle tourne.

UML « Unified Modeling Language »L'UML est le concept de modélisation objet. Son développement a débuté en 1994 et il a été normalisé par l'OMG début 1997. Grady Booch et Jim Rumbaugh ont décidé de travailler ensemble pour réaliser une unification des anciennes méthodes à objet. La méthode UML est très intuitive, plus simple et plus cohérente que les autres méthodes. Elle simplifie le processus complexe de conception d'un système informatique en définissant 9 points de vue (ou diagrammes) de modélisation.

TWiki  :Il s’agit d’une implémentation en langage Perl du concept de Wiki (voir Wiki dans le glossaire).

20

Uploader  :Envoi d’informations du client vers le serveur (flux montant).

XML-RPC « Remote Procedure Call sur XML » :L’ancêtre du service web tel qu’on le connaît aujourd’hui, mais toujours d’actualité. Il s’agit d’une alternative si on ne veut pas utiliser SOAP.

W3C “World Wide Web Consortium”Fondé en 1994 par Tim Berners-Lee. Son principal objectif est la mise au point de normes et de protocoles ouverts et libres, dans un souci d'interopérabilité maximale : RDF, XML, CSS. Il est géré conjointement par le MIT aux Etats-Unis, l'INRIA en France et l'université Keio au Japon

Wiki  :Un Wiki est un site web dynamique dont tout visiteur peut modifier les pages à volonté. Il permet donc de communiquer ses idées rapidement.

Il s'agit d'un concept assez récent, bien que la technologie nécessaire existe depuis plusieurs années. Le nom Wiki provient d'un adjectif hawaïen wikiwiki, qui signifie rapide. C'est une forme à redoublement de l'adjectif wiki. Ward Cunningham, le créateur du système Wiki, a choisi ce terme pour désigner le premier site utilisant ce principe, le WikiWikiWeb.

Le principe est simple : il s'agit d'un modèle coopératif de rédaction de documents. Concrètement, n'importe quel visiteur a la possibilité de modifier la page qu'il est en train de lire. Les modifications sont ensuite enregistrées et toutes les versions historiques restent accessibles (comme dans un logiciel de gestion de versions). Ainsi, un premier auteur rédige un article, un second le complète puis un visiteur en corrige d'éventuelles erreurs qu'il aura remarquées en navigant sur le site.

WSDL « Web Service Description Language » :Dialecte XML dédié à la description de tous les éléments nécessaires pour interagir avec un service web. Soutenu principalement par Ariba, IBM et Microsoft.

WYSIWYG « What You See Is What You Get » :Traduit en français par « ce que vous voyez à l'écran est ce que vous obtiendrez à l'impression » ou encore « tel écran-tel écrit ». Principe de fonctionnement de la plupart (actuellement) des logiciels de traitement de texte et de PAO à destination du grand public, dans lequel les affichages à l'écran sont aussi proches que possible de ce qui va être finalement imprimé.

21

Annexes

Annexe A1 : Description des lots concernant l’éditeur WYSIWYG

Lot n° 1 : Réalisation de l’interface graphique conformément à sa définition sur papier et écriture du traducteur à partir de code libre existant (traducteur de F. Luddeni, étudiant en Miage et d’autres ressources provenant de www.twiki.org)

Lot n° 2 : Mise en place des traitements concernant le formatage de texte (cf. tableau ci-dessous)

Lot n° 3 : Mise en place des traitements concernant les tableaux et les listes à puces imbriquées (cd tableau ci-dessous)

Lot n° 4 : Intégration du traitement des variables (des prérequis de la part de l’équipe WebService sont nécessaires), intégration de traitements supplémentaires(cf. tableau)

Lot n° 5 : Intégration et finalisation de l’ensemble du projet

Elément de syntaxe Traitement(s) souhaité(s) * Lot n°Paragraphes 2Titres et sous-titres : 6 niveaux Affichage standard dans la page ainsi que dans

une fenêtre de navigation (dénommée « fenêtre plan »)

2

Déplacement d’une section dans la fenêtre plan du document

4

Texte italique 2Texte gras 2Texte gras et italique 2Police à chasse fixe 2Police à chasse fixe en gras 2Mode programmation (Verbatim mode) permet d’écrire plusieurs lignes en police à chasse fixe

On pourra passer dans ce mode a tout moment pour faciliter la saisie de programmes

3

Ligne de séparation horizontale

2

Liste à puce 2Liste à puce imbriquée 3Liste ordonnée 2Liste de définition 4Tableau Création à partir de la taille fournie par

l’utilisateur3

Ajout d’une ligne sous le curseur 3

22

Ajout d’une colonne entre 2 colonnes sélectionnées

3

Fusion de la ligne sélectionnée et de la ligne sous-jacente

3

Fusion de la colonne sélectionnée et de la colonne sous-jacente

3

Lien interne par WikiWord Ouverture de la page en mode édition par clic 4Lien interne forcé Ouverture de la page en mode édition par clic 4Lien externe Ouverture de la page dans un navigateur 4Ancre Affichage dans la fenêtre plan 2Lien vers une ancre Accès à la ligne de l’ancre pointée 2Prévention locale de transformation de texte en lien

2

Prévention de transformation de texte en lien sur plusieurs lignes

2

Lien « mailto : » (référence à une adresse mail)

4

Smileys, représente des visages exprimant des émotions (plugin pré-installé sur twiki)

4

* Le comportement général attendu est proche du comportement usuel wysiwyg tel qu’on le trouve dans Microsoft Word, AbiWord ou OpenOffice. Quand la case est vide, cela sous entend qu’on s’inspirera des logiciels cités.

Variables Twiki

En syntaxe Twiki, ce sont des mots entourés de %. Exemple : %UNEVARIABLE%.Elles sont transformées en leur contenu qui dépend du contexte lors de l’affichage.

Variable Traitement(s) souhaité(s) N° de lot%TOC% représente la table des matières du topic

Insertion possible dans le texte

4

%WEB% représente le web courant

Insertion possible dans le texte

4

%TOPIC% représente le topic courant

Insertion possible dans le texte

4

%ATTACHURL fait référence aux pièces jointes du topic

On pourra insérer des éléments attachés via l’interface

4

%INCLUDE% permet d’insérer le contenu d’un topic

On pourra insérer le contenu d’un topic via l’interface

4

23

Annexe A2 : Fichier de test (en syntaxe TWiki) pour l'éditeur WYSIWYG

Ceci est la page de test---+ Gros TitreDu contenu.

---++ Assez gros titre*Du contenu gras*

---+++ Petit titre_Du contenu italique_

---++++ Plus petit titre__Du contenu gras et italique__

---+++++ Très petit titre=Du contenu en chasse fixe=

---++++++ Titre minuscule==Du contenu gras et en chasse fixe==

<verbatim>public static void main(String[] args){

int i = 0;System.out.println(i);

}</verbatim>

Un ligne de séparation---

* Liste à puce * Sur un niveau * et sur deux niveaux * et encore * et sur trois niveaux * et à nouveau

Liste ordonnée : 1 Le premier 1 Le deuxième 1 Le troisième

Liste de définitions $ Twiki: Du web collaboratif $ Wysiwyg: what you see is what you get

Un tableau compliqué| *L* | *C* | *R* |

24

| A2 | 2 | 2 || A3 | 3 | 3 || multi span |||| A4-6 | four | four ||^| five | five ||^| six | six |

UnWikiWord[[un wiki word forcé]]

Un lien externe[[htt://gnu.org][GNU]]

Une ancre

#UneAncre

Un lien vers l'ancre

[[#UneAncre][Go]]

Ceci n'est pas un lien : !UnWikiWord

[[mailto:bill@mail.com envoi un mail]]

La table des matières%TOC%

Vous êtes ici : %WEB% %TOPIC%

%ATTACHURL%/image.jpg

:-):)8-):cool::-I:(:o:D:-D;);-):devil:>;-):devilish:

25

Annexe A3 : Analyses XUL

Rapport étude Composer et XUL dans page Web (03/2004)

XUL XUL est un langage de construction d'interfaces graphiques basé sur XML dans le cadre du projet Mozilla. Ce dernier repose intégralement là-dessus, ainsi que ses applications tierces comme Messenger ou Composer. Cette technologie permet de faire :

Construction d'applications (avec barres d'outils, menus etc.) dans des pages Web aisément.

Modularité possible grâce aux séparations interface graphique/commandes/actions JavaScript/langues/skins etc. Le découpage est simple.

Gestion de packages Facilité d'intégration de Mozilla Composer.

Internet Explorer ne supporte pas en natif cette technologie, mais via un ActiveX Mozilla (XUL n'est pas une recommandation W3C). Intégrer cet ActiveX dans une page HTML à l'intention d'IE signifie placer un container qui utilisera le moteur Gecko de Mozilla pour rendre son contenu XUL. Aucun problème n'a été signalé concernant le rendu d'interface graphique (avec skin classique). Ce qui n'est pas le cas du JavaScript qu'il y a derrière ... (cf. section suivante)

Mozilla Composer Composer est un composant XPCOM (modèle de composant made in Mozilla) développé en C++. Il se présente sous la forme d'une dll sous Windows et d'un .so sous Linux/Unix et MacOS. Le développeur principal de Composer en a aussi fait une version standalone, reprise sous le nom Nvu. Ce composant exporte ses interfaces via IDL (Corba) pour qu'il puisse être accessible via JavaScript. L'intégrer en XUL consiste à faire appel à une balise et construire l'interface graphique autour. Il est possible de réutiliser celle de l'éditeur en faisant appel à certains fichiers XUL (et .js pour les fonctionnalités). Il suffit de donner un certain nom aux éléments graphiques pour que le lien soit automatiquement fait. Exemple :

editorOverlay.xul de l'éditeur : <toolbarbutton id="boldButton" type="checkbox" autoCheck="false" observes="cmd_bold" tooltiptext="&boldToolbarCmd.tooltip;"> <observes element="cmd_bold" type="checkbox" attribute="state" onbroadcast="onButtonUpdate(this.parentNode, 'cmd_bold')"/></toolbarbutton>mon_editeur.xul : <toolbarbutton id="boldButton"/>

Depuis editorOverlay.xul, on récupère le motif, le type, l'info bulle, la commande qui lui est liée etc.

26

Il peut être appelé depuis Mozilla dans une page XUL : chrome://editor/content. Avec la version 1.0.2 il marche, avec la 1.6 il effectue un chargement perpétuel (il n'est pas destiné à être appelé de la sorte).

Créer de nouvelles fonctions pour l'éditeur est plus délicat, et nécessite de rentrer d'avantage dans son source afin de comprendre. Dès lors, on rencontre des difficultés :

Ce n'est pas qu'un petit éditeur. Ses interfaces changent au fil des versions (entre Mozilla 1.0.2 et 1.6 par exemple,

l'accès à l'objet central nsEditorShell a disparu) et les documentations ne sont pas tenues à jour (le site de Mozilla traite de la version +/-1.0.2 sans le mentionner) et XulPlanet doit traiter de la 1.6+.

Peu de documentation sur la programmation de cet éditeur. Le code JavaScript de l'éditeur est (très) mal géré par IE. Pas moyen de le faire

marcher tel quel sous l'ActiveX (1.0.2 ou 1.6).

Plusieurs possibilités :

Ne pas se baser sur le JavaScript de Mozilla et tout recréer autour du composant : difficile.

Ne pas gérer IE (!) En faire une version standalone (étendre) (Nvu)

Conclusion C'est encore trop tôt pour bâtir des applications Web sur ce modèle.

27

Rapport Nvu (03/2004)

Présentation Nvu est le fer de lance de l'édition WYSIWYG Html sous Lindows. Il s'agit d'une implémentation standalone du Composer de Mozilla (du moins en ce qui concerne l'utilisation), créée par son développeur principal. La différence entre les deux n'est pas flagrante, si ce n'est l'ajout d'une extension Site Manager qui permet de représenter sous forme arborescente le site Internet auquel on veut éditer une page. Au niveau code, à vue de nez, cela ressemble à la dernière implémentation de Composer (1.6), et les technos utilisées sont les mêmes : XUL + JavaScript + DTDs + RDFs ...

Environnement Le fait que Nvu se base sur les technologies mises en oeuvre dans Composer implique une dépendance vis à vis de Mozilla. C'est au niveau de la compilation que c'est le plus visible : en effet, faire une application standalone avec du XML et du JavaScript nécessite une sorte de container ou d'environnement d'exécution; cet environnement c'est Mozilla. Tout ça pour arriver au fait que pour compiler Nvu, il faut compiler Mozilla préalablement. La compilation a été réalisée sous Windows, comme indiquée sur le site de Mozilla, non sans difficultés. 1h de compilation, 180 Mo de fichiers sources, 1 go de fichiers objet : c'est la base d'un environnement pour travailler sur Nvu. Après, c'est relativement rapide de compiler Nvu seul. Par contre, impossible d'utiliser un IDE comme on le ferait en Java.

Programmation de Nvu Nvu est un éditeur déjà assez important, assez mal documenté concernant son mode de fonctionnement (cf. Composer sur le site de Mozilla). Il s'agirait d'un travail d'intégration, faisant principalement intervenir du XUL, du JavaScript et des DTDs.

Conclusion Beaucoup de risques dans cette direction. Passé la phase délicate de la préparation d'un environnement de développement, il est difficile d'appréhender la difficulté avec laquelle il sera possible d'intégrer de nouvelles fonctionnalités. Il faudrait pas mal de temps afin d'analyser l'éditeur dans sa globalité et de maîtriser correctement des technologies auxquelles nous ne sommes pas familiers. N'ayant que relativement peu de temps pour faire ce TER, il vaut mieux écarter cette piste.

28