Difference between revisions of "Non-code extensions FR"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Les Chemins)
(Extensions comportant des services UNO (code))
Line 18: Line 18:
 
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”.
  
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.  
+
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é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.
+
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 ==
 
== Support des Packages dans le Gestionnaire de Configuration ==

Revision as of 23:07, 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 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 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.

Les Chemins

Quelques données d'OpenOffice.org ne sont pas stockées dans les fichiers de configuration xcu mais autre part 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 y ajouter quelque chose. Aussi l'accès à ces fichiers doit respecter un principe de couches également. 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 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.

Personal tools