Introduction

Tout d'abord, situons le contexte dans lequel ce développement technique a vu le jour. Les sites Web coopératifs qui ont été développés ou qui sont en cours de développement à l'ICA offrent aux utilisateurs une fonction de soumission de documents et d'URL. Dans le cas du projet Oxymoron ce sont, entre autres, des notes de lecture sous la forme de tableau MS-Word.

Ouvrons une parenthèse sur Oxymoron, projet développé en collaboration avec l'Université coopérative sans distance du Roannais, qui offre la possibilité à des adultes qui souhaitent valider leurs acquis ou/et développer leurs compétences, d'avoir accès au savoir sans distance. Oxymoron est un outil qui leur permet de mutualiser des fiches de lecture, créer un capital de connaissance et établir des relations entre personnes qui doivent produire des études et des recherches.

L'idée fondatrice est de constituer des ressources documentaires accessibles aisément et sans distance. L'outil se compose de quatre modules principaux:

• un annuaire des étudiants-chercheurs;
• un thesaurus de mots-clés;
• un ensemble de résumés, table des matières, notes de lecture, commentaires, et bibliographies;
• un outil d'annotations qui fera l'objet d'une communication à la conférence WebNet'98 à Orlando.
• Fermons la parenthèse.

Le coeur d'Oxymoron est constitué par un moteur de base de données relationnelle Informix (IUS) et ses extensions dans un environnement Unix. Nous avons alors rencontré le problème bien connu de récupérer des fichiers Word sur un serveur Web, que nous avons résolu par l'outil de conversion automatique en HTML décrit dans le paragraphe suivant. Deuxième problème rencontré: l'alimentation de la base à partir de données contenues au départ dans des tableaux Word. Dans les premières versions d'Oxymoron, nous
avions chosi l'approche standard qui consiste à offrir à l'utilisateur des TEXTAREA dans lesquels par copier/coller, il alimentait les différents champs de la base. Les premiers utilisateurs nous ont vite fait savoir qu'ils ne pouvaient pas continuer à travailler de cette manière vu la masse d'informations et le peu de temps qu'ils pouvaient y consacrer. Il nous fallait plus considérer la manière de travailler des utilisateurs. Nous devions simplifier au maximum et leur permettre un chargement automatique des différents champs déja présents dans un tableau Word, format imposé aux étudiants lors de la rédaction des fiches de lecture.

Exemple de note de lecture sur Le nouvel esprit scientifique, G. Bachelard

Le contenu des différentes cellules du tableau Word iront automatiquement alimenter les champs de la base de données grâce à la méthode décrite plus loin.

Conversion simple en HTML

Le problème du transfert des données du client vers le serveur est résolu par le type FILE de la marque INPUT. Le fichier Word est acheminé par le serveur HTTP vers le programme de traitement (CGI ou autre) défini par la valeur du paramètre ACTION de FORM. Dans notre cas le fichier est enregistré dans une base de données via des pages HTML comportant des extensions pour Informix. Le fichier doit être converti en format texte afin d'être accessible aux différents outils de recherche de la base.

Nous avons donc cherché une librairie de conversion. Une réponse à la question que nous avions posée dans les Newsgroups de Microsoft Office bien que ne donnant pas la bonne solution, nous a mis la puce à l'oreille. Pourquoi ne pas utiliser Microsoft Word lui même pour convertir ces documents en HTML. Pour cela, rien de plus simple, il vous faut une machine Windows (95, 98 ou NT) et Word. A l'aide de l'éditeur de Macro de Word (Visual Basic for Applications, VBA) il existe une méthode pour sauver un document en HTML. Il suffit d'appeler la méthode SaveAs de l'objet document avec le nom de fichier désiré et le numéro d'index du filtre de conversion à utiliser. Dans notre cas 14 pour le filtre HTML.

ActiveDocument.SaveAs FileName:=»doc3.html», FileFormat:=14

La preuve était donc faite que nous pouvions utiliser Word pour faire cette conversion. Mais c'est une chose d'écrire une macro Word et une autre d'offrir un service de conversion. Nous avons procédé de la manière suivante:

Un composant ActiveX, en Visual Basic, nommé Convert exporte une interface appelée WordConversions qui contient une méthode Doc2HTML. Cette méthode reçoit en paramètre un nom de fichier et crée un objet de type WordApplication, ouvre le fichier passé en paramètre et le sauve dans le format HTML en prenant soin de changer l'extension du fichier en .html. Le code est donné ci-après:

Public Function Doc2HTML(fileName As String) As String
     Dim wordAppObj As Word.Application
     Dim wordDocsObj As Word.Documents
     Dim wordDocObj As Word.Document


     Set wordAppObj = New Word.Application
     Set wordDocsObj = wordAppObj.Documents
     Set wordDocObj = wordDocsObj.Open(fileName)


     htmlFormatIndex = 14
     For Each fc In wordAppObj.FileConverters
          If fc.CanSave = True Then
               If fc.FormatName = «HTML Document» Then
                    htmlFormatIndex = fc.SaveFormat
               End If
          End If
     Next fc
    
     dotPos = InStr(fileName, «.»)


     newFileName = Mid(fileName, 1, dotPos) & «html»
     wordDocObj.SaveAs newFileName, htmlFormatIndex
     wordDocsObj.Close
     wordAppObj.Quit
     Set wordDocObj = Nothing
     Set wordDocsObj = Nothing
     Set wordAppObj = Nothing


     Doc2HTML = newFileName
End Function

Pour rendre ce composant ActiveX visible du monde Unix un fichier ASP reçoit un nom de fichier en paramètre (cette fois ci au format HTML), qui crée un objet de type Convert.WordConversions et invoque la méthode Doc2HTML. L'architecture globale est donnée dans la fig.1.

Fig. 1 - architecture globale

Voici le code ASP:

<%@ LANGUAGE=VBSCRIPT%>
<HTML>
<HEAD><TITLE>Doc to HTML Conversion</TITLE></HEAD>
<BODY>
<%
sourceFileName = Request.querystring 
(«txtSourceFileName»)
set convertor = Server.CreateObject
 («Convert.WordConversions»)
newFileName = convertor.Doc2HTML 
(sourceFileName)
Set convertor = Nothing
%>
Saved:<% = newFileName %> 
</BODY>
</HTML>

Voici une requête typique qui invoque ce fichier ASP:


http://....epfl.ch/doc2html.asp?txtSourceFileName=toto.doc

Restait à résoudre un dernier problème: le partage des ressources entre le monde UNIX et le monde Windows. Nous avons choisi la solution Samba qui nous permet de passer du monde des // à celui des \\.

Schéma de principe:

A travers un formulaire Web le fichier Word est chargé dans la base de données dans un élément de type blob (Binary Large Object) puis au moyen de la fonction lotofile on dépose le fichier dans un espace partagé avec Windows. Un script PERL fait appel au service ASP.

http://....epfl.ch/doc2html.asp?txtSourceFileName=\\doc\toto.doc

Le résultat de l'opération, un fichier toto.html est enregistré dans \\doc. Dernière étape, on charge ce fichier dans la base de données.

La séquence d'évènement complète est illustrée dans le diagramme de séquence de la figure 2.

Notez que cette solution ne fait aucune hypothèse sur l'équipement du côté de l'utilisateur. Un simple browser suffit étant donné que toute les conversions de formats se font sur les serveurs.

Fig. 2 - diagramme de séquence de la conversion HTML

Modification d'un document

Le document original est stocké dans la base. Si l'utilisateur veut le modifier le serveur lui renvoit donc le format WORD (avec le MIMETYPE msword). Ceci déclenche l'ouverture de Word si on travaille avec Netscape; avec IE, Word est intégré dans une frame du browser, ce comportement peut paraître élégant mais est troublant pour l'utilisateur qui ne sait plus à quelle application correspondent les menus, un clic dans une autre frame, et le Save As change de contexte.

Formats de documents supportés

Le fait d'avoir choisi d'utiliser MS-Word comme convertisseur de format semble nous condamner à ne supporter que le format MS-Word de Windows. En réalité nous pouvons convertir en HTML tout document que Word est capable d'ouvrir. La liste est assez longue. Mentionnons les formats suivants: Word Mac, RTF, Word Perfect etc. Nous avons testé notre application avec des documents Word Mac 5.1 et 98 chargés directement depuis le Mac et cela fonctionne à merveille.

En plus, s'il devient nécessaire de supporter d'autres formats, il suffit que les applications concernées proposent une interface ActiveX et la conversion en HTML pour que l'on puisse réaliser une conversion automatique.

Problèmes rencontrés

• Vous avez sans doute remarqué l'étrange paragraphe dans le code Doc2HTML qui est une boucle analysant les différents filtres de conversion. Sa raison d'être est que le numéro du format HTML pour le convertisseur selon la documentation Microsoft est toujours 14, contrairement à ce que nous avons expérimenté; bizarrement notre machine s'est mise un jour à sauver des fichiers au format Word 5.1 au lieu du HTML prévu. La boucle cherche le nom du convertisseur dont le nom est «HTML Document».
• Malgré le fait que nous fermons le document après son enregistrement et que nous quittons Word, le disque dur est encombré de fichiers temporaires. Pour l'instant, nous n'avons pas trouvé de solutions à ce problème.
• Si deux utilisateurs tentent de soumettre simultanément un fichier Word, l'un d'eux sera bloqué. C'est probablement dû au composant ActiveX qui ne supporte pas les accès concurrents. La solution est d'utiliser Microsoft Transaction Server.

Fig. 3 - diagramme de séquence de la conversion de tables

MS-Word comme interface de base de données

Insertion dans la base de données

La figure 4 montre la première interface utilisateur que nous avons imaginée pour Oxymoron. Une fiche contient 3champs décrits plus haut. Tout naturellement nous avons construit un formulaire HTML pour recevoir ces champs. Cette interface a beaucoup plu aux utilisateurs tant qu'ils ne devaient pas vraiment l'utiliser. Comme les données étaient déjà stockées dans des tableaux WORD, ils devaient donc faire de multiples opérations de copier/coller de Word dans les formulaires d'Oxymoron. Inutile de dire qu'ils n'aimaient pas du tout cette expérience. Il nous fallait automatiser le processus et établir une correspondance directe entre les cellules du tableau et les champs de la base de données.

Nous avons donc utilisé un mécanisme semblable à celui décrit plus haut pour la conversion HTML. Mais à présent nous construisons des requêtes HTTP qui transportent le contenu des cellules vers la base de données. Chaque requête correspond à une ligne du tableau et transporte donc les 3 champs de la ligne. C'est un nouveau fichier ASP (ConvertTable.asp) qui reçoit les requêtes de conversion en provenance du serveur Unix. Il utilise une méthode Table2Array que nous avons ajoutée à l'interface WordConversions du composant ActiveX déjà utilisé pour la conversion HTML. Table2Array extrait le texte de toutes les cellules du premier tableau qu'il trouve dans le fichier et les met dans une variable VisualBasic de type ARRAY de taille dynamique. Ensuite une requête HTTP est construite pour chaque ligne.

Fig. 4 - version 1 de la forme HTML

Fig. 5 - version 2 de la forme HTML

Voici un exemple de l'URL utilisé:

http://...www.epfl.ch:/web332webdriver? MIval=oxy_notelec2& MItab=v2_oxyapp&count= documentId&signature=login&type=documentType& item1= valueCell1&item2=valueCell2&item3= valueCell3"

La séquence d'évènement complète est illustrée dans le diagramme de séquence de la figure 3.

Modification d'un document

Ici, le document original est sauvé sur le serveur sous forme texte. Quand l'utilisateur veut modifier une note, le serveur lui renvoit le texte de la cellule correspondante avec le MIMETYPE msword. La mise à jour dans la base se fait à travers l'outil de conversion HTML décrit précédemment.

Extensions futures

Pourquoi ne pas soumettre directement le document WORD depuis MS Word sans passer par un browser? Nous sommes donc en train de développer une macro WORD sous forme de bouton Oxymoron dans la barre d'outils. Un simple clic dans Word suffira pour soumettre le document.