Difference between revisions of "Non-code extensions FR"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Paquetage de Gallery)
 
(35 intermediate revisions by 7 users not shown)
Line 1: Line 1:
a traduire
+
traduction en cours ... sur la base de :
 
http://wiki.services.openoffice.org/wiki/Non-code_extensions
 
http://wiki.services.openoffice.org/wiki/Non-code_extensions
  
Line 6: Line 6:
 
__TOC__
 
__TOC__
  
= UNO Packages: Basic Principles =
+
= Packages UNO: Principes de base =
 +
 
 +
Le concept de déploiement des extensions OpenOffice.org basé sur les packages UNO n'est pas limité au code. Il est également possible d'installer d'autres choses dans des packages faciles d'utilisation, comme des modèles, des autotextes etc. Vous trouverez ci-dessous une explication du fonctionnement de base. Elle est destinée aux utilisateurs avancés et aux administrateurs système. La plupart des points abordés ici sont expliqués de façon plus détaillée et plus compréhensible à d'autres endroits. Le propos de la documentation ci-dessous est de présenter une vue générale et d'expliquer les principes de base. Si vous souhaitez en savoir plus sur UNO, vous pouvez consulter notre [[Uno |wiki UNO]] ou les pages web du  [http://udk.openoffice.org project UDK].
 +
 
 +
Toutes les informations fournies ici se rapportent à OpenOffice.org 2.0.4. Les différences pouvant exister avec des versions plus anciennes ne sont pas expliquées ici, bien que l'on puisse mentionner explicitement les choses apparues pour la première fois dans la 2.0.4.
 +
 
 +
Les packages UNO ne sont rien d'autre que des dossiers zippés avec des données supplémentaires et des méta-données décrivant le contenu. Il peuvent être déployés par l'interface du Gestionnaire de packages intégré à OOo ("Outils - Gestionnaire de packages") ou grace à l'outil en ligne de commande “unopkg” qui se trouve dans le répertoire "program" de OOo. Ce dernier permet non seulement le déploiement d'un package pour un utilisateur, mais également pour tous les utilisateurs avec le paramètre optionnel "--shared”. Quand les packages sont installés, leur contenu est recopié à des emplacements privés bien définis sous “share/uno_packages” ou “user/uno_packages”, selon la portée de l'installation du package (installation système ou simple utilisateur). On entend par "Privé" : ne pas écrire de code qui se fie à la structure particulière du composant UNO décompressé, l'accès aux fichiers compressés doit utiliser un API défini qui se charge des détails pour l'appelant. Des fichiers en dehors des dossiers "uno_packages" ne devraient jamais être affectés, à la seule exception dont l'explication se trouve ici [http://www.openoffice.org/issues/show_bug.cgi?id=70283 bug]: Des macros Basic dans des packages UNO doivent toujours être enregistrées dans un fichier xlc se trouvant dans l'un des répertoires "basic".
 +
 
 +
== Extensions comportant des services UNO (code) ==
 +
 
 +
Si un package UNO comporte un composant écrit en Java, C++ ou Python, ce dernier doit rendre publique sa fonctionnalité afin d'être fonctionnel au sein de OpenOffice.org. Dans les développements basés sur UNO, un ensemble de fonctionnalités défini est appelé un "service". Ceux-ci sont identifiés et on y accède par leurs noms de service. Un composant qui met en oeuvre de tels services doit informer les autres de son identification. Aujourd'hui tous les composants exportent une fonction qui peut être appélée par unopkg et qui va obliger le composant à écrire toutes les informations nécessaires dans le fichier de registre des services qui est créé et maintenu à l'intérieur d'un dossier „uno_package“. Lorsque OpenOffice.org se sert de son gestionnaire de service pour rechercher des services UNO disponibles, il regardera non seulement dans le registre des services (services.rdb) au sein du répertoire principal du programme (contenant toutes les informations sur les "services internes"), mais également dans tous les fichiers de registre se trouvant dans les dossiers “uno_packages”.
 +
 
 +
OOo n'est capable d'instancier des services UNO par leurs noms que s'il en connaît l'existence. Ceci est facile pour des services qui remplacent ceux déjà présents en "interne" puisqu'OOo les connaît déjà et s'en sert couramment, mais comme la plupart des composants fournissent de nouveaux services, il doit exister autre chose qui permet à OOo de s'en servir bien que lui étant inconnus lors de la compilation. Pour ces cas précis, les composants UNO doivent fournir des données complémentaires sur le moment auquel le chargement d'un service donné doit s'effectuer. Ces "données de composant additionnelles" sont fournies dans les fichiers de configuration de OOo.
 +
 
 +
Un exemple serait un composant de filtre de document dans lequel les données complémentaires qui doivent être fournies consistent (entre autres) en le type de fichier que le filtre sait charger. Un composant de filtre précis pourrait se déclarer capable de charger des fichiers WordPerfect. Ainsi, si un utilisateur choisit ce filtre pour charger un ficher dans l'application alors OOo trouverait les données déclarées en recherchant toutes données contenant le type de fichier souhaité (wps), instancierait le composant de filtre par son nom de service tel que découvert dans ces données et ensuite s'en servir pour charger le fichier dans l'application. Chaque filtre déjà présent dans OOo a ses propres données de configuration et les filtres de conversion de documents dans les packages UNO fournissent leurs propres données de configuration de manière à complémenter celles déjà présentes dans le produit.
 +
 
 +
== Support des Packages dans le Gestionnaire de Configuration ==
 +
Le Gestionnaire de Configuration d'OpenOffice.org possède également la capacité à rechercher dans un ensemble de dossiers extensibles de la même manière que le Gestionnaire de Services. S'il trouve plusieurs fichiers de configuration dans ces dossiers contenant des données pour les mêmes éléments dans l'arborescence des entrées de configuration, soit il les fusionnera, soit il remplacera des données d'ordre hiérarchique inférieur par des données d'ordre hiérarchique supérieur, selon le type de données de configuration. Les données de configuration "utilisateur" ont toujours précédence sur les données de configuration préinstallées se trouvant dans la couche partagée ("share"). Les données de configuration des packages UNO se situent entre ces deux extrêmes : les données de configuration partagées des packages UNO ont un ordre hiérarchique supérieur à la couche partagée pré-installée, mais un ordre hiérarchique inférieur aux données de configuration "utilisateur".
 +
 
 +
Il demeure la question suivante : quelles données sont fusionnées lorsqu'il y a au moins deux couches de configuration ?
 +
 
 +
Le Gestionnaire de Configuration a tendance à prendre ses informations dans des fichiers xml (portant l'extension de fichier xcu) avec des éléments typés. Il supporte quelques types de base, des types structurés qui doivent être définis dans des fichiers de schéma (portant l'extension de fichier xcs) et fait une liste de tous ces types. Ceux-ci ne peuvent pas être étendus. Si la configuration découvre des valeurs différentes de celles dans les différentes couches, c'est la valeur de l'ordre hiérarchique supérieur qui est retenue. Pour la fusion d'éléments de configuration et par ce biais l'extension de la fonctionnalité qui en dépend nécessite le type "set". Pour mieux comprendre son fonctionnement, regardez dans [[Configuration_schema_path_settings|configuration schema]] mentionné dans la section "Configuration des Chemins".
 +
 
 +
Un composant peut étendre ou modifier la configuration de OpenOffice.org en lui fournissant des fichiers xcu dans son package qui remplaceront ou étendront (fusion) des entrées de configuration dans OpenOffice.org. Il peut également disposer de ses propres entrées de configuration s'il fournit des fichiers de schéma (xcs) dans son package.
 +
 
 +
Il existe un autre cas d'utilisation (relativement évident) du principe de couches du gestionnaire de configuration : le remplacement des entrées de configuration de OpenOffice.org au niveau de tous les utilisateurs ("all users"). Un administrateur peut personnaliser l'installation de OpenOffice.org dans son propre compte utilisateur, et puis ensuite prendre les fichiers xcu créés contenant les personnalisations et les inclure dans un package qu'il installera par la suite avec "unopkg add --shared" chaque fois qu'il installera, réinstallera ou mettra à jour OpenOffice.org. Il n'y aura ainsi aucun besoin d'éditer les fichiers xcu dans "share/registry" à la main !
 +
 
 +
Le principe des couches du registre de services et de la configuration sont les principes de base qui rendent le système de packages UNO à la fois solide et flexible.
 +
 
 +
= Configuration des Chemins =
 +
Quelques données d'OpenOffice.org ne sont pas stockées dans les fichiers de configuration xcu mais ailleurs dans le système de fichiers, comme, par exemple, les modèles de documents, l'autotexte, le contenu de la galerie, etc. Bien entendu ce contenu doit pouvoir être déployé dans des packages, mais dans ce cas, d'ordinaire, vous ne souhaitez pas remplacer le contenu existant, vous souhaitez lui ajouter quelque chose. Aussi l'accès à ces fichiers doit également respecter un principe de couches. OpenOffice.org dispose de quelques composants qui gèrent l'accès aux fichiers. Nous aurions pu étendre ces composants de la  même façon que nous avons étendu le Gestionnaire de Configuration ou le Gestionnaire de Services (en les rendant capables d'utiliser explicitement des couches), mais nous avons décidé de réutiliser la capacité déjà disponible du Gestionnaire de Configuration.
 +
 
 +
L'endroit où sont recherchés ces fichiers est défini dans la configuration soit comme un simple chemin, soit comme une liste de chemins ("multichemin"). Malheureusement, une telle liste ne peut qu'être remplacée dans les couches les plus hautes et non étendue, aussi avons-nous besoin d'un nouveau schéma de configuration pour les chemins, nouveau schéma qui utilise des "ensembles" au lieu de "listes" comme ils peuvent être étendus par des packages. Nous utilisons ce nouveau schéma pour les chemins à partir d'OpenOffice.org 2.0.4. Nous avons gardé l'ancien schéma et ses données pour des raisons de compatibilité et porterons ces réglages vers les nouvelles données. L'ancien schéma sera supprimé dans OpenOffice.org 3.0.
 +
 
 +
Si vous jetez un coup d'oeil aux entrées des "Chemins" dans la boîte de dialogue "Options" dans OOo2.0.4 vous remarquerez que toutes les parties des multichemins n'y sont pas montrées. Dans les versions antérieures  d'OOo, vous pouviez voir habituellement deux dossiers pour les modèles par exemple :  $(share)/templates et $(user)/templates, où "$(share)" et "$(user) sont des variables pour les dossiers partage (share) et utilisateur (user) de l'installation particulière. Vous pourriez voir de même tous les dossiers supplémentaires que l'administrateur ou l'utilisateur ont pu ajouter. Dans OOo2.0.4 vous continuerez de voir $(user)/templates et ces dossiers additionnels (si jamais il y en a), mais vous ne verrez plus $(share)/templates à cet endroit-ci. Si des packages contenant des modèles de documents sont installés, leur dossier ne sera pas montré ici non plus, ce dialogue n'est désormais qu'un outil pour permettre à l'utilisateur d'adapter les réglages qui sont sous son contrôle direct.
 +
 
 +
      [[Image:Dialog_Tools_Options_204.png]]
 +
 
 +
=Packages de Modèles=
 +
 
 +
Un package UNO pour les modèles de documents est plutôt simple. Il contient principalement les modèles, organisés en des répertoires qui définissent les catégories de modèles pour le Gestionnaire de Modèles de Documents. De plus, un fichier Paths.xcu doit être fourni, fichier qui enregistre le package dans l'ensemble des dossiers de modèles de documents. Ce fichier contient l'URL du dossier où les modèles du package seront décompressés. Comme il s'agit là d'une inconnue lors de la création du package, une variable est utilisée dans l'URL, remplacée par le gestionnaire de packages quand il copie le fichier xcu à son emplacement final. L'avantage réside en ce que cette variable sera toujours la même pour chaque package de modèles et qu'ainsi le créateur d'un tel package n'aura aucun besoin de la créer lui-même :
 +
 
 +
'''Paths.xcu'''
 +
<code> [xml]
 +
<?xml version='1.0' encoding='UTF-8'?>
 +
 
 +
<oor:component-data oor:package="org.openoffice.Office"
 +
    oor:name="Paths" xmlns:install="http://openoffice.org/2004/installation"
 +
    xmlns:oor="http://openoffice.org/2001/registry"
 +
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
 +
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 +
 
 +
<node oor:name="Paths">
 +
 
 +
<node oor:name="Template" oor:op="fuse">
 +
<node oor:name="InternalPaths">
 +
<node oor:name="%origin%/template" oor:op="fuse"/>
 +
</node>
 +
</node>
 +
 
 +
</node>
 +
</oor:component-data>
 +
</code>
 +
 
 +
 
 +
== Exemple de Package ==
 +
[http://framework.openoffice.org/files/documents/25/3702/TemplatePackage.oxt À cet endroit] se trouve un package vide pour modèles de documents prêt à être rempli de modèles.
 +
 
 +
Le conteneur au format zip possède un dossier nommé "template". Tout sous-dossier que vous y créerez apparaîtra comme une catégorie de modèles dans les dialogues de modèles d'OOo. Les modèles peuvent être déposés dans ces sous-dossiers. Le titre du modèle sera emprunté aux métadonnées du document (les propriétés du document) ou au nom du fichier  si le titre n'est pas positionné dans les métadonnées. Si un de vos sous-dossiers a le nom d'une catégorie de modèles déjà présente, les modèles du package seront ajoutés à cette catégorie par le composant des modèles d'OpenOffice.org. Essayez, c'est plus simple à faire qu'à expliquer.
 +
 
 +
== Localisation des modèles et des catégories de modèles ==
 +
Les titres des catégories et modèles peuvent être pris aux noms des dossiers et fichiers. Ces noms peuvent être traduits  et utiliser tous les caractères que le conteneur zip et le (ou les) système de fichiers cible autorisent. Il peut arriver que les modèles soient installés sur des systèmes de fichiers où l'on rencontre des problèmes avec les noms  de catégories (les noms de dossiers) traduits. Le composant des Modèles de Documents permet de fournir ces noms traduits dans un fichier différent. Les noms traduits des modèles de documents peuvent être enregistrés dans les métadonnées du document (les propriétés du document) de façon à ce qu'aucun problème ne survienne ici.
 +
 
 +
Le fichier de localisation s'appelle "groupuinames.xml" et prend place dans le sous-dossier "template" du package. Son contenu s'appréhende directement. Voici un exemple d'adaptation française de quelques dossiers qui utilisent des noms de fichiers en anglais :
 +
 
 +
'''groupuinames.xml'''
 +
<code> [xml]
 +
<?xml version="1.0" encoding="UTF-8"?>
 +
<groupuinames:template-group-list xmlns:groupuinames="http://openoffice.org/2006/groupuinames">
 +
        <groupuinames:template-group groupuinames:name="educate"
 +
                groupuinames:default-ui-name="Éducation" />
 +
        <groupuinames:template-group groupuinames:name="layout"
 +
                groupuinames:default-ui-name="Arrière-plans de présentation" />
 +
        <groupuinames:template-group groupuinames:name="misc"
 +
                groupuinames:default-ui-name="Divers" />
 +
        <groupuinames:template-group groupuinames:name="officorr"
 +
                groupuinames:default-ui-name="Correspondance d'affaires" />
 +
        <groupuinames:template-group groupuinames:name="offimisc"
 +
                groupuinames:default-ui-name="Autres documents d'affaires" />
 +
        <groupuinames:template-group groupuinames:name="personal"
 +
                groupuinames:default-ui-name="Correspondance privée et documents" />
 +
        <groupuinames:template-group groupuinames:name="presnt"
 +
                groupuinames:default-ui-name="Présentations" />
 +
</groupuinames:template-group-list>
 +
</code>
 +
 
 +
 
 +
== Packages multilingues de modèles ==
 +
Des packages multilingues de modèles sont également possibles. Ils nécessitent d'une part une légère modification de la ligne 13 du fichier Paths.xcu :
 +
 
 +
'''Paths.xcu'''
 +
<code> [xml]
 +
<?xml version='1.0' encoding='UTF-8'?>
 +
 
 +
<oor:component-data oor:package="org.openoffice.Office"
 +
    oor:name="Paths" xmlns:install="http://openoffice.org/2004/installation"
 +
    xmlns:oor="http://openoffice.org/2001/registry"
 +
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
 +
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 +
 
 +
<node oor:name="Paths">
 +
 
 +
<node oor:name="Template" oor:op="fuse">
 +
<node oor:name="InternalPaths">
 +
                                <node oor:name="%origin%/template/$(vlang)" oor:op="fuse"/>
 +
</node>
 +
</node>
 +
 
 +
</node>
 +
 
 +
</oor:component-data>
 +
 
 +
</code>
 +
 
 +
et, d'autre part, la création de dossiers supplémentaires. Il s'agit des dossiers qui contiendront les modèles, sous-dossiers du dossier "template", et qui  auront comme nom les codes ISO des langages  fournis par les packs de langues d'OOo. Vous trouverez [http://framework.openoffice.org/files/documents/25/3706/MultiLanguageTemplatePackage.oxt un deuxième package vide] qui fournit l'infrastructure d'un tel package. Utilisez-le et placez les modèles en allemand dans le dossier "de", ceux en anglais dans le dossier "en-US", ceux en français dans le dossier "fr" etc.  Des dossiers vides ne posent pas de problème. Chaque fichier de localisation (groupuinames.xml) doit désormais être placé dans le dossier correspondant au langage qu'il utilise et non plus directement dans le dossier  "template" comme dans le cas d'un package monolingue.
 +
 
 +
 
 +
= Packages Autotexte =
 +
 
 +
Tout ce qui a été expliqué ci-dessus par rapport aux pacakges de modèles s'applique également aux packages autotextes. Le fichier comporte alors, à la place d'une valeur pour le chemin du "Template", une valeur correspondant au chemin "AutoTexte". Un exemple d'un tel package se trouve [http://framework.openoffice.org/files/documents/25/3710/AutoTextPackage.oxt ici]. Cet exemple peut être utilisé pour fournir des fichiers autotexte. A l'heure actuelle, il n'existe aucune méthode d'export pour ces fichiers, il est donc aussi simple de copier les fichiers "*.bau" à la main qui ont été créés directement dans le package. De la même manière, on peut créer des packages d'autotextes localisés dans la langue de son choix: il suffit de placer les fichiers dans des sous-dossiers portant des noms conformes aux codes langue ISO, comme cela est indiqué dans le dossier "share/autotext". Contrairement aux packages de modèles, le chemin de l'autotexte ne nécessite pas d'inclure "$(vlang)" pour obtenir des packages multilingues puisque le composant gérant les autotextes implémente déjà en interne l'accès indépendamment de la langue.
 +
 
 +
Une remarque toutefois qui pose parfois des problèmes lors du déploiement de packages autotextes: l'interface graphique de l'utilisateur permet à l'heure actuelle d'enregistrer les autotextes dans des endroits arbitraires. Ceci est une erreur de fonctionnement ou [http://www.openoffice.org/issues/show_bug.cgi?id=70410 bug] qui devrai être corrigée dans des versions futures de OpenOffice.org. Tout changement appliqué à des autotextes présents dans un package seront perdus lors de la désinstallation du package. Il n'est pas prévu qu'on puisse changer le contenu des packages!
 +
 
 +
= Paquetage de Gallery =
 +
 
 +
Tout ce qui a été écrit ci-dessus s'applique également aux packages de Gallery. Le fichier Paths.xcu contient cette fois-ci une valeur relative au chemin du "Gallery" à place de celui des "Template". Un exemple d'un package Gallery se trouve  [http://framework.openoffice.org/files/documents/25/3711/GalleryPackage.oxt ici]. On peut ainsi le remplir avec les thèmes de Gallery qu'on souhaite.
 +
Comme cet aspect des choses n'est pas aussi facile à maîtriser que cela puisse paraître, le code a souvent tendance à provoquer des conflits de noms entre les différents fichiers de thème, '''il est déconseillé ne pas mettre en oeuvre des packages de Gallery''' tant que le bug référencé  [http://www.openoffice.org/issues/show_bug.cgi?id=70412 ici] n'est pas résolu. ''En effet, les thèmes utilisent actuellement une valeur numérique et l'ajout d'un thème pourrait écraser un autre thème portant le même numéro.''
 +
 
 +
= Packages pour dictionaires et wordbooks utilisateurs =
 +
 
 +
Ce travail n'est pas encore achevé parce qu'il nécessite une refonte de l'accès aux fichiers se rapportant aux outils linguistiques. Revenez de temps en temps pour voir où cela en est.

Latest revision as of 13:08, 18 July 2010

traduction en cours ... sur la base de : http://wiki.services.openoffice.org/wiki/Non-code_extensions

OOo Extensions project

Please view the wiki usage guidelines
before contributing.

Categories:

Pages:

Extensions on the main site

Extensions in other languages:
ES - FR - IT - JA - NL - OC -

Packages UNO: Principes de base

Le concept de déploiement des extensions OpenOffice.org basé sur les packages UNO n'est pas limité au code. Il est également possible d'installer d'autres choses dans des packages faciles d'utilisation, comme des modèles, des autotextes etc. Vous trouverez ci-dessous une explication du fonctionnement de base. Elle est destinée aux utilisateurs avancés et aux administrateurs système. La plupart des points abordés ici sont expliqués de façon plus détaillée et plus compréhensible à d'autres endroits. Le propos de la documentation ci-dessous est de présenter une vue générale et d'expliquer les principes de base. Si vous souhaitez en savoir plus sur UNO, vous pouvez consulter notre wiki UNO ou les pages web du project UDK.

Toutes les informations fournies ici se rapportent à OpenOffice.org 2.0.4. Les différences pouvant exister avec des versions plus anciennes ne sont pas expliquées ici, bien que l'on puisse mentionner explicitement les choses apparues pour la première fois dans la 2.0.4.

Les packages UNO ne sont rien d'autre que des dossiers zippés avec des données supplémentaires et des méta-données décrivant le contenu. Il peuvent être déployés par l'interface du Gestionnaire de packages intégré à OOo ("Outils - Gestionnaire de packages") ou grace à l'outil en ligne de commande “unopkg” qui se trouve dans le répertoire "program" de OOo. Ce dernier permet non seulement le déploiement d'un package pour un utilisateur, mais également pour tous les utilisateurs avec le paramètre optionnel "--shared”. Quand les packages sont installés, leur contenu est recopié à des emplacements privés bien définis sous “share/uno_packages” ou “user/uno_packages”, selon la portée de l'installation du package (installation système ou simple utilisateur). On entend par "Privé" : ne pas écrire de code qui se fie à la structure particulière du composant UNO décompressé, l'accès aux fichiers compressés doit utiliser un API défini qui se charge des détails pour l'appelant. Des fichiers en dehors des dossiers "uno_packages" ne devraient jamais être affectés, à la seule exception dont l'explication se trouve ici bug: Des macros Basic dans des packages UNO doivent toujours être enregistrées dans un fichier xlc se trouvant dans l'un des répertoires "basic".

Extensions comportant des services UNO (code)

Si un package UNO comporte un composant écrit en Java, C++ ou Python, ce dernier doit rendre publique sa fonctionnalité afin d'être fonctionnel au sein de OpenOffice.org. Dans les développements basés sur UNO, un ensemble de fonctionnalités défini est appelé un "service". Ceux-ci sont identifiés et on y accède par leurs noms de service. Un composant qui met en oeuvre de tels services doit informer les autres de son identification. Aujourd'hui tous les composants exportent une fonction qui peut être appélée par unopkg et qui va obliger le composant à écrire toutes les informations nécessaires dans le fichier de registre des services qui est créé et maintenu à l'intérieur d'un dossier „uno_package“. Lorsque OpenOffice.org se sert de son gestionnaire de service pour rechercher des services UNO disponibles, il regardera non seulement dans le registre des services (services.rdb) au sein du répertoire principal du programme (contenant toutes les informations sur les "services internes"), mais également dans tous les fichiers de registre se trouvant dans les dossiers “uno_packages”.

OOo n'est capable d'instancier des services UNO par leurs noms que s'il en connaît l'existence. Ceci est facile pour des services qui remplacent ceux déjà présents en "interne" puisqu'OOo les connaît déjà et s'en sert couramment, mais comme la plupart des composants fournissent de nouveaux services, il doit exister autre chose qui permet à OOo de s'en servir bien que lui étant inconnus lors de la compilation. Pour ces cas précis, les composants UNO doivent fournir des données complémentaires sur le moment auquel le chargement d'un service donné doit s'effectuer. Ces "données de composant additionnelles" sont fournies dans les fichiers de configuration de OOo.

Un exemple serait un composant de filtre de document dans lequel les données complémentaires qui doivent être fournies consistent (entre autres) en le type de fichier que le filtre sait charger. Un composant de filtre précis pourrait se déclarer capable de charger des fichiers WordPerfect. Ainsi, si un utilisateur choisit ce filtre pour charger un ficher dans l'application alors OOo trouverait les données déclarées en recherchant toutes données contenant le type de fichier souhaité (wps), instancierait le composant de filtre par son nom de service tel que découvert dans ces données et ensuite s'en servir pour charger le fichier dans l'application. Chaque filtre déjà présent dans OOo a ses propres données de configuration et les filtres de conversion de documents dans les packages UNO fournissent leurs propres données de configuration de manière à complémenter celles déjà présentes dans le produit.

Support des Packages dans le Gestionnaire de Configuration

Le Gestionnaire de Configuration d'OpenOffice.org possède également la capacité à rechercher dans un ensemble de dossiers extensibles de la même manière que le Gestionnaire de Services. S'il trouve plusieurs fichiers de configuration dans ces dossiers contenant des données pour les mêmes éléments dans l'arborescence des entrées de configuration, soit il les fusionnera, soit il remplacera des données d'ordre hiérarchique inférieur par des données d'ordre hiérarchique supérieur, selon le type de données de configuration. Les données de configuration "utilisateur" ont toujours précédence sur les données de configuration préinstallées se trouvant dans la couche partagée ("share"). Les données de configuration des packages UNO se situent entre ces deux extrêmes : les données de configuration partagées des packages UNO ont un ordre hiérarchique supérieur à la couche partagée pré-installée, mais un ordre hiérarchique inférieur aux données de configuration "utilisateur".

Il demeure la question suivante : quelles données sont fusionnées lorsqu'il y a au moins deux couches de configuration ?

Le Gestionnaire de Configuration a tendance à prendre ses informations dans des fichiers xml (portant l'extension de fichier xcu) avec des éléments typés. Il supporte quelques types de base, des types structurés qui doivent être définis dans des fichiers de schéma (portant l'extension de fichier xcs) et fait une liste de tous ces types. Ceux-ci ne peuvent pas être étendus. Si la configuration découvre des valeurs différentes de celles dans les différentes couches, c'est la valeur de l'ordre hiérarchique supérieur qui est retenue. Pour la fusion d'éléments de configuration et par ce biais l'extension de la fonctionnalité qui en dépend nécessite le type "set". Pour mieux comprendre son fonctionnement, regardez dans configuration schema mentionné dans la section "Configuration des Chemins".

Un composant peut étendre ou modifier la configuration de OpenOffice.org en lui fournissant des fichiers xcu dans son package qui remplaceront ou étendront (fusion) des entrées de configuration dans OpenOffice.org. Il peut également disposer de ses propres entrées de configuration s'il fournit des fichiers de schéma (xcs) dans son package.

Il existe un autre cas d'utilisation (relativement évident) du principe de couches du gestionnaire de configuration : le remplacement des entrées de configuration de OpenOffice.org au niveau de tous les utilisateurs ("all users"). Un administrateur peut personnaliser l'installation de OpenOffice.org dans son propre compte utilisateur, et puis ensuite prendre les fichiers xcu créés contenant les personnalisations et les inclure dans un package qu'il installera par la suite avec "unopkg add --shared" chaque fois qu'il installera, réinstallera ou mettra à jour OpenOffice.org. Il n'y aura ainsi aucun besoin d'éditer les fichiers xcu dans "share/registry" à la main !

Le principe des couches du registre de services et de la configuration sont les principes de base qui rendent le système de packages UNO à la fois solide et flexible.

Configuration des Chemins

Quelques données d'OpenOffice.org ne sont pas stockées dans les fichiers de configuration xcu mais ailleurs dans le système de fichiers, comme, par exemple, les modèles de documents, l'autotexte, le contenu de la galerie, etc. Bien entendu ce contenu doit pouvoir être déployé dans des packages, mais dans ce cas, d'ordinaire, vous ne souhaitez pas remplacer le contenu existant, vous souhaitez lui ajouter quelque chose. Aussi l'accès à ces fichiers doit également respecter un principe de couches. OpenOffice.org dispose de quelques composants qui gèrent l'accès aux fichiers. Nous aurions pu étendre ces composants de la même façon que nous avons étendu le Gestionnaire de Configuration ou le Gestionnaire de Services (en les rendant capables d'utiliser explicitement des couches), mais nous avons décidé de réutiliser la capacité déjà disponible du Gestionnaire de Configuration.

L'endroit où sont recherchés ces fichiers est défini dans la configuration soit comme un simple chemin, soit comme une liste de chemins ("multichemin"). Malheureusement, une telle liste ne peut qu'être remplacée dans les couches les plus hautes et non étendue, aussi avons-nous besoin d'un nouveau schéma de configuration pour les chemins, nouveau schéma qui utilise des "ensembles" au lieu de "listes" comme ils peuvent être étendus par des packages. Nous utilisons ce nouveau schéma pour les chemins à partir d'OpenOffice.org 2.0.4. Nous avons gardé l'ancien schéma et ses données pour des raisons de compatibilité et porterons ces réglages vers les nouvelles données. L'ancien schéma sera supprimé dans OpenOffice.org 3.0.

Si vous jetez un coup d'oeil aux entrées des "Chemins" dans la boîte de dialogue "Options" dans OOo2.0.4 vous remarquerez que toutes les parties des multichemins n'y sont pas montrées. Dans les versions antérieures d'OOo, vous pouviez voir habituellement deux dossiers pour les modèles par exemple : $(share)/templates et $(user)/templates, où "$(share)" et "$(user) sont des variables pour les dossiers partage (share) et utilisateur (user) de l'installation particulière. Vous pourriez voir de même tous les dossiers supplémentaires que l'administrateur ou l'utilisateur ont pu ajouter. Dans OOo2.0.4 vous continuerez de voir $(user)/templates et ces dossiers additionnels (si jamais il y en a), mais vous ne verrez plus $(share)/templates à cet endroit-ci. Si des packages contenant des modèles de documents sont installés, leur dossier ne sera pas montré ici non plus, ce dialogue n'est désormais qu'un outil pour permettre à l'utilisateur d'adapter les réglages qui sont sous son contrôle direct.

      Dialog Tools Options 204.png

Packages de Modèles

Un package UNO pour les modèles de documents est plutôt simple. Il contient principalement les modèles, organisés en des répertoires qui définissent les catégories de modèles pour le Gestionnaire de Modèles de Documents. De plus, un fichier Paths.xcu doit être fourni, fichier qui enregistre le package dans l'ensemble des dossiers de modèles de documents. Ce fichier contient l'URL du dossier où les modèles du package seront décompressés. Comme il s'agit là d'une inconnue lors de la création du package, une variable est utilisée dans l'URL, remplacée par le gestionnaire de packages quand il copie le fichier xcu à son emplacement final. L'avantage réside en ce que cette variable sera toujours la même pour chaque package de modèles et qu'ainsi le créateur d'un tel package n'aura aucun besoin de la créer lui-même :

Paths.xcu [xml] <?xml version='1.0' encoding='UTF-8'?>

<oor:component-data oor:package="org.openoffice.Office"

   oor:name="Paths" xmlns:install="http://openoffice.org/2004/installation" 
   xmlns:oor="http://openoffice.org/2001/registry" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<node oor:name="Paths">

<node oor:name="Template" oor:op="fuse"> <node oor:name="InternalPaths"> <node oor:name="%origin%/template" oor:op="fuse"/> </node> </node>

</node> </oor:component-data>


Exemple de Package

À cet endroit se trouve un package vide pour modèles de documents prêt à être rempli de modèles.

Le conteneur au format zip possède un dossier nommé "template". Tout sous-dossier que vous y créerez apparaîtra comme une catégorie de modèles dans les dialogues de modèles d'OOo. Les modèles peuvent être déposés dans ces sous-dossiers. Le titre du modèle sera emprunté aux métadonnées du document (les propriétés du document) ou au nom du fichier si le titre n'est pas positionné dans les métadonnées. Si un de vos sous-dossiers a le nom d'une catégorie de modèles déjà présente, les modèles du package seront ajoutés à cette catégorie par le composant des modèles d'OpenOffice.org. Essayez, c'est plus simple à faire qu'à expliquer.

Localisation des modèles et des catégories de modèles

Les titres des catégories et modèles peuvent être pris aux noms des dossiers et fichiers. Ces noms peuvent être traduits et utiliser tous les caractères que le conteneur zip et le (ou les) système de fichiers cible autorisent. Il peut arriver que les modèles soient installés sur des systèmes de fichiers où l'on rencontre des problèmes avec les noms de catégories (les noms de dossiers) traduits. Le composant des Modèles de Documents permet de fournir ces noms traduits dans un fichier différent. Les noms traduits des modèles de documents peuvent être enregistrés dans les métadonnées du document (les propriétés du document) de façon à ce qu'aucun problème ne survienne ici.

Le fichier de localisation s'appelle "groupuinames.xml" et prend place dans le sous-dossier "template" du package. Son contenu s'appréhende directement. Voici un exemple d'adaptation française de quelques dossiers qui utilisent des noms de fichiers en anglais :

groupuinames.xml [xml] <?xml version="1.0" encoding="UTF-8"?> <groupuinames:template-group-list xmlns:groupuinames="http://openoffice.org/2006/groupuinames">

       <groupuinames:template-group groupuinames:name="educate" 
               groupuinames:default-ui-name="Éducation" />
       <groupuinames:template-group groupuinames:name="layout" 
               groupuinames:default-ui-name="Arrière-plans de présentation" />
       <groupuinames:template-group groupuinames:name="misc" 
               groupuinames:default-ui-name="Divers" />
       <groupuinames:template-group groupuinames:name="officorr" 
               groupuinames:default-ui-name="Correspondance d'affaires" />
       <groupuinames:template-group groupuinames:name="offimisc" 
               groupuinames:default-ui-name="Autres documents d'affaires" />
       <groupuinames:template-group groupuinames:name="personal" 
               groupuinames:default-ui-name="Correspondance privée et documents" />
       <groupuinames:template-group groupuinames:name="presnt" 
               groupuinames:default-ui-name="Présentations" />

</groupuinames:template-group-list>


Packages multilingues de modèles

Des packages multilingues de modèles sont également possibles. Ils nécessitent d'une part une légère modification de la ligne 13 du fichier Paths.xcu :

Paths.xcu [xml] <?xml version='1.0' encoding='UTF-8'?>

<oor:component-data oor:package="org.openoffice.Office"

   oor:name="Paths" xmlns:install="http://openoffice.org/2004/installation" 
   xmlns:oor="http://openoffice.org/2001/registry"
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<node oor:name="Paths">

<node oor:name="Template" oor:op="fuse"> <node oor:name="InternalPaths">

                               <node oor:name="%origin%/template/$(vlang)" oor:op="fuse"/>

</node> </node>

</node>

</oor:component-data>

et, d'autre part, la création de dossiers supplémentaires. Il s'agit des dossiers qui contiendront les modèles, sous-dossiers du dossier "template", et qui auront comme nom les codes ISO des langages fournis par les packs de langues d'OOo. Vous trouverez un deuxième package vide qui fournit l'infrastructure d'un tel package. Utilisez-le et placez les modèles en allemand dans le dossier "de", ceux en anglais dans le dossier "en-US", ceux en français dans le dossier "fr" etc. Des dossiers vides ne posent pas de problème. Chaque fichier de localisation (groupuinames.xml) doit désormais être placé dans le dossier correspondant au langage qu'il utilise et non plus directement dans le dossier "template" comme dans le cas d'un package monolingue.


Packages Autotexte

Tout ce qui a été expliqué ci-dessus par rapport aux pacakges de modèles s'applique également aux packages autotextes. Le fichier comporte alors, à la place d'une valeur pour le chemin du "Template", une valeur correspondant au chemin "AutoTexte". Un exemple d'un tel package se trouve ici. Cet exemple peut être utilisé pour fournir des fichiers autotexte. A l'heure actuelle, il n'existe aucune méthode d'export pour ces fichiers, il est donc aussi simple de copier les fichiers "*.bau" à la main qui ont été créés directement dans le package. De la même manière, on peut créer des packages d'autotextes localisés dans la langue de son choix: il suffit de placer les fichiers dans des sous-dossiers portant des noms conformes aux codes langue ISO, comme cela est indiqué dans le dossier "share/autotext". Contrairement aux packages de modèles, le chemin de l'autotexte ne nécessite pas d'inclure "$(vlang)" pour obtenir des packages multilingues puisque le composant gérant les autotextes implémente déjà en interne l'accès indépendamment de la langue.

Une remarque toutefois qui pose parfois des problèmes lors du déploiement de packages autotextes: l'interface graphique de l'utilisateur permet à l'heure actuelle d'enregistrer les autotextes dans des endroits arbitraires. Ceci est une erreur de fonctionnement ou bug qui devrai être corrigée dans des versions futures de OpenOffice.org. Tout changement appliqué à des autotextes présents dans un package seront perdus lors de la désinstallation du package. Il n'est pas prévu qu'on puisse changer le contenu des packages!

Paquetage de Gallery

Tout ce qui a été écrit ci-dessus s'applique également aux packages de Gallery. Le fichier Paths.xcu contient cette fois-ci une valeur relative au chemin du "Gallery" à place de celui des "Template". Un exemple d'un package Gallery se trouve ici. On peut ainsi le remplir avec les thèmes de Gallery qu'on souhaite. Comme cet aspect des choses n'est pas aussi facile à maîtriser que cela puisse paraître, le code a souvent tendance à provoquer des conflits de noms entre les différents fichiers de thème, il est déconseillé ne pas mettre en oeuvre des packages de Gallery tant que le bug référencé ici n'est pas résolu. En effet, les thèmes utilisent actuellement une valeur numérique et l'ajout d'un thème pourrait écraser un autre thème portant le même numéro.

Packages pour dictionaires et wordbooks utilisateurs

Ce travail n'est pas encore achevé parce qu'il nécessite une refonte de l'accès aux fichiers se rapportant aux outils linguistiques. Revenez de temps en temps pour voir où cela en est.

Personal tools