Zend_Controller は軽量で部品化されており、拡張しやすいように設計されています。 この設計は、柔軟性および利用者に対する自由度を確保するための最低限のものであり、 Zend_Controller を使用して構築したシステムは、 ほぼ同じようなコード配置・規約を共有できます。

次の図は処理の流れを表したものです。また、詳細についてはそれ以降で説明しています。

Zend_Controller の処理の流れは、 いくつかの部品にわかれて実装されています。 これらの部品のすべてを完璧に理解する必要はありませんが、 処理の概要を知っておくことは有用です。

• Zend_Controller_Front は、 Zend_Controller の処理全体を取りまとめます。 FrontController パターンであるといえます。 サーバから受け取ったすべてのリクエストを Zend_Controller_Front が処理し、最終的にリクエストを ActionController (Zend_Controller_Action) に委譲します。

• Zend_Controller_Request_Abstract はリクエスト環境を表し、コントローラ名やアクション名 そしてリクエストパラメータを設定したり取得したりする機能を提供します。 さらに、アクションが Zend_Controller_Dispatcher でディスパッチされたかどうかを追跡する機能もあります。 この抽象リクエストオブジェクトを拡張し、 リクエスト情報をカプセル化します。それによって、 ルータはリクエストの情報を取得して コントローラとアクションを決定できるようになります。

  デフォルトでは Zend_Controller_Request_Http が用いられます。これは、HTTP リクエスト環境全体へのアクセス機能を提供します。

• Zend_Controller_Router_Interface を使用してルータを定義します。 ルーティングとは、リクエストの内容を調べて、 そのリクエストを処理するコントローラとアクションを決定する処理のことです。 このコントローラとアクション、そしてリクエストパラメータがリクエストオブジェクトに設定され、 Zend_Controller_Dispatcher_Standard で処理されます。 ルーティングが発生するのは一度だけ、 つまり最初にリクエストを受け取ってから 最初のコントローラにディスパッチされるまでの間だけです。

  デフォルトのルータである Zend_Controller_Router_Rewrite は、 Zend_Controller_Request_Http で指定された URI を受け取ってそれを分解し、コントローラや アクション、そして URL に含まれたパスのパラメータを取得します。 たとえば、http://localhost/foo/bar/key/value のような URL の場合は foo がコントローラ、 bar がアクション、そしてパラメータ key の値として value を取得します。

  Zend_Controller_Router_Rewrite は、任意のパスにマッチさせることもできます。 詳細は ルータのドキュメント を参照ください。

• Zend_Controller_Dispatcher_Interface を使用してディスパッチャを定義します。ディスパッチとは、 コントローラとアクションをリクエストオブジェクトから受け取り、 それを実際のコントローラファイル/クラスとメソッドに対応させる処理のことです。 コントローラやアクションが存在しない場合は、 デフォルトのコントローラやアクションにディスパッチします。

  実際のディスパッチ処理では、 コントローラクラスのインスタンスの作成と そのクラスのアクションメソッドのコールを行います。 ルーティングは一度しか発生しませんが、 それとは異なりディスパッチは繰り返し発生します。 リクエストオブジェクトのディスパッチ状態がリセットされるとループが再開され、 現在リクエストオブジェクトに設定されているアクションがコールされます。 リクエストオブジェクトのディスパッチ状態が (TRUE に) 設定された状態でループが終了すると、処理が終了します。

  デフォルトのディスパッチャは Zend_Controller_Dispatcher_Standard です。 これは、MixedCasedClasses 形式の名前の最後に Controller がついたクラスをコントローラとして使用し、 アクションメソッドの名前は camelCasedMethods 形式 (最後に Action をつける) となります。たとえば FooController::barAction() のような場合、コントローラは foo、アクションは bar となります。

  注意: 大文字小文字の命名規約
  人はみな、リンクをタイプする際に大文字小文字の区別をあまり気にしないものです。 Zend Framework では、パス情報をすべて小文字に正規化します。 これはもちろん、 コントローラ名やアクション名を決める際やリンクする場合にも影響を及ぼします。
  コントローラクラスやアクションメソッドの名前に MixedCase あるいは camelCase の単語を複数使用したい場合は、 URL 上での単語の区切り文字として '-' あるいは '.' のいずれかを使用しなければなりません (とは言え、ここで使用する文字は変更できます)。
  たとえば、アクションを FooBarController::bazBatAction() で定義したとすると、対応する URL は /foo-bar/baz-bat あるいは /foo.bar/baz.bat となります。
  

• Zend_Controller_Action はコントローラの基底コンポーネントです。 各コントローラはこの Zend_Controller_Action クラスを継承して作成します。このクラスではアクションメソッドを定義します。

• Zend_Controller_Response_Abstract は基底レスポンスクラスで、アクションコントローラからの応答内容を収集し、 それをレスポンスとして返します。これはヘッダと本文の両方を収集します。

  デフォルトのレスポンスクラスは Zend_Controller_Response_Http で、 これは HTTP 環境での使用に適しています。

Zend_Controller の処理の流れは比較的シンプルです。 Zend_Controller_Front がリクエストを受け取り、 Zend_Controller_Router_Rewrite をコールして、 配送先となるコントローラ (そしてコントローラ内のアクション) を決定します。Zend_Controller_Router_Rewrite は URI を分解し、リクエストからコントローラ名とアクション名を取得します。 その後、Zend_Controller_Front はディスパッチループに突入します。 まず Zend_Controller_Dispatcher_Standard をコールしてそこにリクエストを渡し、 リクエストで指定されたコントローラとアクションを取得します (あるいはデフォルトを使用します)。 コントローラが終了すると、処理は Zend_Controller_Front に戻ります。リクエストのディスパッチ状態がリセットされ、 別のコントローラをディスパッチするように指示された場合は、 ループが続けられて次の配送処理が行われます。 それ以外の場合は、処理がそこで終了します。それ以外の場合は、 処理が終了します。