IT/Non-code extensions it
| Progetto "Estensioni" per OOo
Si prega di consultare le |
|---|
|
Categorie: Pagine: |
| Estensioni sul sito principale
Visualizza o modifica questo template.
|
Contents
Estensioni di OOo: Principi basilari
OpenOffice.org è stato progettato per essere estendibile sin dalle sue origini. All'inizio ogni estensione era qualcosa che conteneva del codice (es: scritto in Java o OOo Basic). Era integrata all'interno di OOo dalla nostra tecnologia a componenti chiamata UNO, per questo il file contenente un'estensione era chiamata un "package UNO". Nel frattempo le estensioni di OOo si sono diffuse anche tra gli utenti e così abbiamo pensato che era giunta l'ora di cambiare un po' la terminologia. La seguente documentazione prende in considerazione questa motivazione. Cerca di evitare il termine tecnico "pacchetto UNO", dove possibile, così come lo scopo di questa documentazione è di fornire una vista generale e una spiegazione dei concetti basilari. Se vuoi imparare di più circa UNO puoi dare un'occhiata al wiki di UNO o alle pagine WEB del progetto UDK.
Il concetto di estensione di OpenOffice.org non è limitato al codice, permette anche di installare altre cose come template, autotext, ecc. utilizzando file singoli. Qui di seguito è riportata una breve spiegazione sul funzionamento di base di questa funzionalità. Questa documentazione è rivolta a utenti finali avanzati, amministratori e sviluppatori alle prime armi. Tutte le informazioni fornite qui descrivono cosa si può trovare in OpenOffice.org versione 2.0.4 o superiore. Le differenze con le versioni precedenti non sono elencate sebbene è menzionato in modo esplicito quando qualcosa è stato aggiunto nella versione 2.0.4 per la prima volta.
Se non sei interessato per nulla allo sviluppo, allora potresti volere saltare la sezione relativa al codice delle estensioni.
La sezione che tratta della gestione della configurazione fornisce alcune idee di come potresti utilizzare le estensioni di OOo per scopi di personalizzazione del prodotto.
Se sei soltanto interessato a conoscere come creare le "estensioni prive di codice" senza imparare realmente come funzionano, allora puoi passare direttamente alla sezione "Impostazione dei percorsi". Dovresti però almeno leggere questa sezione introduttiva.
Per favore spedisci eventuali considerazioni (in inglese) a 
.
Nel caso hai accesso a questo wiki puoi certamente anche usare il tab "Discussion" presente in cima a questa pagina (meglio in inglese nella versione inglese della pagina).
Le estensioni di OOo sono più o meno archivi .ZIP con alcuni dati e metadati addizionali che descrivono il suo contenuto. Possono essere attivati utilizzando la funzionalità di gestione delle estensioni (Strumenti -> Gestione pacchetti) che permettono di installare le estensioni per l'utente corrente. Lo stesso risultato può essere ottenuto usando il programma a linea di comando "unopkg", che è posizionato nella directory dei programmi di OOo (in /usr/lib/openoffice/program sotto Debian e derivate). Questo programma permette anche di installare un'estensione per tutti gli utenti del sistema utilizzando il parametro "--shared".
Quando le estensioni sono installate il loro contenuto è copiato in una posizione privata ben definita all'interno dell'albero di directory di OOo: "share/uno_packages" (se l'installazione è globale) o "user/uno_packages" (se l'installazione è per il solo utente attuale). Con il termine "privata" si fa riferimento al fatto che non bisogna scrivere nessun codice che fa affidamento ad una particolare struttura di un'estensione scompressa, l'accesso ai file scompressi deve essere fatto tramite API definite che gestiscono questi dettagli per il chiamante. I file presente all'esterno della directory "uno_packages" non sono toccati per nulla, con la sola eccezione che può essere vista come un bug: le macro in Basic nelle estensioni di OOo hanno bisogno ancora di essere registrate in file xlc in una delle directory di "basic".
Le estensioni supportano l'installazione a caldo. Questo differisce, ad esempio da Firefox, dove occorre riavviare l'applicazione per avere le estensioni disponibili per l'uso. In OOo è possibile utilizzare le estensioni subito dopo l'installazione. C'è però una restrizione: è possibile che il codice di OOo tenga in cache quello che ha trovato al suo avvio o primo utilizzo di una determinata risorsa e quindi non vede un possibile cambiamento apportato dall'installazione dell'estensione. In questi casi è necessario per lo meno aprire una nuova finestra o documento di OOo o riavviare OOo. In molti casi questo comportamento può essere visto come un bug. Un esempio: in OOo 2.0.4 le estensioni dei template devono essere installate prima che la galleria sia usata per la prima volta.
Estensioni contenenti servizi di UNO (codice)
Se un'estensione di OOo contiene dei componenti di UNO scritti in Java, C++ o Python, allora questo componente deve pubblicare le sue funzionalità per diventare usabile per OOo. Nello sviluppo basato su UNO un insieme definito di funzionalità è chiamato "servizio". Un servizio è identificato e acceduto dai suoi nomi di servizi. Così un componente implementato come servizi deve dichiarare i propri identificativi al mondo. Attualmente tutti i componenti esportano una funzione che unopkg può chiamare per ottenere dal componente la scrittura delle informazioni necessarie all'interno di un file di registro del servizio che è creato e mantenuto all'interno della directory "uno_packages". Quando OOo utilizza il suo gestore dei servizi per vedere la disponibilità di servizi UNO non solo scansiona il registro dei servizi (services.rdb) nella sua directory di programma (contenente informazioni relative ai servizi interni), ma anche tutti i file di registro all'interno delle directory "uno_packages".
Certamente OOo può soltanto istanziare servizi di UNO dai loro nomi se li conosce. Questo è semplice per servizi che ne sostituiscono altri "interni" già esistenti, in questo caso OOo certamente già li conosce e li utilizza, ma la maggior parte dei componenti fornisce nuovi servizi e ci deve essere qualcosa d'altro che abilita OOo ad utilizzarli perché questi non sono di certo conosciuti durante la fase di compilazione. In questi casi i componenti di UNO devono fornire ulteriori informazioni a riguardo di quando un particolare servizio che implementano deve essere caricato. Le informazioni addizionali dei componenti sono passate a OOo mediante i file di configurazione.
Un esempio di questo è il componente di filtro di un documento dove l'informazione aggiuntiva che necessariamente deve essere fornita è (tra le altre cose) il tipo di file che il filtro è in grado di caricare. Un componente di filtro particolare può registrare sé stesso per essere in grado di caricare file nel formato Word Perfect. Così se un utente ha selezionato questo filtro per caricare un file, OOo troverà le informazioni registrate mediante ricerca di qualsiasi dato contenente il tipo di file desiderato (.WPS), istanzierà il componente del filtro tramite il suo nome di servizio trovato in queste informazioni e lo utilizzerà per caricare il file. Ogni filtro creato internamente ha la sua propria configurazione di dati e i filtri di documenti nelle estensioni forniscono le loro configurazioni che estendono i dati preinstallati. Così il gestore delle configurazioni deve essere capace di localizzarli e integrare il loro contenuto in una modalità conveniente.
Supporto delle estensione nel gestore di configurazione
Il gestore di configurazione ha un'abilità similare a quella del gestore dei servizi di UNO: può ricercare informazioni in un insieme di directory. La lista delle directory può essere espansa (mediante il configmanager.ini), in questo modo il gestore di configurazione può avere dei "livelli" addizionali. Ha anche l'abilità di utilizzare altre metodologie per aumentare il numero di "livelli", ma questo non viene trattato qui.
Le informazioni di configurazione sono sistemate in una struttura ad albero, i dati possono essere disposti in questa struttura ad ogni livello. Il gestore di configurazione esamina i livelli (directory) in un modo che le informazioni presente nei livelli "alti" rimpiazzano o estendono quelle presenti nei livelli "bassi", in maniera similare a quanto accade nei registri di ms-windows. Le informazioni sono rimpiazzate o estese in base alla tipologia associata alle informazioni; questo è spiegato in schemi di configurazione per i nostri percorsi impostati.
Di default OOo ha due livelli che già conosci: "share" (condiviso tra tutti) e "user" (utente). Il primo è contenuto nelle informazioni preinstallate, mentre il secondo contiene tutte le impostazioni che un utente particolare ha creato per sé stesso. I file di configurazione nelle estensioni di OOo creano due nuovi livelli: "share/uno_packages" e "user/uno_packages". Questi sono tra i livelli di default nel seguente palese ordine: "share" - "share/uno_packages" - "user/uno_packages" - "user".
Così un'estensione può estendere o cambiare la configurazione di OOo fornendo file xcu che sovrascrivono o estendono (uniscono) le impostazioni di configurazione di OOo. Può anche avere la sua propria impostazione di configurazione se provvede file do schema (xcs) per essa.
C'è un altro (abbastanza ovvio) caso d'uso per il concetto di livellamento del gestore di configurazione: sovrascrivere le impostazioni preinstallate di OOo sui livelli di tutti gli utenti. Un amministratore può personalizzare l'installazione di OOo nel suo utente, prendere i file xcu creati che contengono queste personalizzazioni e inserirle in una estensione che installa con il comando "unopkg add --shared" ogni volta che installa, reinstalla o aggiorna OOo. Non c'è bisogno di modificare i file xcu nel "share/registry" manualmente!
Il concetto dei livelli legato al registro dei servizi e alla configurazione sono i principi basilari che creano la potenzialità delle estensioni di OOo.
Impostazione dei percorsi
Alcune informazioni in OpenOffice.org non sono salvate nei file di configurazione xcu, ma in altre locazioni del file system; ad esempio: i template dei documenti (detti anche modelli), autotext, la galleria di immagini, ecc. Certamente anche questi contenuti devono essere installabili mediante l'uso di estensioni, così l'accesso a questi file deve avere un concetto a livelli che permette le estensioni di accedere a questi file. OOo contiene alcuni componenti che gestiscono l'accesso ai file. Noi potevamo estendere questi componenti con le stesse modalità con cui abbiamo esteso la gestione delle configurazioni o il gestore dei servizi (mediante abilitazione all'uso di livelli espliciti), ma abbiamo deciso di riutilizzare le capacità già disponibili del gestore di configurazione.
La locazione dove questi file sono da cercare è definita nella configurazione, nelle impostazioni di percorso. Ogni "percorso" in qualsiasi versione di OOo precedente alla 2.0.4 era o una singola stringa riportante la directory o una lista di stringhe riportante un elenco di directory (percorsi multipli). Sfortunatamente una simile lista non può essere soprascritta nei livelli alti, ma non estesa, così abbiamo bisogno di un nuovo schema di configurazione per i percorsi che utilizzano "insiemi" di stringhe al posto di "liste di stringhe" dato che gli insiemi possono essere ampliati.
Abbiamo iniziato ad utilizzare nuovi schemi per l'impostazione dei percorsi da OpenOffice.org 2.0.4. Abbiamo mantenuto lo schema precedente e i suoi dati per ragioni di compatibilità e abbiamo migrato le definizioni verso i nuovi dati. Il vecchio schema sarà rimosso in OpenOffice.org 3.0.
Nelle versioni recenti di OOo generalmente si possono vedere due o più directory nell'albero o negli alberi di OOo utilizzate per i template: "share" (condivisa tra tutti gli utenti), "user" (personale per ogni utente) e altre condivise. È possibile inoltre che ulteriori percorsi siano stati aggiunti dall'utente o dall'amministratore o dal gestore che ha creato la versione di OOo che state utilizzando.
Dando uno sguardo, in OOo 2.0.4, a: "Opzioni -> OpenOffice.org -> Percorsi", noterete che non tutti i componenti dei percorsi multipli sono visualizzati qui, soltanto le directory per gli elementi "percorsi utente" e "percorsi di scrittura" dal nuovo schema di configurazione. Normalmente in una installazione di default solo una directory è impostata per ogni percorso.
Opzioni -> OpenOffice.org -> Percorsi
Dall'immagine è possibile vedere i percorsi impostati di default dall'installazione di OOo o modificati dall'utente e/o amministratore del sistema. Quello che non si può vedere qui sono i percorsi impostati dall'installazione di un'estensione, poiché solo chi ha aggiunto tali percorsi deve poterli controllare e quindi poterli rimuovere.
Un miglioramento per gli utenti come per il codice di OOo permette all'utente di selezionare esplicitamente la directory di default dove vuole inserire i propri di dati mediante un radio button. Nella maggior parte dei casi è l'ultimo elemento.
Opzioni -> OpenOffice.org -> Percorsi -> Modifica
Templates Extensions
An extension for document templates is quite simple. It mainly contains just the templates, organized in directories that define template categories for the Document Templates Manager. Additionally a Paths.xcu file has to be provided that registers the extension in the set of document templates folders. This file contains the URL of the folder where the templates in the extension will be unpacked to. As this is something that isn't known the creation time of the extension a variable is used in the URL that is replaced by the extension manager when he copies the xcu file to the final location. The good thing is that this variable will always be the same for each templates extension so there is no need for the creator of such an extension to create by himself:
Paths.xcu
[xml]
<?xml version='1.0' encoding='UTF-8'?>
<oor:component-data oor:package="org.openoffice.Office"
oor:name="Paths" xmlns:install="http://openoffice.org/2004/installation" xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<node oor:name="Paths">
<node oor:name="Template" oor:op="fuse"> <node oor:name="InternalPaths"> <node oor:name="%origin%/template" oor:op="fuse"/> </node> </node>
</node> </oor:component-data>
If you compare this data with the data in the installation you can see that both files contain something in the "InternalPaths" that the configuration merges into its name container representing this element. Merging is caused by the "fuse" keyword that defines the operation "add me to the container or create a new container if it doesn't exist".
Example
Here is an "empty extension" for document templates that is ready to be filled with templates.
The zip container has a folder called “templates”. Any sub folder of it you create will appear as a template category in the OOo templates dialogs. Templates can be put into those sub folders. The title of the template will be taken from the document metadata (document properties) or from the file name if the title in the metadata is not set. If one of your sub folders has the same name as an existing template category the templates in the extension will be merged into this category by the OpenOffice.org templates component. Just try it out, it's simpler to do it than to explain it.
Localization of templates and template categories
The titles of the categories and templates can be taken from the file and folder names. These names can be localized and use any characters that the zip container and the target file systems(s) allow. It is possible that templates are installed on file systems that have problems with localized category (=folder) names so the Document Templates component allows to provide these localized names in a different file. The localized document template names can be stored in the document meta data (Document Properties) so they don't create a problem here.
The localization file is called "groupuinames.xml" and it is placed in the "templates" sub directory of the zip container. Its content is pretty straightforward. Here's an example for a german localization of some folders that use english file names:
groupuinames.xml
[xml]
<?xml version="1.0" encoding="UTF-8"?>
<groupuinames:template-group-list xmlns:groupuinames="http://openoffice.org/2006/groupuinames">
<groupuinames:template-group groupuinames:name="educate"
groupuinames:default-ui-name="Bildung" />
<groupuinames:template-group groupuinames:name="layout"
groupuinames:default-ui-name="Präsentationshintergründe" />
<groupuinames:template-group groupuinames:name="misc"
groupuinames:default-ui-name="Diverses" />
<groupuinames:template-group groupuinames:name="officorr"
groupuinames:default-ui-name="Geschäftliche Korrespondenz" />
<groupuinames:template-group groupuinames:name="offimisc"
groupuinames:default-ui-name="Sonstige geschäftliche Dokumente" />
<groupuinames:template-group groupuinames:name="personal"
groupuinames:default-ui-name="Private Korrespondenz und Dokumente" />
<groupuinames:template-group groupuinames:name="presnt"
groupuinames:default-ui-name="Präsentationen" />
</groupuinames:template-group-list>
Multi language templates extensions
Multi language templates extensions are also possible, they need a small modification in line no. 13 of the Paths.xcu file:
Paths.xcu
[xml]
<?xml version='1.0' encoding='UTF-8'?>
<oor:component-data oor:package="org.openoffice.Office" oor:name="Paths"
xmlns:install="http://openoffice.org/2004/installation" xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<node oor:name="Paths">
<node oor:name="Template" oor:op="fuse"> <node oor:name="InternalPaths">
<node oor:name="%origin%/template/$(vlang)" oor:op="fuse"/>
</node> </node>
</node>
</oor:component-data>
and additional directories need to be created be the "templates" folder that have the ISO language codes supported by the OOo language packs as their names. I have created a second empty extension file that provides the infrastructure. Take it and put german templates into the "de" folder, english ones into "en-US", french ones into "fr" etc. Empty folders are not a problem. The localization files (groupuinames.xml) now need to be placed into the language specific folders, not directly into the "templates" folder as in the single language extension.
If you create an extension this way you can always only use the templates of the current GUI language. This is caused by the "$(vlang)" variable in the path. A solution that allows to switch the template language independently is still missing.
AutoText Extensions
Everything told about templates extensions also applies to extensions for autotexts. The Paths.xcu of course now doesn't contain a value for the "Template" path but for the "AutoText" path. Again here is an example that can be filled with autotext files. As currently there is no exporter you can manually copy any ".bau" files you have created into the extension. And also creating extensions with localized autotexts works the same way: put the files into sub folders with names created from ISO language codes like you can see in the "share/autotext" folder. As distinct from the template path the autotext path doesn't need to contain "$(vlang)" for multi language extensions as the autotext management component implements the language dependent access internally.
There is a tricky part here when you deploy autotext extensions: currently the autotext GUI allows to save autotexts to arbitrary locations. This is a bug that needs to be fixed. Any changes applied to autotexts in an extension will get lost when the extension is deinstalled. Extension content is not meant to be changed directly!
Gallery Extensions
Everything told about templates extensions also applies to extensions for gallery items. The Paths.xcu of course now doesn't contain a value for the "Template" path but for the "Gallery" path. Again here is an example that can be filled with gallery themes you have created by yourself. As this is a little bit tricky and the gallery code currently is prone to name clashes of the theme files it is not recommended to use gallery extensions until the issue about these problems is fixed.
Another unsolved problem is the localization of gallery items.
Extensions for dictionaries and user wordbooks
This is work in progress as we have to redesign the file access of the linguistic tools. So stay tuned. You can refer to the issue that covers this.
