プラグイン導入コントローラにはプラグイン機構が組み込まれており、 コントローラの処理中にイベントが発生した際にユーザのコードをコールできます。 フロントコントローラは、プラグインブローカにユーザのプラグインを登録します。 そして、イベントメソッドがコールされた際に、 フロントコントローラに登録されているプラグインをプラグインブローカが実行します。 イベントメソッドは、抽象クラス Zend_Controller_Plugin_Abstract で定義されています。 ユーザが作成するプラグインクラスは、これを継承させます。
プラグインの書き方プラグインクラスを書くには、単に抽象クラス Zend_Controller_Plugin_Abstract をインクルードしてそれを継承するだけです。
Zend_Controller_Plugin_Abstract には抽象メソッドはありません。 つまり、上に示したイベントメソッドを、 プラグインクラスでかならず実装しなければならないわけではありません。 プラグインの作者が、必要なものだけを選んで実装できます。 Zend_Controller_Plugin_Abstract では、 リクエストオブジェクトやレスポンスオブジェクトをプラグインから操作できます。 それぞれ、 getRequest() メソッドおよび getResponse() メソッドを使用します。 プラグインの使用法プラグインクラスを登録するには、 Zend_Controller_Front::registerPlugin() をコールします。 これは、いつでも行うことができます。 次の例は、コントローラチェインでプラグインを使用する方法を示すものです。
他に何かの出力を行うアクションがなく、ひとつのアクションのみがコールされたとしましょう。 上のプラグインは、次のような出力を行います。
プラグインの取得と操作時には、プラグインの登録を解除したりプラグインの情報を取得したいこともあるでしょう。 フロントコントローラには、そのような場合のために次のメソッドが用意されています。
標準の配布パッケージに含まれるプラグインZend Framework の配布パッケージには、 エラー処理用のプラグインが標準で組み込まれています。 ActionStack(日本語)ActionStack プラグインは、リクエストをスタックで管理します。 postDispatch プラグインとして動作します。 現在のリクエストオブジェクトで既に転送先が指定されている (別のアクションがコールされている) 場合は、何も行いません。 転送されていない場合はスタックの最上位の要素を取り出し、 そのリクエストが指すアクションに転送します。 スタックの処理は LIFO (後入れ先出し) 方式で行います。 このプラグインをフロントコントローラから取得するには、 Zend_Controller_Front::getPlugin('Zend_Controller_Plugin_ActionStack') とします。プラグインオブジェクトを取得したら、 さまざまな仕組みを利用できるようになります。
さらに forward() メソッドが存在します。 このメソッドにはリクエストオブジェクトを渡し、 フロントコントローラにおける現在のリクエストオブジェクトの状態を ここで渡したオブジェクトの状態に設定します。 そして、リクエストを未ディスパッチ状態に戻します (ディスパッチループの次の処理に強制的に進ませます)。 Zend_Controller_Plugin_ErrorHandler(日本語)Zend_Controller_Plugin_ErrorHandler は、アプリケーションからスローされた例外を処理するためのプラグインです。 たとえば、指定したコントローラやアクションが見つからないといったエラーを処理します。 これは、MVC の例外についてのセクション で説明したメソッド群の代わりとして使用できます。 このプラグインが主に対象としているのは、次のような例外です。
言い換えると、ErrorHandler プラグインが想定しているのは、HTTP 404 型のエラー (ページが存在しない) と 500 型のエラー (内部エラー) ということになります。 他のプラグインで発生した例外の処理は、想定していません。 デフォルトでは、Zend_Controller_Plugin_ErrorHandler はデフォルトモジュールの ErrorController::errorAction() に処理を転送します。これを変更するには、以下のようなアクセス用メソッドを使用します。
さらに、コンストラクタの引数として連想配列を渡すこともできます。 この場合、その配列がそのまま setErrorHandler() に渡されます。 Zend_Controller_Plugin_ErrorHandler は postDispatch() フックとして登録され、 レスポンスオブジェクト に格納された例外を確認します。もし何かの例外が見つかったら、 事前に登録されているエラーハンドラアクションに処理を転送します。 エラーハンドラへのディスパッチ中に例外が発生した場合は、 このプラグインはフロントコントローラに例外をスローします。 その際に、レスポンスオブジェクトに格納された直近の例外を再度スローします。 404 ハンドラとしての ErrorHandler の使用ErrorHandler プラグインが捕捉するのは、 アプリケーションのエラーだけではありません。 コントローラチェインが次のコントローラクラスやアクションメソッドを 見つけられなかった場合に、404 ハンドラとして動作させることもできます。 そのためには、エラーコントローラ内で例外の型を調べる必要があります。 捕捉した例外は、リクエストで登録したオブジェクトの中に記録されます。 これを取得するには、 Zend_Controller_Action::_getParam('error_handler') を使用します。
エラーオブジェクトを取得したら、次に $errors->type でその型を調べます。 これは、次のいずれかとなります。
最初の3つの型であった場合に、404 ページを返せばいいわけです。
エラーハンドラで発生した礼儀を取得するには、 error_handler オブジェクトのプロパティ exception を使用します。
前回のレンダリング結果の扱いひとつのリクエストで複数のアクションにディスパッチする場合、 あるいはアクション内で render() を複数回コールする場合などは、 レスポンスオブジェクト内にすでに内容が格納されていることがあります。 これをうまく処理しないと、本当に必要な内容と それ以外の内容が混じってしまう恐れがあります。 そのような場合にページの中でエラー処理をしたい場合は、 特に何も手を加える必要はありません。 そのような内容をレンダリングしたくないという場合は、 ビューのレンダリング前に以前の内容を消去しておく必要があります。
プラグインの使用例Example #1 標準的な使用法
Example #2 別のエラーハンドラの設定
Example #3 アクセス用メソッドの使用
エラーコントローラの例エラーハンドラプラグインを使用するには、 エラーコントローラが必要です。以下にシンプルな例を示します。
Zend_Controller_Plugin_PutHandler(日本語)Zend_Controller_Plugin_PutHandlerは、 まるで POST リクエスト・ボディのようなリクエスト・パラメータに PUT リクエスト・ボディを配置するために、 ドロップイン・プラグインを提供します。 それはリクエストを調べます、そして、 PUT ならば、 生の PUT ボディを解析してリクエストに配置されるパラメータの配列にするためにparse_strを使います。 例えば、
'title' 及び 'body' パラメータを通常のリクエスト・パラメータとして受け取るために、 プラグインを登録します:
そして、コントローラ内でリクエストから PUT ボディー・パラメータに名前によるアクセスができます:
|