Difference between revisions of "Non-code extensions FR"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Packages UNO: Principes de base)
(Extensions conmportant des services UNO (code))
Line 14: Line 14:
 
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".
 
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 conmportant des services UNO (code) ==
+
== Extensions comportant des services UNO (code) ==
  
 
Si un package UNO comporte un composant écrit en Java, C++ ou Python, ce dernier doit rendre public 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”.
 
Si un package UNO comporte un composant écrit en Java, C++ ou Python, ce dernier doit rendre public 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”.

Revision as of 21:34, 11 October 2006

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 sujet 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 public 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 capanble 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éhà 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éhà 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 de OpenOffice.org présente é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 fort et flexible.

Personal tools