フロントコントローラ概要Zend_Controller_Front は » Model-View-Controller (MVC) アプリケーションで用いられる » フロントコントローラパターン を実装したものです。 その役割は、リクエスト環境を初期化してリクエストの配送先を決定し、 見つかった配送先に処理を引き渡すことです。また、 レスポンスの内容を取得してそれをコール元に返します。 Zend_Controller_Front は » シングルトンパターン も実装しています。つまり、どんな場合でもひとつのインスタンスしか存在しないことになります。 これを利用すると、コントローラをレジストリとして扱えるようになります。 Zend_Controller_Front は プラグインブローカ を持っています。これにより、さまざまなイベントをプラグインで処理できるようになります。 開発者は、ディスパッチ処理をカスタマイズして機能を追加する際に フロントコントローラ自体を継承したクラスを作成する必要がなくなります。 アクションコントローラ へのパスを含むディレクトリを最低ひとつは指定しないと、 フロントコントローラは動作しません。 フロントコントローラの動作環境やそのヘルパークラスを変更するために、 さまざまな手法が用意されています。
主要なメソッドフロントコントローラには、その環境設定用のメソッドがいくつか用意されています。 そのうち、フロントコントローラの機能の鍵となる主要なメソッドは、以下の3つです。 getInstance()getInstance() は、フロントコントローラのインスタンスを取得します。 フロントコントローラはシングルトンパターンを実装しているので、 フロントコントローラのインスタンスを作成する唯一の方法はこのメソッドをコールすることとなります。
setControllerDirectory() および addControllerDirectorysetControllerDirectory() は、ディスパッチャ が アクションコントローラ クラスファイルをどこから探せばよいのかを指定するメソッドです。 単一のパスを指定することもできますし、複数のパスを連想配列で指定することもできます。 いくつか例を示します。
コントローラディレクトリの現在の設定を取得するには getControllerDirectory() を使用します。 これは、モジュールとディレクトリの組を配列で返します。 addModuleDirectory() および getModuleDirectory()フロントコントローラのひとつの側面として、モジュラーディレクトリ構造を定義 して単体のコンポーネントを作成するということがあります。 これは "モジュール" と呼ばれます。 書くモジュールは個別のディレクトリになければならず、 またデフォルトモジュールと同じディレクトリ構成でなければなりません。 すなわち、すくなくともサブディレクトリ /controllers/ がなければならず、 またたいていは /views/ などの他のサブディレクトリもあるということです。 addModuleDirectory() には、ひとつあるいは複数のモジュールディレクトリの名前を渡します。 渡された内容を調べ、それをフロントコントローラのコントローラディレクトリに追加します。 その後、特定のモジュールや現在のモジュールへのパスを知りたい場合に getModuleDirectory() をコールします。 モジュール名を渡すと、指定したモジュールのディレクトリを取得することができます。 dispatch()dispatch(Zend_Controller_Request_Abstract $request = null, Zend_Controller_Response_Abstract $response = null) は、フロントコントローラでもっとも重要な仕事を担当します。 オプションで リクエストオブジェクト や レスポンスオブジェクト を受け取り、それぞれ独自のオブジェクトを指定することができます。 リクエストオブジェクトやレスポンスオブジェクトを省略すると、 dispatch() は事前にオブジェクトが登録されているかどうかを確認します。 もし登録されていればそれを使用し、登録されていなければデフォルトのオブジェクトを作成して使用します (どちらの場合についても、HTTP リクエスト/レスポンス オブジェクトをデフォルトで使用します)。 同様に、 dispatch() は ルータ や ディスパッチャ オブジェクトについても登録済みのものがあるかどうかを確認します。 もしあればそれを使用し、なければデフォルトのオブジェクトを作成して使用します。 ディスパッチ処理は、次の三段階に分けられます。
ルーティングは一度だけ発生します。これは、 dispatch() がコールされた際のリクエストオブジェクトの内容を使用して行います。 ディスパッチは繰り返し行われます。 ひとつのリクエストが複数のアクションを指定している場合や、 コントローラまたはプラグインがリクエストオブジェクトを設定しなおして 別のアクションへディスパッチさせた場合などです。 すべてが終了したら、フロントコントローラはレスポンスを返します。 run()Zend_Controller_Front::run($path) は静的メソッドで、コントローラを含むディレクトリへのパスを指定します。 このメソッドは getInstance() を使用してフロントコントローラのインスタンスを取得し、 setControllerDirectory() を使用してパスを登録し、最後に ディスパッチ します。 run() は、サイト単位の設定などで フロントコントローラのカスタマイズが不要な場合に便利なメソッドです。
環境へのアクセス用メソッド群これまでに説明したメソッド以外にもさまざまなアクセス用メソッドが用意されており、 これらを使用してフロンとコントローラの環境にアクセスすることができます。 つまり、フロントコントローラが処理を委譲しているクラスの環境にもアクセスできるということです。
フロントコントローラのパラメータ最初のほうで、フロントコントローラはレジストリとしても使用できると説明しました。 その際に使用するのが "param" 系のメソッド群です。 これらのメソッドを使用すると、任意のデータ (オブジェクトや変数) をフロントコントローラに登録することができます。 登録したデータは、ディスパッチチェイン内のどこででも使用できます。 これらの値は、ルータやディスパッチャそしてアクションコントローラにも渡されます。 各メソッドについて、以下にまとめます。
ディスパッチチェイン内で特定の目的で使用するために、 いくつかのパラメータが事前に定義されています。
フロントコントローラの継承フロントコントローラを継承する際には、 最低限 getInstance() メソッドをオーバーライドしなければなりません。
getInstance() メソッドをオーバーライドすることで、それ以降の Zend_Controller_Front::getInstance() のコールが Zend_Controller_Front ではなく新しいサブクラスのインスタンスを返すようになります。 これは、デフォルト以外のルータやビューヘルパーを使用する場合などに便利です。 何か新しい機能 (たとえばプラグインの自動ローダーや、 アクションヘルパーのパスの指定方法) を追加したいというのでもない限り、 ふつうはフロントコントローラのサブクラスを作成する必要はありません。 ほかに変更したくなるような箇所としては、 コントローラディレクトリの保存方法や デフォルトルータ/デフォルトディスパッチャを使用するかどうかなどがあるでしょう。
|