Difference between revisions of "Extension Deployment"

Revision as of 16:49, 14 June 2014

Eerste overwegingen

Inzetten van extensies moet niet worden beschouwd als een zelfstandige taak. Inderdaad, als u extensies wilt inzetten op een aantal werkstations, dient u ook sjablonen, autoteksten, thema's voor de Galerij, enzovoort in te zetten, omdat u een relatieve homogeniteit zult willen behouden. In feite dient u extensies tegelijkertijd in te zetten als u sjablonen, autoteksten, thema's voor de Galerij inzet.

Om die reden wordt hier de volgende benadering te hanteren:

1 - de structuur van een pakket te definiëren die er op is gericht om extensies in één bewerking in te zetten, inclusief macro's en werkbalken, sjablonen, autoteksten en thema's voor de Galerij;

2 - de gebruikersinterface te definiëren voor een beheersprogramma waarvan het doel is om een dergelijk pakket te maken;

3 - de gebruikersinterface te definiëren voor een gebruikersprogramma dat de eindgebruiker in staat het pakket op het werkstation te installeren, of om de beheerder in staat te stellen het pakket in de gedeelde boom van de installatie te installeren.

Technische context

Vóór het specificeren van de inhoud van het pakket moeten we denken aan enkele technische beperkingen die ons worden opgelegd door de implementaties van de configuratieobjecten, en de regels voor het specificeren van hun locatie.

Het register van OOo

OOo heeft zijn eigen systeem voor het register.

Het register is geïmplementeerd in een map genaamd "registry", zowel in de gedeelde map voor de installatie als in de gebruikersmap .openoffice.org2/gebruikersmap.

Wanneer de gebruiker aanpassingen maakt in de omgeving van OOo wordt soms het register gewijzigd, soms niet. Het installatieproces zou niet direct de gebruikersmap van OOo moeten wijzigen als die wijziging een wijziging in het register zou veroorzaken. In dat geval zou het werk moeten worden verricht door OOo, dus het installatieproces zou de OOo API moeten activeren.

Standaard locaties

Standaard locaties van de objecten lijken te worden gespecificeerd in het bestand $(insturl)/share/registry/schema/org/openoffice/Office/Common.xcs

In de meeste configuratiebestanden wordt naar enkele veelgebruikte locaties verwezen variabelen:

$(insturl) verwijst naar de installatiemap, bijv. /opt/openoffice.org2.0

$(userurl) verwijst naar de map met de gebruikersconfiguratie, bijv. /home/smith/.openoffice.org2/user

$(work) staat voor de werkmap van de gebruiker.

Sjablonen

De standaard locaties van sjablonen worden gespecificeerd in het volgende gedeelte van XML:

<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>

Sjablonen zijn objecten die veel lijken op andere objecten die worden geproduceerd door het kantoorpakket. Het enige verschil bestaat uit de letter 't' in plaats van 'd' op de tweede plaats van het achtervoegsel en in de virtuele boom om toegang tot ze te krijgen, gebouwd vanuit de set met paden die zijn gedeclareerd in de configuratiebestanden.

Vanaf de tijd dat de gebruiker iets wijzigt in de paden worden zij opgeslagen in het bestand $(userurl)/registry/data/org/openoffice/Office/Common.xcu

Autoteksten

De standaard locatie van autoteksten wordt gespecificeerd in het volgende gedeelte van XML:

<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>

Autoteksten zijn georganiseerd in categorieën. De gebruiker kan net zoveel categorieën maken als hij wenst, en vragen om ze op te slaan in een van de locaties die zijn gedeclareerd in het configuratiebestand, vooropgesteld dat de gebruiker schrijfrechten heeft. Elke categorie wordt geïmplementeerd in een bestand genaamd <categorie_naam>.bau wat in feite een zip-archief is.

Niettegenstaande dat worden, als de naam van de categorie speciale tekens bevat, die stilzwijgend verwijderd uit de bestandsnaam. Dus is het meer robuust om de naam van de categorie op te zoeken in het bestand BlockList.xml dat is opgenomen in het archief.

Databases

The databases are described in .odb files which may be stored anywhere. this ones are standard OOo archive. The content.xml file describe the data source and some attributes of the database.

The databases are declared in the registry directory, in the file:

$(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>

Gallery's themes

At the moment, managment of themes in OOo seems a little bit twisted.

Themes are stored in three binary files, those format are inherited from StarOffice.

This files are suffixed with .sdg, .sdv and .thm.

The .thm file contains, among binary data, the name of the theme, as given by the user.

The name of each file is of the form sgNNN.xxx where NNN is a number (the same from the three files) and xxx the suffix.

Apparently, the only rule for choosing the number is to obtain unique file names in the target directory.

This implementation is adequate for a local managment of themes, but doesn't give satisfaction when exchanging themes between users. Indeed, the question is: how to detect duplicates during the installation?

using the file name? 

as the file name is, in a way, randomly given during installation, the same theme may be given different names depending on the history of previous installations on different workstations. Furthermore, OOo may have given the same filename to different themes created on different workstations.

using the name stored in the .thm file? 

if this name is too generic, as "people", "events" or "houses", the same name may be given to different themes created by different users.

Thus, at the installation time, it is pertinent to consider the following cases:

the number and the theme name doesn't exist

to install directly the theme;

the number already exists and the theme name doesn't exist

to search another discriminatory number;

the theme name already exists

to ask the user if the existing theme must be overwritten, or the new one renamed, or its installation aborted.

It is important to systematically search for the theme name in all already existing themes.

Macros

to be completed

Toolbars

to be completed

The package manager

At this stage, it is important to consider the package managment provided by OOo V2.

The package manager can import, enable, disable and export packages.

In the package you can store one module containing several libraries of macros.

You can describe additional main menu items, tools menu items and buttons for lauching the macros. The buttons are grouped in one new toolbar.

At the moment, the package manager can't manage templates, autotexts nor gallery themes.

A package is a zip archive.

The root of this archive contains an addons.xcu file whose contains is described here

Background

This project should not start from zero. Some work has already been done, and here is some non exhaustive reference to it.

• Bernard Marcelly has written a document called "How to Distribute Macros with an Addon" containing macros making it very easy to create a package. This document is outdated. For OpenOffice 2.x see page Extensions_Packager

• Didier Dorange-Pattoret has written a macro allowing easy installation of galleries.

• Laurent Godard has written DicOOo which installs dictionaries on a workstation, and which is now distributed with OOo V2.

• Philippe Allart has written a simple bash script which complies to the structure proposed below, and which use the tool of Didier Dorange-Pattoret

Specification of a configuration package

Layout

To be consistent with the technological choices of the developpers team of OOo, it is suggested that the package be implemented as a zip archive.

This archive should contains one directory for each type of object.

Perhaps, it would be a good idea to add a "goodies" directory, allowing to add objects not directly concerned by the configuration process, but which would be very usefull for end users.

Thus, the suggested tree could be as follows:

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/

Dependencies

The objects in the package are not fully independent of others. For instance, a macro may refer to styles coming with a template and be called when the document is created.

Furthermore, some objects in the package may depend on the previous installation of other objects.

Thus, it will be very useful to identify all types of dependencies, and how and where to express them.

Specifications for installation

At this stage, it is necessary to define what will be specified, and how it will be, for the installation process.

It is useless to re-invent the wheel, and it seems a good idea to reuse the structure of the addons.xcu file used by the package manager.

Indeed, this structure is very generic, in the sense that it doesn't contain specific tags. In fact, it's just a set of two columns tables containing properties/values pairs. Theses tables are organised in tree where each node have a name as an attribute.

Formally, the XML Schema is as follows:

XML Schema to be described

Now, the work stands in:

• to define the structure of the tree, and to give a name to each node;
• for each node, to define the content of the table, i.e. the set of properties/values pairs.

Contributors

--Pallart 16:34, 6 April 2006 (CEST)