XULの構造

まず、最初に XUL が Mozilla でどのように処理されるかについて見てみることにします。

XUL の処理

Mozilla における XUL の処理は、HTML などのコンテンツを処理する方法によく似ています。 HTML の場合、ブラウザのアドレス入力欄に HTML ページの URL が入力されると、ブラウザは Web サイトを見つけ出して、そのコンテンツをダウンロードします。 Mozilla の描画エンジンは、HTML のソースからコンテンツを取り出して文書ツリーの形に変換した後、そのツリーを画面上に表示可能なオブジェクトの集合に変換します。さらに、スタイルシート (CSS) や画像、その他の技術が表示の制御に利用されます。 XUL の場合も、これとほぼ同様の動作になります。

実際、Mozilla では、全ての文書型を同じ基本コードで処理しています。 HTML と XUL はもちろん、 SVG さえも同じです。これは HTML と XUL のいずれに対しても、スタイルを付けるために同じ CSS プロパティが利用できたり、多くの機能が双方で共有できるということを意味します。ただし、フォームのように HTML に特有な機能や、オーバーレイのように XUL に特有な機能も一部あります。 XUL と HTML は同じ方法で処理されるため、どちらのファイルも「利用者のウェブページ」、「拡張機能」、「スタンドアローンな XULRunner 用のアプリケーション」から読み込むことが可能です。

リモートから読み込まれるコンテンツ (例えばhttps://localhost/~username/) は、文書の型を問わず、セキュリティ上の理由から実行可能な命令が制限されます。 HTML や XUL はもちろん、他のタイプの文書も含めたすべてが制限の対象になります。このため、Mozilla はローカルにコンテンツをインストールする手段と、インストールされたファイルを chrome システムの一部として登録する手段を提供しています。ファイルは、ローカルにインストールして「chrome://」で始まる chrome URL と呼ばれる特殊な URL から呼び出すことによってのみ、制限されている命令の実行が許可されるようになります。 chrome URL を用いてファイルにアクセスした場合、ファイルはローカルファイルや設定情報、ブックマークへのアクセスを含めた特権的な操作を実行可能な高い権限を得ます。言うまでもないことですが、ウェブページは、デジタル証明書による署名がされていて、かつ利用者がそれらの命令を実行するための許可を与えたものでもないかぎり、こういった特権は取得できません。【訳注: スクリプトに署名して特権を与える方法】

chrome パッケージの登録は Firefox の拡張機能がブラウザに機能を追加するための方法です。拡張機能は複数の XULファイル、Javascript、スタイルシート、画像を1つのファイルにまとめたファイルです。このファイルは ZIP ユーティリティを用いて作ることが出来ます。利用者がそのファイルをダウンロードしたとき、それは利用者のマシンにインストールされることになります。拡張機能は、オーバーレイと呼ばれる XUL 特有の機能を使用して、拡張機能の中の XUL と、ブラウザの持つ XUL を結合することにより、ブラウザの中に組み込まれます。利用者からは、この挙動は、拡張機能がブラウザを修正しているように見えるかもしれません。しかし、実際には、コードは完全に分けられているため、拡張機能は簡単にアンインストールすることが可能になっています。もちろん、登録されたパッケージが、必ずオーバーレイを使用しなければならないわけではありません。オーバーレイを使わない場合、メインのブラウザインターフェースからはアクセスすることは出来ませんが、 chrome URL がわかっている場合、その URL を経由してアクセスすることが可能です。

スタンドアローンな XUL アプリケーションにも、同様の方法で XUL コードを含めることができます。もちろん同様とはいっても、アプリケーションのための XUL は、拡張機能のように別々にインストールされるのではなく、アプリケーションの一部としてインストールされることになるはずです。どちらにしても、この XUL コードも、アプリケーションが UI を表示できるように chrome システムに登録されることになります。

実は Mozilla ブラウザ自身が、XUL ファイル、JavaScript、スタイルシートを含んだパッケージの集合体であることは注目に値すると思います。ブラウザは、ほとんどの拡張機能より、ずっと大きく洗練されたものではありますが、ブラウザのファイルも、chrome URL を通してアクセスされることによって強化された権限を持ち、他のパッケージと同様に動作します。 Firefox や Thunderbird をはじめとする他の様々なコンポーネントはすべて XUL で書かれていて、どれも chrome URL からアクセスすることが可能です。

chrome URL は常に「chrome://」で始まります。「https://」 URL が常にリモートの Web サイトを指し、「file://」 URL が常にローカルファイルを指すのと同様に、「chrome://」 URL は、常にインストールされているパッケージや拡張機能を指しています。次のセクションでは chrome URL の記法についてより詳しく見ていきます。 chrome URL を通してコンテンツへアクセスする場合、他の URL では得られない、上で述べた様な特権が与えられることに特に注意してください。例えば、HTTP URL には何ら特権が与えられることはなく、ローカルファイルを読ませようとしたりするとエラーが生じます。一方、chrome URL から読み込まれたファイルからは、制約無しにファイルを読むことが可能です。

この違いは重要です。つまり、利用者のブックマークを読み出すといった、Web ページのコンテンツからはできないことが、いくつか存在します。この違いは表示されているコンテンツの種類には関係なく、URL の種類にのみ依存します。 HTML と XUL のどちらであっても、ウェブサイトに置かれた場合は、特別の権限が付与されることはありません。一方 chrome URL により読み込まれた場合、HTML と XUL は、両方とも強化された権限を得ることになります。

XUL をウェブサイトで利用するには、 HTML ファイルのときと同様に、単にウェブサイトに置いて、その URL をブラウザで読み込みます。ウェブサーバ側では、 XUL ファイルのコンテントタイプを「application/vnd.mozilla.xul+xml」として送信する様に設定しておく必要があります。(例えば PHP を利用する場合は、「header('Content-type: application/vnd.mozilla.xul+xml');」のようにします)。このコンテントタイプによって Mozilla は HTML か XUL かの違いを識別します。 Mozilla はファイルシステムから読み出す場合を除いてファイル名の拡張子を利用しません。とはいっても、全ての XUL ファイルの拡張子は .xul にしておくべきだと思います。これによって、あなたのマシンにある XUL ファイルを、ブラウザから開いたり、ファイルマネージャーでダブルクリックすることにより読み出すことができるようになるからです。

リモートから XUL を読み込む場合には、出来ることに大きな制約がかけられていることを覚えておいてください。

HTML、XML と XUL 文書型について

Mozilla は、機能の大部分が共有されているにもかかわらず、HTML と XUL のために明確に違った種類の文書オブジェクト (DOM) を使っています。 Mozilla には、3 種類の主要な文書「HTML」「XML」「XUL」があります。当然ですが、HTML 文書オブジェクトは HTML 文書のために使われており、XUL 文書オブジェクトは XUL 文書のために使われています。 XML 文書オブジェクトは、それ以外のタイプの XML 文書に使われています。 XUL も XML であるため、XUL 文書オブジェクトは、汎用的な XML 文書オブジェクトのサブタイプになります。これらの機能面での違いはわずかです。例えば HTML ページのフォームコントロールには「document.forms」プロパティからアクセス可能ですが、XUL には HTML の意味でのフォームというものがないため、このプロパティは XUL 文書には存在しません。逆に、オーバーレイやテンプレートといった XUL 特有の機能は XUL 文書でしか利用できません。

この文書型の違いは重要です。 XUL の多くの機能は、文書型に依存しないため HTML や XML 文書で利用することが可能です。ただし、それ以外の機能では適切な文書型が必要になります。例えば、 XUL のレイアウト型の要素は XUL 文書型には機能的に依存していないため、他の文書型でも使うことが可能です。

上で述べた点を要約します。

Mozilla では HTML と XUL のいずれに対しても同じエンジンを使用してレンダリングを実行し、外観の指定には CSS が用いられます。
XUL は「リモートサイト」、「ローカルファイルシステム」、あるいは「パッケージとしてインストールされた後に chrome URL からアクセスされる」ことによって読み込まれます。最後のものがブラウザの拡張機能が行う動作になります。
chrome URL を用いれば、インストールされたパッケージにアクセスすることができ、それらを強い権限を与えて開くことが可能です。
HTML 、XML 、 XUL はそれぞれ異なる文書型です。いくつかの機能はどの文書型でも利用できますが、いくつかの機能は特定の文書型に固有のものになります。

ここから数セクションに渡って Mozilla にインストールできる chrome パッケージの基本的な構造について説明していきます。ですが、簡単なアプリケーションの作成に早くとりかかりたいのであれば、「ウィンドウを作成する」までスキップして、このセクションの残りは後回しにしてもかまいません。

パッケージの編成

Mozilla は、コンポーネントを、必要ならばいくつでも初期インストールに含めることが可能な構成になっています。また、個々の拡張は別々の chrome URL を持つコンポーネントになります。さらに、インストールされる個々のスキンやロケールについても、1 つのコンポーネントが含まれることになります。これらのコンポーネント、あるいはパッケージのそれぞれが、ユーザーインターフェイスを記述した一連のファイルで構成されています。例えば、メッセンジャーコンポーネントには、メールメッセージ一覧ウィンドウ、編集ウィンドウ、アドレス帳ダイアログについての記述が含まれています。

Mozilla に付属して提供されるパッケージは、 Mozilla をインストールしたディレクトリにある chrome ディレクトリの下に置かれています。 Mozilla のブラウザやメールクライアント、その他アプリケーションで利用されるユーザインターフェイスを記述するファイルは、全て chrome ディレクトリの下に置かれます。通常は、利用者が個別にインストールした拡張機能 (利用者ごとの拡張機能のためのディレクトリにインストールされます) を除いて、アプリケーションの XUL ファイルはこのディレクトリに置かれます。単純にファイルを「chrome」ディレクトリにコピーするだけで、特権を与えたり、chrome URL からアクセス可能にはなりません。特権を得るためには、マニフェストファイルを作成して、chrome ディレクトリに置いてください。このファイルは、1 行が長めですが 2 行程度の記述ですむため、簡単に作成することができます。このファイルは、chrome URL と、XUL ファイルが置かれているディスク上のディレクトリパスとの対応付けのために使われます。このファイルを作る方法の詳細は、後のセクションで説明します。

chrom URL を通してアクセス可能なコンテンツを作成する唯一の方法は、次の数セクションで説明するように、パッケージを作成することになります。なお、ディレクトリ名を「chrome」としたのは、Mozilla に付属する chrome パッケージを保持するディレクトリ名としてふさわしいと思われたためです。

更に紛らわしいのですが、chrome という単語が現れる場所が、他にも 2 つあります。 1 つは「-chrome」コマンドライン引数で、もう 1 つは window.open() 関数の chrome 修飾子です。いずれにおいても特権が付与されるわけではありません。これらはメニューバーやツールバーなどの、ブラウザ UI (ユーザーインターフェイス) を持たない、トップレベルの新規ウィンドウを開くためのものです。この機能は、もっと複雑な XUL アプリケーションでは頻繁に利用されます。 (ダイアログボックスの周囲からはブラウザ UI は消したいはずです)。

パッケージのファイルは、通常 1 つの JAR ファイルにまとめられます。 JAR ファイルは、ZIP ユーティリティで作成したり、中身を調べたりすることが可能です。例えば、パッケージの基本的な構造を確認するために、 Mozilla の chrome ディレクトリ内の JAR ファイルをいくつか開いてみることができます。パッケージは、通常 JAR ファイルにまとめられますが、ディレクトリ内に展開された形で置いて、アクセスすることも可能です。通常、パッケージをそのような形で配布することは無いと思いますが、開発時には、再パッケージや再インストールをせずに、ファイルを直接編集するだけで XUL ファイルを再読み込みさせることができるため便利です。

ただし、デフォルトでは、Mozilla は、アプリケーションのセッションが再度呼び出されたときのために、アプリケーションの XUL ファイルやスクリプトを解析したあと、コンパイル前のものをキャッシュとしてメモリに保存します。このことは、処理性能の改善に効果がありますが、 XUL のソースファイルを変更しても、再読み込みされなくなってしまう副作用が発生します。開発作業の便宜のために、この機構を停止するためには、設定の「nglayout.debug.disable_xul_cache」を変更する必要があります。 Firefox では、アドレス入力欄に「about:config」と入力して、上記の値を「true」に設定するか、user.js 設定ファイルを手で編集して、以下の行を追加します。

pref("nglayout.debug.disable_xul_cache", true);

chrome パッケージは、通常３つの異なる「パート」からなりますが、どのパートも必須ではありません。各パートはそれぞれ異なるディレクトリ下に格納されます。その 3 つとは、以下で述べる「コンテント」、「スキン」、「ロケール」です。パッケージには、1 つかまたは複数のスキンやロケールを提供していて、利用者が、それをインストールすることによって、元からあるものを置き換えるようなものもあります。付け加えれば、そのパッケージは、それぞれ異なる chrome URL でアクセスする、いくつかの異なるアプリケーションを含んでいるかもしれません。以上のように、このパッケージシステムは、必要ならば、どんなパートでも含めることが可能である一方、他国の言語のテキストといった、他のパートを一部だけ別途ダウンロードすることも可能であるといった具合いに十分な柔軟性があります。

3 種類の chrome パッケージについて以下に説明します。

コンテント - ウィンドウとスクリプト
ウィンドウとそれに含まれるユーザインターフェイス要素の定義です。これらは拡張子 xul を持つ XUL ファイルに収められます。コンテントパッケージには複数の XUL ファイルが含まれることがありますが、メインウィンドウのファイル名はパッケージ名と同じにする必要があります。例えば editor パッケージには editor.xul というファイルが含まれます。スクリプトは、別ファイルに分けて、 XUL ファイルと同じ場所に置いておきます。
スキン - スタイルシートと画像、その他テーマ専用のファイル
スタイルシートはウィンドウの外観の詳細を記述するもので、アプリケーションのスキン (テーマ) の変更を容易にするために XUL ファイルとは分けて収められます。また、画像もここに収められます。
ロケール - ロケール専用のファイル
ウィンドウに表示されるあらゆるテキストが、ここに分けて収められます。これにより、利用者が自身の言語用セットを持つことが可能になります。

コンテントパッケージ

JAR ファイルは、ファイル名から内容を推測することはできるものの、実際に中身を見てみないと、確かにそうだとは言えないと思いますので、実際に Firefox に含まれているブラウザパッケージを例に使って見てみることにします。このパッケージファイルである browser.jar を展開した場合、以下のようなディレクトリ階層になっていることが確認できるはずです。

content
   browser
      browser.xul
      browser.js
      -- その他のブラウザ用 XUL や JavaScript ファイル --
      bookmarks
         -- ブックマークファイル --
      preferences
         -- 設定ファイル --
.
.
.

まず、トップレベルのディレクトリ名が content であることから、これがコンテントパッケージであることが簡単にわかります。このディレクトリ名は、もしスキンであれば、通常 skin となり、ロケールであれば、通常 locale になります。この命名規則は絶対ではないのですが、パッケージのパートを判り易くするために、一般的な慣習として使われています。パッケージによっては、コンテント、スキン、ロケールの全てを持っているものもあります。その場合は、各パートごとのサブディレクトリが全て作成されているのが確認できるはずです。例えば、Chatzilla が、この形式で配布されています。

次に、content/browser ディレクトリには、拡張子が .xul や、 .js のファイルが多数含まれています。このうち、XUL ファイルは、拡張子 .xul を持つものです。また、拡張子が .js のものは JavaScript ファイルで、ウィンドウが提供する機能を実装したスクリプトが置かれています。多くの XUL ファイルは、そのファイルに関連付けられたスクリプトファイルを持っており、また、そのうちのいくつかは複数のスクリプトファイルを持っています。

上のリストには 2 つのファイルが含まれています。もちろん、これ以外のファイルもあるのですが、簡単にするため省略しています。この、browser.xul は、メインのブラウザウィンドウを記述する XUL ファイルになります。コンテントパッケージのメインウィンドウは、パッケージ名に拡張子 .xulを付加した名前にする必要があります。したがって、この場合はパッケージ名が「browser」なので、「browser.xul」は必ず存在することが期待できます。また、いくつかのそれ以外の XUL ファイルは、別のウィンドウの記述に使われています。例えば、pageInfo.xul ファイルは、「ページの情報」ダイアログの記述になります。

既存の多くのパッケージには、パッケージ情報、作者、使用するオーバーレイを記述した contents.rdf が含まれています。しかし、このファイルを使う方法は旧式になり、簡単な機構に変更されています。新しい方法は、上述のマニフェストファイルによるもので、このファイルは、chrome ディレクトリ内で .manifest という拡張子を持ったファイルとして見つかるはずです。具体的には、browser.manifest ファイルが、ブラウザパッケージについての記述に使用されることになります。

また、bookmarks や preferences といった、いくつかのサブディレクトリは、ブラウザコンポーネントの付加的な部分と対応しています。これらが別ディレクトリに置かれているのは、単にファイルの置き場所を整理しておくためです。

スキンまたはテーマ

Mozilla の内部コードから「スキン」と呼ばれているものと、ユーザインターフェイスから「テーマ」と呼ばれているものは、どちらも同じものを指しています。例えば、classic.jar ファイルは、Firefox と一緒に配布されるデフォルトのテーマが記述されているファイルです。このファイルはコンテントパッケージと類似の構造を持っています。以下に、classic.jar ファイルを調べた結果を示します。

skin
   classic
      browser
         browser.css
         -- その他のブラウザスキンファイル --
      global
         -- グローバルスキンファイル --
.
.
.

このディレクトリ構造も、必須ではないものの便利に使うことができます。極端なことをいえば、すべてのファイルをトップディレクトリに置いて、サブディレクトリを使わないような構造でもかまいませんが、大きなアプリケーションでは、ファイルをコンポーネント単位でサブディレクトリに分けておくのが普通です。上記の例では、ブラウザのテーマに関するファイルのためのディレクトリと、グローバルなテーマに関するファイルのためのディレクトリが存在しています。 global ディレクトリには、すべてのパッケージに適用可能な、汎用のスキンファイルが含まれています。これらのファイルは、独自に開発されたスタンドアローンなアプリケーションも含めて、すべてのコンポーネントに適用されます。また、global の部分には、共通の XUL ウィジェットすべての外観が定義されているのに対して、それ以外のディレクトリは、そのディレクトリ名が示すアプリケーションに限定したファイルが置かれています。なお、Firefox では、グローバルとブラウザのテーマファイルを、1 つのアーカイブにまとめていますが、それらを別のアーカイブに分けておくことも可能です。

スキンは、CSS ファイルとたくさんの画像ファイルから構成されていて、インターフェイスの外観を定義するために使用されます。 browser.css ファイルは、browser.xul から利用されて、ブラウザインターフェイスの様々な部分の外観を定義するスタイルが含まれています。ここでも、browser.css ファイルの名前が、パッケージ名と同じであることに注意してください。機能面での変更を行うことなく、この CSS ファイルを変更するだけで、ウィンドウの外観を調整することが可能です。 XUL の部分は元のものを残し、スキンの部分だけを単独で変更することで、新しいテーマを作成することができます。

ロケール

ファイル en-US.jar は、各コンポーネントに対する言語情報が記述されており、このファイルの場合は、米国英語 (US English) 用になります。スキンと同様に、それぞれ言語ファイルには、対象とするパッケージで使用するテキスト情報を特定の言語に翻訳したものが含まれています。ロケールのファイル構造については、他のパッケージとほとんど同じであるため、ここでは内容のリストは省略します。

ローカライズ (地域化) されたテキスト情報は、パッケージ中の DTD ファイルと、プロパティファイルの 2 種類のファイルに収められています。 DTD ファイルは、拡張子が .dtd のファイルで、このファイルには、ウィンドウで使用される個々のテキストの実体 (entity) 宣言が含まれています。例えば、browser.dtd ファイルは、ブラウザの各メニューにある操作項目テキストの実体宣言を含んでいます。また、各メニュー操作に対応するキーボードショートカットも、言語によって異なる可能性があるため、この DTD ファイルで定義されています。 DTD ファイルは、XUL ファイルから参照されますが、通常、各 XUL ファイルから参照する DTD ファイルは 1 つだけにします。また、パッケージの locale パートには、プロパティファイルも含まれています。このファイルも、 DTD ファイルと類似していますが、スクリプトから利用される点が異なります。例えば、browser.properties には、ブラウザで利用されるローカライズされた文字列がいくつか含まれています。

訳注: 実体宣言は、XML の仕様の 1 つで、特定の文字(列)を「実体」として XML の文書型定義 (DTD) の中で宣言し、各 XML ファイルでは、割り当てたキーワードを元に参照するようにすることで、用語 (言語) の変更の影響が個々の XML 文書に及ばないようにする仕組みです。

上記の構造によって、別の言語用の新しいロケールを追加するだけで、 Mozilla やコンポーネントをその言語に対応させることができます。このとき、XUL のコードには、何も変更を加える必要はありません。さらに、他の開発者が、あなたが作成したコンテントパートに適用するためのスキンやロケールを、別のパッケージとして提供することも可能です。このとき、新しいテーマや言語をサポートを提供するために元のパッケージに変更を加える必要はありません。

訳注:上記は、元のパッケージが、ロケールを作成できるように XUL ファイルには直接文字列を書き込まず、実体参照を使っている場合の話です。もし、XUL ファイルに、直接文字列が埋め込まれている場合は、まずそれらの文字列を洗い出して、実体宣言にまとめ、XUL ファイルは実体参照を使うように変更するといった作業が必要になります。

その他のパッケージ

Mozilla の chrome ディレクトリには、ツールキット (toolkit)、またはグローバル (global) と呼ばれる特別なパッケージが存在します。 global ディレクトリについては、スキンの説明のところで触れましたが、 toolkit.jar ファイルには、それに対応するコンテントパート、つまり、グローバルなダイアログなどの定義が含まれています。また、テキスト入力欄やボタンといった、共通して利用される様々なウィジェットに対するデフォルトの外観や機能も定義されています。このため、スキンパッケージの global パートに置かれたファイルは、すべての XUL インターフェイス要素に対するデフォルトの外観に関する記述を含むことになります。なお、このツールキットパッケージは、すべての XUL アプリケーションから使用されます。

パッケージを追加する

Mozilla と同時にインストールされるパッケージは、chrome ディレクトリに置かれますが、必ずしも、そこに置く必要はありません。追加でパッケージをインストールするとき、パッケージファイルは、マニフェストファイルが指してさえいれば、ディスク上のどこであってもかまいません。便宜上、新しいパッケージは、chrome ディレクトリ内に配置するのが普通ですが、別のディレクトリであればもちろん、(Windows の場合だと、UNC パスによってアクセス可能な) ローカルネットワーク上ですら、どこに置いても同じように働きます。ただし、(ローカルファイルシステム上にマウントされている場合を除いて) リモートサイトに置くことはできません。

XUL アプリケーションにパッケージを追加するときにインストール先として使用する chrome ディレクトリは 2 つあります。 1 つはアプリケーションがインストールされたのと同じ場所で、もう 1 つは利用者のプロフィールを格納する場所の中になります。前者にインストールされたパッケージは、すべての利用者で共有することが許可され、後者にインストールされたパッケージは、固有、または特定の利用者に対してのみ許可されます。拡張機能専用のディレクトリにインストールされた拡張機能も、通常はインストールした利用者に固有になります。起動時に、これらの両方の chrome ディレクトリに置かれたすべてのマニフェストファイルは、インストールされているパッケージを確認するために調べられます。

次のセクションでは、chrome URL を使用して、chrome パッケージを参照する方法について見ていきます。

« 前のページ次のページ »

Interwiki Language Links