XPCOM: 第3回: XPCOMのセットアップ

XPCOM開発環境の構築

Rick ParrishがWindowsまたはLinux用のMozillaを作成するプロセスを詳しく解説します。加えて、アプリケーションでXPCOMを使えるようにすることを含めた (ただしそれに限定されない) XPCOMのセットアップに必要な他の事柄や、コンポーネント、サービス、およびカテゴリー・マネージャーの基本的な働きを理解するために必要な事柄も網羅します。

Rick Parrish (rfmobile@swbell.net), Independent consultant

閉じる [x]

Rick Parrish氏は、高校生の頃からコンピューター・サイエンスに興味を持ち始めましたが、エレクトロニクスにはもっと早くから関心を持っていました。最初は電気工学の教育を受けていましたが、ソフトウェアの場合は、ハードウェアとは違って、塩化第二鉄溶液の嫌な臭いをかぐ必要はなく、ただ設計変更のためだけに指にやけどをする危険を冒す必要もないことに気付きました。Rickは、長い間C/C++ のプログラミングに携わってきましたが、VBとDelphi(Pascal) による仕事も多く、アセンブリー言語の仕事も少なくありません。今でも、熱いハンダを必要とする1つか2つのプロジェクトに何とか携わっています。Windows 2000は素晴らしいけれど、Ogg Vorbisもクールだし、IPTableのあるLinux 2.4カーネルは本当にタフだ! というのが彼の現在の持論です。現在の関心事は、ソフトウェア・モデリング設計用のツールを開発するオープン・ソース・プロジェクトを始めることです。Rickの連絡先は、 rfmobile@swbell.net です。



2001年 3月 01日

XPCOMを使うアプリケーションや、XPCOMコンポーネント自身の実際の作成作業に入る前に、適切な開発環境が必要になります。すべてのツールが適切な場所に存在し、正常に機能していることを確認する最良の方法は、Mozillaブラウザーを作成してみることです。

lizardの作成

Mozillaは "the lizard" としても知られていますが、XPCOMとXPConnectの上に作成されるため、これを作成することは、ライブラリーと一群の有用なXPCOMコンポーネントを手に入れることに相当します。そのうちのいくつかは、ブラウザーと共存させなくても構わないものです。www.mozilla.orgにアクセスし、ソース・コードと補足的な開発ツールをダウンロードし、全体をビルドしてください。Mozillaコードでは、ビルドするときに、コンパイラー固有のプロジェクト・ファイルではなく、汎用のmakeファイル、シェル・スクリプト、およびPerlスクリプトを使います。この「最小公分母」的なアプローチは、異なるプラットフォーム上でも同じ方法で同じコードを確実にビルドできるようにする唯一の方法です。

このアプローチでは、大量のディスク・スペースを消費するので注意してください。これを執筆している時点で、ソース・コードのtarファイルを解凍するだけで、28567ものファイルが出現し、160,975,003バイトを消費します。NTFSではファイル・システムが効率的ではないため、この作業に244,293,632バイトもの実ディスク・スペースが使われます。ソース・コードだけ でこのような状態です!リリース・ビルド後のソース・コードとバイナリー・ファイルになると、450メガバイトに届くかというところでしょう。しかもここには、他のツールのためのディスク・スペースや、デバッグ・ビルド作成のためのスペースが含まれていないのです。

上に戻る

CVS

異なるプラットフォームで同じソース・コードをコンパイルできるマジックを実現できる理由の1つは、非常に多くのプラットフォームへ移植されているいくつかのツールに可用性があることです。そのようなツールには、gmake、CVS、およびinfozip等があります。

CVS -- Concurrent Versioning Systemはシンプルですが、よく使われていてテストを重ねられた、マルチユーザーのソース制御およびバージョン付けシステムです。これを使うことにより、たくさんのプログラマーが大規模なプロジェクトで協調できます。機能的には、Microsoft社のSourceSafeツールと比較できます。RCSは、同様な別のUNIX専用プログラムです。

CVSは、バグやパッチを追跡するためのツールで、いわばMozillaの兵器庫に蓄えられているえり抜きの武器といえます。CVSを使うときにもっとも興味深い点は、ソース・コードに対する変更が皆に適用できるようになったら、すぐに最新の変更を増分的にダウンロードしてソース・コードに適用する機能でしょう。次のtarファイルのリリースを待つことをいとわないのであれば、CVSについてはスキップしても構いません。

CVSサーバーではパスワードが必要です。モジュール所有者としての信頼性を得て、書き込みアクセス権限を持つユーザーとして指名されたのでない限り、汎用の読み取り専用アカウントを使うことになります。ただし、何も貢献することができないということではまったくありません。その場合は、直接モジュール所有者に対してパッチをサブミットして検討してもらうことになります。

上に戻る

Windows環境のセットアップ

ここでは、MS Windowsについてのステップをさっとたどります。

  1. 最新のアップデート (筆者が確認した時点ではService Pack 4まであります) すべてを含めて、Microsoft Visual C++ 6がインストールされていることを確認します。gccのようなWindows上の他のコンパイラーをサポートする取り組みが進行中ですが、今のところ、VC6だけが動作確認されています。SP3を含むVC5も動作することになっていますが、私は確認していません。
  2. コンパイラー、リンカー、およびmakeツールをシェル・ウィンドウから実行できることを確認します。
    • "cl" と入力します - "Microsoft (R) 32 bit Optimizing C/C++ compiler version .." のような表示が出ます。
    • "nmake" と入力します - "Microsoft (R) Program Maintenance Utility ..." のような表示が出ます。
    • "lib" と入力します - "Microsoft (R) Library Manager ..." のような表示が出ます。

      いずれも動作しない場合、後述のステップ5に示されている環境変数のヒントを参照してください。

  3. ソースtarファイルをダウンロードし (参考文献を参照)、空き容量がたくさんあるディスク (最小で約1ギガ、同時にデバッグとリリースの両方のビルドをする場合は2ギガ) の "mozilla" ディレクトリーに内容をunzipします。
  4. cygwin、Active State Perl、およびinfozipのような、必要とする補足ツールをダウンロードします (これらのプログラムへのリンクは、参考文献を参照してください)。tarファイルをunzipするときに、winzipやpkzipを使えますが、Mozillaのmakeファイルでは、作成の一部としてinfozipを使います。
  5. 次の環境変数を定義する必要があります:
    Windows 9Xの場合、次のように2、3のコマンドをAUTOEXEC.BATに追加します: 
     set PATH=%PATH%;C:\cygwin\bin;C:\progra~1\micros~1\common\msdev98\bin;c:\perl\bin
 C:\progra~1\micros~1\vc98\bin\vcvars32
 set MOZ_BITS=32
 set MOZ_SRC=C:
 set MOZ_TOOLS=C:
 set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot

    Windows 2000の場合、[コントロール パネル] にナビゲートし ([スタート/設定/コントロール パネル] の順にクリックします)、[システム] をクリックして、[詳細] タブを選択し、[環境変数] をクリックして、編集ダイアログを表示します。それぞれのシステムで、次に示す設定またはそれに相当する同様の設定事項 (表1を参照) を調べます。

表1. システム環境変数
PATHC:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;
C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin;
C:\Program Files\Microsoft Visual Studio\Common\Tools;
C:\Program Files\Microsoft Visual Studio\VC98\bin;
C:\Perl\bin;
C:\cygwin\bin
includeC:\Program Files\Microsoft Visual Studio\VC98\atl\include;
C:\Program Files\Microsoft Visual Studio\VC98\mfc\include;
C:\Program Files\Microsoft Visual Studio\VC98\include
libC:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;
C:\Program Files\Microsoft Visual Studio\VC98\lib
MSDevDirC:\Program Files\Microsoft Visual Studio\Common\MSDev98
MOZ_BITS32
MOZ_SRCC:
MOZ_TOOLSC:
CVSROOT:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot

正確なPATHの指定先は、ツールをインストールした場所に応じて異なります。MOZ_SRC変数は、mozillaディレクトリー・ツリーのすぐ上 のディレクトリーを指していなければなりません。MOZ_TOOLS変数は、cygwinツールのbinディレクトリーのすぐ上 のディレクトリーを指している必要があります。

上に戻る

Cygwin GNUツール

インストールするサード・パーティー・ツール群の最初のものは、Windows用に移植されたGNUコマンド行ツール群です。ファイル "setup.exe" をダウンロードして実行します (この作業をするために、アクティブなインターネット接続が必要です)。セットアップ・プログラムは、選択したコンポーネントをダウンロードしてインストールします。必要なコンポーネントは、ash、cygwin、diff、fileutils、gawk、grep、sed、shellutils、textutils、unzip、およびzip です。このようなGNUツールをダウンロードするときに、PerlおよびCVSを取ってくることもできますが、そうはしないでください。ビルドのエキスパートは、他の場所で入手できる異なるバージョンをお奨めしています。別のモジュールをダウンロードするといくらか時間がかかりますので、少し我慢してください。

上に戻る

Infozip

ビルド・プロセスには、JARファイルを作成するためのinfozipが必要です。上記のcygwinセットアップには、zip およびunzip (infozipの2つの部分) を、ダウンロードしてインストールするためのオプションがあります。infozipツールを入手する別のルートとして、次のステップを行うことができます。zipツール配布物はZIPファイルで配布されるため、それをunzipするために、別のunzipが必要になります。infozipのサイト (またはいずれかのミラー・サイト) から、ファイル "unz542xN.exe" および "zip23xN.zip" を、一時ディレクトリーへダウンロードし、次のコマンドを入力します:

cd \temp
unz542xN
unzip zip23.zip
copy *.exe c:\bin

上に戻る

Netscape Wintools

Netscapeは、たくさんのGNUコマンド行ツールを修正し、いくつかの問題を解決しています。そのほとんどは、GNUスタイルのUNIXビルドとの間のmakeファイルの互換性の問題です。このバンドルのインストーラーは、MOZ_TOOLS変数を使って、いくつかの実行可能ファイルのインストール先を判別するため、前述の環境変数を追加しておく必要があります。次のコマンドをコマンド・プロンプトから実行すると、wintools.zipファイルがデフォルトのディレクトリー "buildtools" にunzipされ、インストールが完了します。

cd \temp
unzip wintools.zip
cd \buildtools\windows
install

上記のステップでは、実際に "C:\bin" および "C:\include" ディレクトリーが作成されます (ただし、MOZ_TOOLSが "C:" にあると定義したとして)。スペースを節約しようと思えば、このステップの後に "buildtools" の下にあるすべてのものを削除できます。他のツールとは違って、Netscape Wintoolsへのパスは、PATH環境変数内に含めない ようにします。makeファイルでは、gmakeおよびNetscapeによって修正された他のバイナリーを見つけるため、MOZ_TOOLSを使います。

上に戻る

Perl

Active State Perlをインストールすることは、恐ろしく簡単です。Windows Installerモジュール、つまりMSIファイルとしてダウンロードするだけでよいのです。Windowsのエクスプローラを使い、Perlをダウンロードしたフォルダーを参照し、"ActivePerl-5_6_0_616-MSWin32-x86-multi-thread.msi" のようなファイルをクリックします。

小さなことですが、2つの「要点」にお気づきでしょうか。まず、インストーラーは "\Perl\bin" をPATH環境変数へ追加します。Windows NTかWindows 2000を実行している場合、このことは現在ログインしているユーザーにのみ適用されます。次に、Windows 9XかNTを実行している場合、Microsoft社のWebサイトから、Microsoft Windows Installerパッケージをダウンロードしなければならない場合があります。

最後のテストとして、マシンをリブートして変更を有効にします。コマンド行ウィンドウを開き、コマンド・プロンプトにサード・パーティー・ツールの名前を入力し、それぞれのツールを実行してみます。実行してみるとよいコマンドは、ash、diff、grep、perl、およびunzip です。

ここまでのステップは、ビルド環境を作成するときまたは再作成する場合にのみ必要なものです。ここからのステップは、実際にMozillaをビルドするたびに実行する必要のあるものです。

デバッグ・ビルドを実行する場合、ビルドの直前に次のコマンドを入力します:

set MOZ_DEBUG=1

知っておくと役立つその他のオプションは、次のようなものがあります:

  • SVGサポートを追加するMOZ_SVG
  • MathMLサポートを追加するMOZ_MATHML
  • LDAPサポート用のMOZ_LDAP_XPCOM
  • ビルドのときにzipの使用で混乱したくない場合に役立つMOZ_DISABLE_JAR_PACKAGING
  • その他に、試してみる価値があるMOZ_LITE、MOZ_MEDIUM、およびMOZ_MAIL_NEWS

最後に、次のコマンドを実行してビルドを開始します:

nmake /f client.mak build_all

この時点で発生する可能性のある一般的なエラーのほとんどには、失敗になるコマンドを発行するmakeファイルが関係しています。失敗の理由としては、コマンドに指定したツールがないか、検索パスに示されていないかのいずれかです。ビルド環境の間違いが解消されれば、ビルド・プロセスが2、3時間かけて実行されます (うそではありません)。

正しい作成環境であったとしても、実行して問題が生じる場合もあります。上記の手順が妥当かどうかを調べるために、mozilla-0.7 tarファイルでテストしてみました。PR_CLIENT_BUILD_WINDOWSオプションをセットすると、NSPRモジュールでgmakeがクラッシュするという問題がすぐに発生しました (NSPRは、一番最初にビルドされるモジュールです)。mozilla-0.8 tarファイルをダウンロードしてunzipし、上記のコマンドを再実行したら、コンパイルはすべてうまくゆきました。Mozillaビルド・ページ (参考文献を参照) には、一般的なエラーとその解決方法のリストが示されています。

上に戻る

WindowsでのCVS

cvshome.orgのサイトから、Windows用のCVSバイナリーをダウンロードします。

次に示すのは、CVSサーバーからソース・ツリー全体を引き出すためのコマンド・シーケンスです:

  • set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
  • set HOME=\TEMP
  • cvs login (CVSログインのプロンプトに応答)
  • cvs checkout mozilla/client.mak
  • cd mozilla
  • nmake -f client.mak pull_all

次に示すのは、変更したファイルだけをCVSサーバーに送達させることで、(最新のtarファイルのように) 既存のソース・ツリーを更新するコマンド・シーケンスです:

  • set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
  • set HOME=\TEMP
  • cvs login (CVSログインのプロンプトに応答)
  • cd mozilla
  • cvs -z3 checkout -PA mozilla/client.mk
  • nmake -f mozilla/client.mak checkout MOZ_CO_FLAGS=-PA

上に戻る

Linux環境のセットアップ

Windowsのときとは対照的に、プログラマー・フレンドリーなほとんどのLinux配布版には、Mozillaを作成するのに必要なすべてのツールがそろっています。DebianやRedHatやSlackwareなどのLinux CDを入手したら、ありがたいことに、必要な部品がすべてそこに入っているわけです。ビルド環境を整えて実行するために必要な点は、どのバージョンがインストールされているかを確認することだけです。

次に、必要なパッケージのまとめを示します:

  • C++ コンパイラー
    • egcs
    • gcc
  • GNU make
  • GTK/GLib
  • Perl 5
  • zip

環境変数を次のように設定します:

  • ・setenv MOZ_BITS 32
  • ・setenv MOZ_SRC=/usr/home
  • ・setenv CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot

次のようにしてmozillaディレクトリーからconfigツールを実行します:

cd mozilla./configure

mozillaディレクトリーから、デフォルトのビルドを実行します:

gmake

mozillaディレクトリーから、手動のビルドを実行します:

gmake -f client.mk build

上に戻る

LinuxでのCVS

次のコマンドを使い、CVSからソース・ツリー全体を引き出します:

  • setenv CVSROOT :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
  • cvs login (CVSサーバー・ログインのプロンプトに応答)
  • cvs checkout mozilla/client.mk
  • cd mozilla
  • make -f client.mk checkout

次のコマンドを使い、(最新のtarファイルのように) 既存のソース・ツリーを、CVSサーバーからの最新ソースに更新します:

  • setenv CVSROOT :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
  • cvs login (CVSサーバー・ログインのプロンプトに応答)
  • cd mozilla
  • cvs -z3 checkout -PA mozilla/client.mk
  • make -f mozilla/client.mk checkout MOZ_CO_FLAGS=-PA

上に戻る

その他の環境

Win32、Mac、UNIX、Linux、BSD、および他のプラットフォームで明示的に作成するときの指示は、ビルド・ページ (参考文献を参照) を調べてください。ここまでの指示すべてに実際に従い、自分のコンピューターで機能するビルド環境を正しく設定してきたのであれば、表彰モノです (少しお休みください)!自分で自分を誉めていただき、ここからは実際に生産的な作業を始めましょう。

上に戻る

アプリケーションでのXPCOMの使用可能化

アプリケーションが実際にXPCOMコンポーネントを使い始める前に、XPCOMフレームワークが機能するように、ロードして初期設定しておく必要があるライブラリー群があります。次に示すのは、そのことを実行するサンプル・アプリケーションです:

リスト1. 必要なライブラリーをロードして初期設定するサンプル・アプリケーション

#include <stdio.h>
#include <nsIServiceManager.h>
#include <nsISomething.h>
int main()
{
   static const char szContractId[] =
      "Your component's contract ID goes here";
   nsresult rv;
   // Initialize XPCOM and check for failure ...
   rv = NS_InitXPCOM(nsnull, nsnull);
   if ( NS_FAILED(rv) )
   {
      printf("Calling NS_InitXPCOM returns [%x].\n", rv);
      return -1;
   }
   // optional autoregistration - forces component manager to check for new components.
   (void)nsComponentManager::AutoRegister(nsIComponentManager::NS_Startup, nsnull);
   // Create an instance of our component
   nsCOMPtr<nsisomething> mysample = do_CreateInstance(szContractId, &rv);
   if ( NS_FAILED(rv) )
   {
      printf("Creating component instance of %s fails.\n", szContractId);
      return -2;
   }
   // Do something useful with your component ...
   // (main body of code goes here)
   // Released any interfaces.
   // Shutdown XPCOM
   NS_ShutdownXPCOM(nsnull);
   return 0;
}

重要な呼び出しは2つあり、NS_InitXPCOM とNS_ShutdownXPCOM です。XPCOMのコア・ライブラリーは、普通はアプリケーションと同じディレクトリーにあり、"components" という別のサブディレクトリーが必要になります。XPCOMを初期化したら、生産的な作業を実行するときに直接に関係する2大コンポーネントは、コンポーネント・マネージャーとサービス・マネージャーです。AutoRegisterへの呼び出しは実際には任意指定で、これが本当に必要になるのは、新しいコンポーネントをインストールするときだけです。

上記の例では、ブラウザー・サポートを必要としないスタンドアロン・アプリケーションを想定しています。nsISomething は、いくつかの実インターフェースにとっては見せかけに過ぎません。このインターフェースを利用する現実のアプリケーション・コードは、上記のサンプルで "main body of code goes here" とコメントされている位置に置かれます。

上に戻る

コンポーネント・マネージャー

コンポーネント・マネージャーは、名前が示すとおりのことを行います。すなわち、現在どのコンポーネントがインストールされているか、また、特定のコンポーネントを作成するのにどのDLLまたは共用ライブラリーをロードすべきかを記憶しています。前述のcomponentsサブディレクトリーは、コンポーネント・マネージャーが、コンポーネントを見つけようとする場所ということになります。上記のAutoRegisterステップでこのディレクトリーをスキャンして、まだ登録されていないコンポーネントを探し、記述項目を専用のマップ・ファイルに追加します。どのDLLまたは共用ライブラリーをロードするかについては、すでにマップからわかっているので、この後にコンポーネントに対して出される要求はずっと早くなります。コンポーネントは、次の2つのいずれかで識別されます: クラスID (CID) として知られている128ビットのUUID、またはコントラクトIDとして知られている短いテキスト名。

MSCOMプログラマーへの注: コントラクトIDは、MSCOMのプログラムID (ProgID) と機能的に同等です。

ここでは、IDLのコンポーネント・マネージャーによって提供されるコア・メソッドをいくつか紹介します。最初のものは、指定したコントラクトIDのクラスIDを検索します。同じクラスのコンポーネントを大量に作成する計画で、コンポーネントのコントラクトIDしか知らない場合、まずこのメソッドを呼び出し、createInstance に対するその後の呼び出しで、短く、速いクラスIDを使うことにより、パフォーマンスを改善できます。

void contractIDToClassID(in string aContractID, out nsCID aClass);

次のメソッドは、上記の逆を行うだけです:

string CLSIDToContractID(in nsCIDRef aClass, out string aClassName);

次のメソッドは、いくつかのコンポーネントが登録されていて使用できることを確認します:

boolean isRegistered(in nsCIDRef aClass);

次の2つのメソッドは、任意のXPCOMコンポーネントをロードするために、面倒なすべての作業を実行してくれます。コンポーネントを識別するときの選択を、createInstance のクラスIDによって、またはcreateInstanceByContractID のcontractID によって、最初のパラメーターに指定します。2番目のパラメーターaDelegate は、集約という作業を行っている場合にだけ必要で、普通はnsnullにセットされています。3番目のパラメーターは、インターフェースIIDです。

voidPtr createInstance(in nsCIDRef aClass, in nsISupports aDelegate, in nsIIDRef aIID);
voidPtr createInstanceByContractID(in string aContractID, in nsISupports aDelegate, in nsIIDRef IID);

コンポーネント・マネージャー・メソッドのすべてのIDLソースは、nsIComponentManager.idl にあります。

上に戻る

サービス・マネージャー

XPCOMサービスは、いくつかの本の中でシングルトン・オブジェクトとして言及されています。サービスを何回要求したとしても、あなたは同じコンポーネントへのインターフェースを受け取ります。すべてのサービスの中でも最大のサービス、すなわちコンポーネント・マネージャーについてはすでに見ました。遠まわしに言うと、サービス・マネージャーそのものがサービスと言えます。要するに、サービス・マネージャーは、サービスのロードとアンロードを担当します。すでにロードされたサービスへの要求を出すと、賢いサービス・マネージャーは、別のオブジェクトを構成しようとするのではなく、既存のサービスへの別のポインターを戻します。この動作が、要求ごとに新しいコンポーネントを新調するコンポーネント・マネージャーとどのように違うかに注目してください。サービスは、リスト2で示されているように、普通はNS_WITH_SERVICEマクロを使って要求されます。

リスト2. サービス要求
{  // enter scope of service smart pointer ...
   NS_WITH_SERVICE(nsIMyService, service, kMyServiceCID, &rv);
   if (NS_FAILED(rv)) return rv;
   service->DoSomething(...);    // use my service
} // leaving scope of service smart pointer ...

NS_WITH_SERVICEマクロは、nsCOMPtr を使ってスマート・ポインターを作成することに注目してください。サービスの例がいくつか表2にリストされています。

表2. サービスの例

  • LDAP
  • WebShell
  • JSRuntime
  • Editor
  • EventQueue
  • RDF
  • SMTP
  • IMAP
  • POP3
  • NNTP
  • DNS
  • Error
  • Logging

上に戻る

カテゴリー・マネージャー

コンポーネント・マネージャーとサービス・マネージャーは、コントラクトIDまたはクラスIDを与えられたコンポーネントを取ってきます。しかし、そのどちらのIDもわからないコンポーネントを見つけるときにはどうしますか?この質問の答えは、カテゴリー・マネージャーです。カテゴリー・マネージャーには、カテゴリーに分けられたクラスIDのディレクトリーがあります。ここで言う「ディレクトリー」とは、ディスク・ドライブのディレクトリーではなく、(イエロー・ページのような) 電話帳を思い浮かべてください。電話帳のような形式を使うと、その地域のすべてのホテルを探したい場合に、電話帳の「ホテル」の項目を探すことができます。

たとえば、あなたがさまざまなワード・プロセッシング機能を備え、汎用のインターフェース群を使って複数の文書タイプを扱える、出来の良いエディターを作成したとします。サポートするために選んだ文書タイプは、テキスト、HTML、RTFおよびPDFです。しかし、文書ハンドラー群は「文書ハンドラー」カテゴリーに登録され、使用可能な文書タイプを判別するために、いつも文書ハンドラー・カテゴリーをチェックするようにプログラムを作成しました。

あなたの友達が、あなたのプログラムをどうしてもWordPerfectファイル対応にすると決心し、同じインターフェース群をインプリメントする新しい文書ハンドラー・コンポーネントを作ってきて、文書ハンドラー・カテゴリーの下に登録します。あなたのプログラムを使うユーザーは、友達の新しい文書ハンドラーを、ダウンロードし、インストールし、使い始められるようになりました。あなたの側では余分の作業をする必要はありません。

あるカテゴリーの下にグループ化されたコンポーネントは、事前定義されたインターフェース群のように、普通は何らかの共通点があるものです。それ自身をカテゴリーの下に登録するコンポーネントにとって、カテゴリーというものは暗黙の契約になります。カテゴリーはオブジェクトを独立させるための、非常に強力な方法です。なぜなら、カテゴリーを利用するコードは、インターフェースについて知ろうとするだけであり、特定のインプリメンテーションからは分離することができるためです。このような威力があるのですが、カテゴリーはXPCOMの中で期待したほど使われていない最たる特徴の一つです。

上に戻る

結論

Mozillaソース・ツリーを作成できるようになり、実際にコンポーネントのユーザーになったら、向かうところ敵なしであることを堂々と宣言なさってください。ほんの少しの知識でもこれほど心強いのですが、このシリーズの次の2つの記事を読めば、さらにあなたの知識を完成させることができます。コンポーネントを作成する力をつけるだけでなく、自分自身のプログラムを台無しにしたり他人のアプリケーションを壊してしまうことなく、作成できるようになるでしょう。

参考文献

コメント

閉じる [x]

developerWorks: サイン･イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか？


パスワードをお忘れですか？
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む。

 

お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報（名前、国/地域や会社名）は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

閉じる [x]

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む。

 

送信されたすべての情報は安全です。

上に戻る

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=244518
ArticleTitle=XPCOM: 第3回: XPCOMのセットアップ
publish-date=03012001