include_pathのどこからでもプロバイダとマニフェストが由来するかもしれないので、 ツール・チェーンのいろいろな部分へのアクセスを単純化するためにレジストリが提供されます。 このレジストリはレジストリを認識するコンポーネントに注入されます。 そして、それから必要に応じてそれは彼らから依存性を引き出すかもしれません。 レジストリで登録される依存性の多くは、下位-構成要素に特有のリポジトリです。 レジストリのためのインターフェースは、以下の定義から成ります。: レジストリが管理するいろいろなオブジェクトは、それらに該当する部分で論じられます。 レジストリを認識しなければならないクラスは、 Zend_Tool_Framework_Registry_EnabledInterfaceを実行しなければなりません。 このインターフェースは、単に対象クラスだけでレジストリの初期化を可能にします。 Zend_Tool_Framework_Providerは、 フレームワークの機能または「能力」面を表現します。 基本的に、Zend_Tool_Framework_Providerは 「プロバイダ」をもたらすために必要なインターフェース、 またはZend_Tool_Frameworkツール・チェーン内で呼ぶことができて、 使うことができる若干のツーリング機能を提供します。 このプロバイダ・インターフェースを実装することの割り切った性質によって、 開発者は機能/能力を「ワンストップサービス」で Zend_Tool_Frameworkに加えることができます。 プロバイダ・インターフェースは空のインターフェースで、メソッドを強制しません。 （これは、マーカ・インターフェース・パターンです）: あるいは、もし望めば、Zend_Tool_Framework_Registryに アクセスできるようにする基底（または抽象）プロバイダを実装できます。: ローダの目的は、Zend_Tool_Framework_Provider_Interfaceか Zend_Tool_Framework_Manifest_Interfaceを実装するクラスを含む プロバイダとマニフェスト・ファイルを見つけることです。 一旦これらのファイルがローダによって見つかると、 プロバイダはプロバイダ・リポジトリにロードされ、 マニフェスト・メタデータはマニフェスト・リポジトリにロードされます。 ローダを実装するために、以下の抽象クラスを拡張しなければなりません: _getFiles()メソッドは、ファイル（絶対パス）の配列を返さなければなりません。 Zend Frameworkで供給されるビルトイン・ローダは、インクルードパス・ローダと呼ばれます。 デフォルトで、ツーリング・フレームワークは、 プロバイダまたはマニフェスト・メタデータ・オブジェクトを含むかもしれないファイルを見つけるために、 include_pathベースのローダを使います。 他のオプションが全く無くても、 Zend_Tool_Framework_Loader_IncludePathLoaderはインクルードパスの中で Mainfest.php、Tool.phpまたはProvider.phpで 終わるファイルを探します Zend_Tool_Framework_Loader_Abstractのload()メソッドによって一旦見つかると、 それらがサポートされたインターフェースのいずれかを実装するかどうか判定するためにそれらはテストされます。 もし実装していれば、見つかったクラスのインスタンスがインスタンス化されます、 そして、それは固有のリポジトリを付加されています。 ご覧の通り、インクルードパス・ローダは、$_filterAcceptFilePatternにマッチし、 $_filterDenyDirectoryPatternにマッチしないファイルを求めて、 すべてのinclude_pathsを検索します。 要するに、マニフェストはプロバイダ・リポジトリにどんなさらなるプロバイダでもロードする役割を果たしうるばかりではなく、 どんなプロバイダまたはクライアントにとってでも有用である、指定された、または任意のメタデータを含みます。 空のZend_Tool_Framework_Manifest_Interfaceを実装して、 Zend_Tool_Framework_Manifest_Metadataを実装する オブジェクトの配列を返すgetMetadata()メソッドを提供しさえすれば、 メタデータをマニフェスト・リポジトリにもたらすことができます。 下記で定義されたローダによって、 メタデータ・オブジェクトはマニフェスト・リポジトリ(Zend_Tool_Framework_Manifest_Repository)にロードされます。 すべてのプロバイダがプロバイダ・リポジトリにロードされるとわかったあと、マニフェストは処理されます。 これによって、何が現在プロバイダ・リポジトリ内部にあるかに基づくメタデータ・オブジェクトをマニフェストは作成できます。 メタデータを記述するために用いることができる 多少の異なるメタデータ・クラスがあります。 Zend_Tool_Framework_Manifest_Metadataは、 基底メタデータ・オブジェクトです。 以下のコード・スニペットによってわかるように、 基底メタデータ・クラスは事実上かなり軽量で抽象的です: より分化したメタデータを記述するために同様に他のビルトイン・メタデータ・クラスがあります: ActionMetadata及びProviderMetadata。 これらのクラスは、アクションまたはプロバイダのいずれかに特有なメタデータをより詳細に記述する助けになります。 そして、参照はそれぞれアクションまたはプロバイダへの参照であることが期待されます。 これらのクラスは、以下のコード・スニペットで記述されます。 これらのクラスでの'Type'は、 オブジェクトが責を負うべきメタデータのタイプを記述するのに用いられます。 ActionMetadataのケースでは、タイプは'Action'です。 そして逆に、ProviderMetadataの場合は、タイプは'Provider'です。 これらのメタデータ・タイプは、 それらがこの新しいメタデータで参照しているオブジェクト(getReference())だけでなく、 それらが記述している「もの」についても、さらなる構造化情報を含みます。 基底Zend_Tool_Framework_Manifest_Metadataクラスを拡張して、 クラス/オブジェクト・ローカル・マニフェストを通してこれらの新しいメタデータ・オブジェクトを返しさえすれば、 あなた自身のメタデータ・タイプを構築できます。 これらのユーザー・ベースのクラスは、マニフェスト・リポジトリの中に残ります もし、これらのメタデータ・オブジェクトがリポジトリならば、 リポジトリでそれらを探すために利用できる２つの異なるメソッドがあります。 findMetadatas(array( * 'action' => 'Foo', * 'name' => 'cliActionName' * )); * * 値'Foo'と名前'action'でキーを持つどんなメタデータ・オブジェクトも見つけます。 * そして、キーは'cliActionName'の'name'値と名づけられました。 * * 注意: * 検索基準の中に存在するが、オブジェクトに現れない名前と値のペアを除外するか、 * または含むために、$includeNonExistentPropertiesにブール値を渡してください */ public function findMetadatas(Array $searchProperties = array(), $includeNonExistentProperties = true); /** * どれくらいが返されたかに関係なく、 * マッチしている検索基準のうちのちょうど1つを以下は返します。 * マニフェストの最初の1つは、何が返されるかということです。 */ public function findMetadata(Array $searchProperties = array(), $includeNonExistentProperties = true) { $metadatas = $this->getMetadatas($searchProperties, $includeNonExistentProperties); return array_shift($metadatas); } } ]]> 上記のサーチ方式を見ると、シグニチャはとても柔軟に検索することを許します。 メタデータ・オブジェクトを見つけるために、 制約にマッチする配列を単に配列によって渡してください。 データがプロパティ・アクセッサ （オブジェクト・メタデータの上で実装されるgetSomething()メソッド） によってアクセスできるならば、 それは「見つかった」オブジェクト・メタデータとしてユーザーへ渡されます。 クライアントは、Zend_Tool_Frameworkシステムと ユーザーまたは外部ツールとの橋渡しをするインターフェースです。 クライアントは、すべての形とサイズに伝わることができます: RPCエンドポイント、コマンド・ライン・インタフェースまたはウェブ・インターフェースさえ。 Zend_Toolは、Zend_Tool_Frameworkシステムと相互に作用するための デフォルト・インターフェースとして、コマンド・ライン・インタフェースを実装しました。 クライアントを実装するためには、以下の抽象クラスを拡張する必要があります。: ご覧の通り、そこで、1つのメソッドはクライアントの必要を満たすことを要求されます。 （他の２つは提案されます） 初期化、前処理と後処理 コマンド・ライン・クライアントが動く方法についてより深く研究するには、 ソースコード を見てください。