Inzetten van extensies

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

De databases worden weggeschreven naar bestanden .odb die overal kunnen worden opgeslagen. Dit zijn standaard archieven voor OOo. Het bestand content.xml beschrijft de gegevensbron en enkele attributen van de database.

De databases worden gedeclareerd in de registermap, in het bestand:

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

De naam van de database moet aanwezig zijn in de node "RegisteredNames".

<node oor:name="RegisteredNames">
   ...
   <node oor:name="the_database_name" oor:op="replace">
      <prop oor:name="Location" oor:type="xs:string">
       <value>file://de/locatie/van/de/database.odb</value>
      </prop>
      <prop oor:name="Name" oor:type="xs:string">
       <value>de_naam_van_de_database</value>
      </prop>
    </node>
    ...
</node>

Thema's voor de Galerij

Op dit moment lijkt het beheer van de thema's in OOo een beetje ingewikkeld.

Thema's worden opgeslagen in drie binaire bestanden, welke indeling is geërfd van StarOffice.

Deze bestanden hebben de achtervoegsels .sdg, .sdv en .thm.

Het bestand met .thm bevat, naast binaire gegevens, de naam van het thema, zoals opgegeven door de gebruiker.

De naam van elk bestand is in de vorm sgNNN.xxx waarbij NNN een getal is (hetzelfde voor alle drie de bestanden) en xxx het achtervoegsel.

Het lijkt erop dat de enige regel voor het kiezen van het getal is dat er in de doelmap slechts unieke bestandsnamen staan.

Deze implementatie is adequaat voor lokaal beheer van thema's, maar voldoet niet bij het uitwisselen van thema's tussen gebruikers. Inderdaad, de vraag is: hoe ontdekken we duplicaten tijdens de installatie?

de bestandsnaam gebruiken?: als de bestandsnaam, in een manier, onwillekeurig wordt gegeven gedurende de installatie, kan hetzelfde thema verschillende namen worden gegeven, afhankelijk van de geschiedenis van eerdere installaties op verschillende werkstations. Daarnaast zou OOo dezelfde naam hebben kunnen geven aan verschillende thema's die zijn gemaakt op verschillende werkstations.
de naam gebruiken die is opgeslagen in het bestand .thm?: als de naam te algemeen is, zoals "mensen", "gebeurtenissen" of "huizen", zou dezelfde naam kunnen worden gegeven aan verschillende thema's door verschillende gebruikers.

Dus, op het moment van installatie, is het belangrijk om de volgende gevallen in overweging te nemen:

het getal en de naam van het thema bestaan niet: het thema direct te installeren;
het getal bestaat al en de naam van het thema bestaat niet: zoeken naar een andere uniek getal;
de naam van het thema bestaat al: aan de gebruiker vragen of het bestaande thema moet worden overschreven, of dat het nieuwe moet worden hernoemd, of dat de installatie moet worden afgebroken.

Het is belangrijk systematisch te zoeken naar de naam van het thema in alle reeds bestaande thema's.

Macro's

nog te doen

Werkbalken

nog te doen

Het beheer van het pakket

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:

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