Difference between revisions of "Extension Deployment nl"

Revision as of 11:15, 15 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

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

Op dit moment is het belangrijk om het extensiebeheer, zoals dat wordt verschaft door OOo V2, nader te beschouwen.

Extensiebeheer kan pakketten importeren, inschakelen, uitschakelen en exporteren.

In het pakket kunt u één module opslaan die verschillende bibliotheken met macro's bevat.

U kunt aanvullende items voor het hoofdmenu, menu-items voor programma's en knoppen voor het activeren van de macro's beschrijven. De knoppen worden gegroepeerd in een nieuwe werkbalk.

Op dit moment kan extensiebeheer geen sjablonen, autoteksten en thema's voor de Galerij beheren.

Een pakket is een zip-archief.

De root van dit archief bevat een bestand addons.xcu waarvan de inhoud hier wordt beschreven.

Achtergrond

Dit project zou niet vanaf nul hoeven te beginnen. Enig werk is al verricht en hier zijn enkele niet-uitgebreide verwijzingen ernaar.

• Bernard Marcelly heeft een document geschreven genaamd "How to Distribute Macros with an Addon" dat macro's bevat die het zeer eenvoudig maken om een pakket te maken. Dit document is echter gedateerd. Voor OpenOffice 2.x zie de pagina Extensions_Packager

• Didier Dorange-Pattoret heeft een macro geschreven die eenvoudige installatie van thema's voor de Galerij mogelijk maakt.

• Laurent Godard heeft DicOOo geschreven wat woordenboeken op een werkstation installeert en dat nu wordt gedistribueerd met OOo V2.

• Philippe Allart heeft een eenvoudig bash-script geschreven wat voldoet aan de hieronder voorgestelde structuur en het programma van Didier Dorange-Pattoret gebruikt.

Specificatie van een configuratiepakket

Lay-out

Voorgesteld wordt dat het pakket wordt geïmplementeerd als een zip-archief om consistent te zijn met de technologische keuzes van het ontwikkelteam van OOo.

Dit archief zou één map voor elk object moeten bevatten.

Misschien zou het een goed idee zijn om een map "goodies" toe te voegen, wat het mogelijk zou maken objecten toe te voegen die niet direct betrokken zijn bij het configuratieproces, maar die voor eindgebruikers zeer handig zouden kunnen zijn.

De voorgestelde boom zou dus als volgt kunnen zijn:

1. /

1. • programma's die het mogelijk maken het pakket te installeren

1. • specificaties voor de installatie (locatie van sjablonen, ...)

1. 1. /autotexts/

1. 1. • autoteksten (.bau-bestanden) die moeten worden geïnstalleerd

1. 1. /packages/

1. 1. • pakketten (.zip-bestanden) die moeten worden geïnstalleerd

1. 1. /databases/

1. 1. • databases (.odb-bestanden) die moeten worden geïnstalleerd en mogelijke lokale gegevens

1. 1. /templates/

1. 1. • sjablonen die moeten worden geïnstalleerd

1. 1. /autocorr/

1. 1. • .dat-betanden die regels voor vervangingen en uitzonderingen bevatten

1. 1. /wordbooks/

1. 1. • woordenboeken die moeten worden geïnstalleerd

1. 1. /fonts/

1. 1. • lettertypen die moeten worden geïnstalleerd

1. 1. /gallery/

1. 1. • thema's die moeten worden geïnstalleerd

1. 1. /goodies/

Afhankelijkheden

De objecten in het pakket zijn niet volledig onafhankelijk van andere. Een macro kan bijvoorbeeld verwijzen naar opmaakprofielen die zijn opgenomen in een sjabloon en worden aangeroepen als het document wordt gemaakt.

Verder zouden enkele objecten in het pakket afhankelijk kunnen zijn van de eerdere installatie van andere objecten.

Dus zou het zeer handig zijn om alle typen afhankelijkheden te identificeren en hoe en waar ze worden vermeld.

Specificaties voor installatie

Op dit moment is het, voor het installatieproces, nodig te definiëren wat gespecificeerd zou moeten worden en hoe.

Het is zinloos om het wiel opnieuw uit te vinden en het lijkt een goed idee om de structuur van het bestand addons.xcu, dat wordt gebruikt door extensiebeheer, opnieuw te gebruiken.

Inderdaad, deze structuur is heel algemeen, op de manier dat het geen specifieke tags bevat. In feite is het slechts een set van twee kolomtabellen die paren eigenschappen/waarden bevatten. Deze tabellen worden beheerd in een boom, waar elke node een naam als een attribuut heeft.

Formeel ziet het XML Schema er als volgt uit:

XML Schema nog te beschrijven

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)