Extension Deployment ja

先立つ要因

拡張機能の配置は独立したタスクとして見なすべきはありません。 たしかに、多数のワークステーションに拡張機能を配置する必要があるとき、テンプレート、オートテキスト、ギャラリーテーマなどの配置も必要になるでしょう。それは、相対的に均整をとるために必要になるからです。実際、どうしても頻繁に同時に拡張機能を配置する必要があるなら、テンプレート、オートテキスト、ギャラリーテーマを配置する必要があります。

これは次のアプローチで提案する理由からです。

1 - マクロ、ツールバー、テンプレート、オートテキスト、ギャラリーテーマを含む、ただ一つの拡張機能操作で配置することを目的とするパッケージの構造を定義する

2 - このようなパッケージを作成目的の管理ツールのユーザーインターフェースを定義する

3 - ワークステーションにエンドユーザーがパッケージをインストール、または管理者が共有インストールツリーにインストールを可能にするユーザーインターフェース定義する

技術的なコンテキスト

パッケージの内容を決める前に、構成オブジェクトの実装による技術的な制約およびパッケージ内容の配置を指定するルールに気を止めておかなければいけません。

OOo レジストリ

OOo はレジストリシステムを備えています。

レジストリは "registry" ディレクトリに実装されており、shared インストールディレクトリと同じように user .openoffice.org2/user ディレクトリにもあります。

ユーザーが OOo の環境を変更したとき、レジストリが変更されるときもありますし、変更されないときもあります。インストール処理でレジストリの変更が交代の原因になる場合、直接 user の OOo ディレクトリを変更しないでください。この場合、OOo に変更を任せるべきで、インストール処理には OOo API を起動しなければいけません。

初期配置

オブジェクトの初期配置は次のファイルで指定されているようです。

$(insturl)/share/registry/schema/org/openoffice/Office/Common.xcs

大抵の構成ファイルでは頻繁に利用される配置は次のような変数で参照されています。

$(insturl)インストールディレクトリを示します。たとえば次のようになります。/opt/openoffice.org2.0

$(userurl) ユーザーの構成ディレクトリを示します。たとえば、次のようになります。/home/smith/.openoffice.org2/user

$(work) ユーザーのワーキングディレクトリを表します。

テンプレート

デフォルトのテンプレート配置は次の 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>

テンプレートはオフィスが作成するドキュメントオブジェクトにそっくりです。唯一の違いは接尾語 (拡張子) の二番目の文字が "d" から "t" に置き換わっており、テンプレートへのアクセスの仮想ツリーでは構成ファイルで宣言されたパスのセットが構築されています。

パス設定でユーザーが何かを変更したときから、パス設定は次のファイルに保存されます。 $(userurl)/registry/data/org/openoffice/Office/Common.xcu

オートテキスト

オートテキストのデフォルト配置は次の 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>

オートテキストはカテゴリに整理されています。ユーザーはカテゴリをほしいだけ作成できますし、書き込み権限のある構成ファイルで宣言されたディレクトリのうちの一つへの保存を要求できます。各々のカテゴリは実体が zip アーカイブである <category_name>.bau に組み込まれています。

それでも、カテゴリ名が特殊文字を含むときそれらの文字はファイル名から抜け落ちます。したがって、アーカイブに含まれる BlockList.xml ファイル内でカテゴリ名の検索をより堅固なものにできます。

データベース

.odb ファイルに含まれているデータベースはどこへでも保存できます。この .odb ファイルは標準的な OOo のアーカイブファイルです。content.xml ファイルはデータベースのデータソースと属性を記載しています。

データベースはレジストリディレクトリにある次のファイルで宣言されています。

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

データベース名は "RegisteredNames" ノードに表示されなければいけません。

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

ギャラリーテーマ

現在、OOo のギャラリーテーマ管理はすこしひねくれているようです。

テーマは三つのバイナリファイルに保存されており、それらのフォーマットは StarOffice から受け継がれたものです。

これらのファイルは .sdg、.sdv、.thm という接尾語を持ちます。

.thm ファイルはバイナリデータに混じってユーザーが付けたテーマ名を含みます。

各々のファイルは sgNNN.xxx の形式で名前が付けられており、NNN は数値 (三つのファイルで共通) で xxx は接尾語です。

明らかに、番号を選択するだけのルールはターゲットディレクトリでのユニークなファイル名を得るためです。

この実装はテーマのローカルでの管理には適したものです。しかし、ユーザー間でテーマを交換するときに満足できるものではありません。まったくそのとおりで、インストール中に重複を検出するにはどうするのでしょう？

ファイル名を使用するのでしょうか？

ファイル名とすると、見方によれば、インストール中にランダムにファイル名を付けます。別のワークステーションではインストール履歴により同じテーマが違った名称を付けられるかもしれません。さらに、OOo は別のワークステーションで作成された別のテーマに同じファイル名を付けるかもしれません。; .thm ファイルに保存された名前を使用するのでしょうか？: その名前が "people"、"events"、"houses" といった非常に一般的なものであれば別のユーザーが作成した別のテーマに同じ名前が付けられるかもしれません。

したがって、インストール時に次の場合を考慮するのが妥当です。

ファイル番号とテーマ名が存在しない

テーマは直接インストールされます

ファイル番号が存在しており、テーマ名は存在しない

別の識別番号を探す

テーマ名が存在する

存在するテーマを上書きするか、名称を変更して新しく作成するか、インストールを中断するかをユーザーに尋ねます。系統的に既存のすべてのテーマからテーマ名を探すことは重要なことです。

マクロ

to be completed

ツールバー

to be completed

パッケージマネージャ

現在のところ、OOo V2 で提供されているパッケージ管理について検討するのは重要なことです。

パッケージマネージャはインポート、有効化、無効化、パッケージのエクスポートが可能です。

パッケージにはマクロの複数のライブラリを含むモジュールを保存できます。

追加として、メインメニュー項目、ツールメニュー項目、マクロを実行するボタンを記述できます。ボタンは一つの新規ツールバーにグループ化されます。

今のところ、パッケージマネージャはテンプレート、オートテキスト、そしてギャラリーテーマも管理できません。

パッケージは zip アーカイブです。

このパッケージのルートディレクトリに here で説明されている addons.xcu ファイルを含みます。

拡張機能の背景

プロジェクトはゼロから始めるべきではありません。多くの仕事がすでに成し遂げられています。網羅的ではありませんがここに参考を挙げておきます。

• Bernard Marcelly により "How to Distribute Macros with an Addon" が書かれており、容易にパッケージを作成するマクロが含まれています。

• Didier Dorange-Pattoret により書かれたドキュメント macro はギャラリーを用意にインストール可能にします。

• Laurent Godard による DicOOo はワークステーションに辞書をインストールします。現在、これは OOo V2 と共に配布されています。

• Philippe Allart による simple bash script は次に提案する構造にファイルをコンパイルします。これは Didier Dorange-Pattoret のツールを使用しています。

レイアウト

OOo の開発チームの技術的選択に一貫して、パッケージは zip アーカイブとして組み込むことを提案します。

このアーカイブはオブジェクトの種類ごとに一つのディレクトリを含まなくてはいけません。

もしかすると、構成処理には直接関与しないがエンドユーザーに役立つオブジェクトを追加できる "goodies" ディレクトリを追加するのがいいアイデアかもしれません。

したがって、ディレクトリツリーを次のように提案します。

1. /
   • パッケージのインストールを可能にするツール
   • インストールの指定 (テンプレートの位置など)
   1. /autotexts/
      • インストールされるオートテキスト (.bau ファイル)
   2. /packages/
      • インストールされるパッケージ (.zip ファイル)
   3. /databases/
      • インストールされるデータベース (.odb ファイル) ローカルデータも可能
   4. /templates/
      • インストールされるテンプレート
   5. /autocorr/
      • 置換ルールと除外ルールを含む .dat ファイル
   6. /wordbooks/
      • インストールされる辞書
   7. /fonts/
      • インストールされるフォント
   8. /gallery/
      • インストールされるテーマ
   9. /goodies/

依存性

パッケージ中のオブジェクトは他のものと完全に独立しているわけではありません。たとえば、マクロはテンプレートに付属するスタイルを参照し、ドキュメントが作成されたときにそのマクロが呼び出されるかもしれません。

さらに、パッケージ中のオブジェクトは以前の他のオブジェクトインストールに依存しているかもしれません。

したがって、依存性をどこでどのように明確にするかということは、すべての種類の依存性を確認するのに有用でしょう。

インストールの詳細

現在のところ、インストール目的でなにが指示され、どのように支持するかを決めることが必要です。

新たに考案するのは無駄なことで、パッケージマネージャが利用する Addons.xcu ファイルの [1] を再利用するのがよいアイデアでしょう。

実際、特定のタグを含まないという意味ではこのファイル構造はとても一般的なものです。事実、ファイルの構造はプロパティ/値の組を含む一連の列数 2 のテーブルです。これらのテーブルはそれぞれのノードが属性としての名前を持つツリーに構成されています

形式的には XML スキーマは次のとおりです。

XML Schema to be described

現在、次のことが進行中です。

• ツリー構造を定義し、ノードに名称を付ける
• ノードそれぞれにテーブルの内容を定義する、すなわち、一連のプロパティ/値のペアーです

Contributors

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