Extension Deployement fr

Premières considérations

Le déploiement d'extensions ne doit pas être considéré comme une tâche indépendante. Lorsque vous déployez des extenstions sur plusieurs postes de travail, vous devez également déployer des modèles, des auto-textes, des thèmes pour la Gallery, etc, pour conserver une certaine homogénéité. En fait, la plupart du temps, vous devez déployer des extensions en même temps que des modèles, des auto-textes et des thèmes pour la Gallery.

C'est pourquoi, nous considérons ici de suivre l'approche suivante :

1 - définir la structure d'un package dont le but est de déployer les extensions en une opération, incluant la macro et les barres d'outils, les modèles, les auto-textes et les thèmes de Gallery ;

2 - définir l'interface utilisateur d'un outil d'admnistration dont le but est de créer un tel package ;

3 - définir l'interface utilisateur d'un outil qui permettra à l'utilisateur final d'installer le package sur son poste de travail ou permettra à l'administrateur de l'installer dans l'arborescence d'installation partagée.

Contexte technique

Avant de spécifier le contenu du package, nous devons garder à l'esprit les contraintes techniques induites par l'implémentation de la configuration des objets, et les règles pour spécifier leur emplacement.

Le registre OOo

OOo vient avec son propre système de registre.

Le registre est implémenté dans un répertoire nommé "registry", aussi bien dans le répertoire d'installation partagé (share) que dans le répertoire utlisateur .openoffice.org2/user.

Lorsque l'utilisateur modifie son environnement OOo, parfois son répertoire est modifié et parfois il ne l'est pas. Le processus d'installation ne doit pas directement altérer le répertoire utilisateur OOo si cette modification cause une altération dans le registre. Dans ce cas, le travail doit être pris en charge par OOo, donc le processus d'installation doit invoquer une API OOo.

Emplacements par défaut

L'emplacement par défaut des objets semble être spécifié dans ce fichier $(insturl)/share/registry/schema/org/openoffice/Office/Common.xcs

Dans la plupar des fichiers de configuration, les emplacements fréquemment utilisé sont référencés via des variables :

$(insturl) représente le répertoire d'installation, ex. /opt/openoffice.org2.0

$(userurl) représente le répertoire de configuration utilisateur, ex. /home/smith/.openoffice.org2/user

$(work) correspond au répertoire de travail de l'utilisateur.

Modèles

L'emplacement par défaut des modèles est spécifié dans la partie XML suivante :

<prop oor:name="Template" oor:type="oor:string-list">
    <info>
       <desc>Specifies the templates originate from these folders and sub-folders.</desc>
    </info>
    <value oor:separator=":">$(insturl)/share/template/$(vlang):$(userurl)/template</value>
</prop>

Les modèles sont des objets très proches des autres objets produits par la suite. La différence réside dans la présence du 't' à la place du 'd' à la seconde place du suffixe, et dans le tronc virtuel pour y accéder, construit à partir de l'ensemble de chemins déclaré dans les fichiers de configuration.

A partir du moment où l'utilisateur modifie quelque chose dans les chemins, ils sont stockés dans le fichier $(userurl)/registry/data/org/openoffice/Office/Common.xcu

Auto-textes

L'emplacement par défaut des auto-textes est spécifié dans la partie XML suivante :

<prop oor:name="AutoText" oor:type="oor:string-list">
   <info>
       <desc>Contains the directory which contains the AutoText modules.</desc>
   </info>
   <value oor:separator=":">$(insturl)/share/autotext/$(vlang):$(userurl)/autotext</value>
</prop>

Les auto-textes sont organisés en catégories. L'utilisateur peut créer autant de catégories qu'il veut et demander à ce qu'elles soient stockées dans un des répertoires déclarés dans le fichier de configuration, à partir du moment où il a l'accès en écriture. Chaque catégorie est implémentée dans un ficher nommé <category_name>.bau qui est en fait une archive ZIP.

Néanmoins, si le nom de la catérogie contient des caractères spéciaux, ils sont silencieusement retirés du nom de fichier. Il est donc plus efficace de rechercher le nom de la catégorie dans le fichier BlockList.xml inclue dans l'archive.

Base de données

Les bases de données sont décrites dans des fichiers .odb qui peuvent être stockés n'importe où. Ce sont des archives standard de OOo. Le fichier content.xml décrit la source de données et certains attributs de la base de données.

Les bases de données sont déclarées dans le fichier suivant du répertoire de registre :

$(userurl)/registry/data/org/openoffice/Office/DataAccess.xcu

The database name must appear in the "RegisteredNames" node.

<node oor:name="RegisteredNames">
   ...
   <node oor:name="the_database_name" oor:op="replace">
      <prop oor:name="Location" oor:type="xs:string">
       <value>file://the/location/of/the/database.odb</value>
      </prop>
      <prop oor:name="Name" oor:type="xs:string">
       <value>the_database_name</value>
      </prop>
    </node>
    ...
</node>

Thèmes de la Gallery

Pour le moment, l'organisation des thèmes dans OOo semble un peu compliqué.

Les thèmes sont stockés dans trois fichiers binaires, ces formats sont hérités de Star Office.

Les fichiers sont suffixés : .sdg, .sdv et .thm.

Le fichier .thm contient, en plus de données binaires, le nom du thème tel que donné par l'utilisateur.

Le nom de chaque fichier est sous la forme sgNNN.xxx où NNN est un nombre (le même que celui des trois fichiers) et xxx le suffixe.

Apparemment, la seule règle pour choisir le nombre est d'obtenir des noms de fichiers uniques dans le répertoire cible.

Cette implémentation est adaptée à une organisation locale de thèmes, mais ne donne pas satisfaction lors de l'échange de thèmes entre utilisateurs. En fait, la question est : comment détecter des doublons pendant l'installation ?

en utilisant le nom de fichier ? 

dans la msesure où le nom est donné au hasard pendant l'installation, le même thème peut avoir différents nom dépendant de l'historique des versions précédentes sur différents postes de travail. De plus OOo peut avoir donné le même nom de fichier à différents thèmes créés sur différentes stations de travail.

en utilisant le nom stocké dans le fichier .thm ? 

si ce nom est trop générique, comme "personnes", "événements" ou "maisons" le même nom pourrait être donné à différents thèmes créés par différents utilisateurs.

Donc, lors de l'installation, il est pertinent de considérer les cas suivants :

le nombre et le nom du thème n'existent pas 

installation directe du thème ;

le nombre existe déjà et le nom du thème n'existe pas 

recherche d'un autre nombre discriminant ;

le thème existe déjà 

demande à l'utilisatuer si le thème existant doit être écrasé, ou le nouveau renommé, ou son installation abandonnée.

Il est important de rechercher systématiquement le nom du thème dans tous les thèmes existants.

Macros

A compléter

Barres d'outils

A compléter

Gestionnaire de packages

A cette étape il est important de considérer le gestionnaire de package fournit par OOo 2.0

Le gestionnaire de package peut importer, activer, désactiver et exporter des packages.

Dans le package, vous pouvez stocker un module pouvant contenir plusieurs bibliothèques de macros.

Vous pouvez décrire des options de menu principales, des options de barres d'outils et des boutons pour lancer les macros. Les boutons sont regourpés en une nouvelle barre d'outils.

Actuellement le gestionnaire de package ne prend pas en charge les modèles, les auto-textes et les thèmes de la Gallery.

Un package est une archive zip.

La racine de cete archive contient un fichier addons.xcu dont le contenu est décrit ici

L'existant

Ce projet ne doit pas partir de zero. Certains travaux ont déjà été réalisés et suit une référence non exhaustive à ceux-ci :

• Bernard Marcelly a rédigé un document appelé "Comment distribuer des macros sous forme d'Addon" contenant des macros rendant la création de package très simple.

• Didier Dorange-Pattoret a écrit une macro permettant d'installer des thèmes de Gallery simplement.

• Laurent Godard a écrit DicOOo qui permet d'installer des dictionnaires sur le poste de travail et qui est maintenant distribué avec la version 2.0.

• Philippe Allart a écrit un script batch simple qui correspond à la structure décrite ci-dessous et qui utilise l'outil de Didier Dorange-Pattoret.

Specification de configuration d'un package

Disposition

Pour rester en harmonie avec les choix techniques de l'équipe de développement de OOo, nous suggérons que le package soit implémenté comme une archive zip.

Cette archive doit contenir un répertoire pour chaque type d'objet.

Ce serait peut-être une bonne idée d'ajouter un répertoire "goodies" permettant d'ajouter des objets non directement concernés par le processus de configuration mais qui seront très utiles à l'utilisateur final.

Ainsi, l'arborisation suggérée pourrait être la suivante :

1. /
   • tools allowing installation of the package
   • specifications for installation (location of templates, ...)
   1. /autotexts/
      • autotexts (.bau files) to be installed
   2. /packages/
      • packages (.zip files) to be installed
   3. /databases/
      • databases (.odb files) to be installed and possibly local data
   4. /templates/
      • templates to be installed
   5. /autocorr/
      • .dat files containing replacement rules and exceptions
   6. /wordbooks/
      • dictionaries to be installed
   7. /fonts/
      • fonts to be installed
   8. /gallery/
      • themes to be installed
   9. /goodies/

Dépendances

Les objets contenus dans le package ne sont pas complètement indépendants les uns des autres. Par exemple, une macro peut référer à des styles venant avec un modèle et être appelée lorsque le document est créé.

De plus, certains objets dans le package peuvent dépendre d'une installation précédente d'autres objets.

Il serait dont très utile d'identifier tous les types de dépendances et comment les exprimer.

Spécifications pour l'installation

A cette étape, il est nécessaire de définir ce qui va être spécifié et comment pour le processus d'installation. Il n'est pas la peine de réinventer la roue et il semble une bonne idée de réutliser la structure du fichier addons.xcu utilisé par le gestionnaire de package.

Cette structure est en fait très générique dans la mesure où elle ne contient pas de drapeaux spécifiques. C'est juste un ensemble de tableaux à deux colonnes contenant des paires propriétés/valeurs. Cest tableaux sont organisés en arborescence ou chaque node a un nom et un attribut.

Les shema XML Schema est le suivant :

Schema XML à décrire

Maintenant le travail consiste à :

• définir la structure de l'arborescence et donner un nom à chaque node ;
• pour chaque node, définir le contenu du tableau, i.e. l'ensemble des paires propriétés/valeurs.