Documentation

アクションヘルパー - Zend_Controller

アクションヘルパー

導入

アクションヘルパーを使用すると、Zend_Controller_Action を継承した任意のアクションコントローラに対して 実行時やその他必要に応じて機能追加をすることができます。 アクションヘルパーの狙いは、 アクションコントローラに共通機能を追加するために いちいち抽象クラスを継承する手間を省くことにあります。

アクションヘルパーにはさまざまな使用法があります。 たとえば、Zend_View_HelperZend_Controller_Plugin と同じように、処理の仲買をするために用いることもできます。 アクションヘルパーは (Zend_View_Helper と同様に)、 必要になった時点で読み込むこともできますし、 リクエスト時 (起動時) やアクションコントローラの作成時 ( init()) で読み込むこともできます。詳細は、以下の使用例を参照ください。

ヘルパーの初期化

ヘルパーを初期化するにはいくつかの方法があります。 必要に応じて、またそのヘルパーの機能に応じて使い分けましょう。

ヘルパーブローカは、Zend_Controller_Action$_helper に格納されます。 このブローカを使用して、ヘルパーを取得したりコールしたりします。 以下のような方法があります。

  • 明示的に getHelper() を使用します。 ヘルパーの名前を指定すると、 そのヘルパーオブジェクトが返されます。

    1. $flashMessenger = $this->_helper->getHelper('FlashMessenger');
    2. $flashMessenger->addMessage('先ほどのリクエストで、あることをしました');
  • ヘルパーブローカの __get() 機能を使用すると、 まるでブローカのプロパティであるかのようにヘルパーを操作できます。

    1. $flashMessenger = $this->_helper->FlashMessenger;
    2. $flashMessenger->addMessage('先ほどのリクエストで、あることをしました');
  • たいていのアクションヘルパーは direct() メソッドを実装しており、 これはそのヘルパーのデフォルトメソッドをコールします。 FlashMessenger の例では、 addMessage() をコールします。

    1. $this->_helper->FlashMessenger('先ほどのリクエストで、あることをしました');

Note: これらの例は、すべて同じことを行っています。

ヘルパーのインスタンスを明示的に作成したいと考えるかもしれません。 たとえばアクションコントローラ以外からヘルパーを使用したいだとか、 すべてのアクションのヘルパーブローカに同じヘルパーを渡したいだとかいった場合です。 インスタンスを作成する方法は、通常の PHP のクラスと同じです。

ヘルパーブローカ

Zend_Controller_Action_HelperBroker がヘルパーオブジェクトやそのパスの登録に関する詳細を処理します。 また、必要に応じてそこからヘルパーを取得することができます。

ヘルパーをブローカに登録するには addHelper() を使用します。

  1. Zend_Controller_Action_HelperBroker::addHelper($helper);

もちろん、ヘルパーのインスタンスを作成してそれをブローカに渡すという作業は 時間とリソースを消費します。これらの作業の手間をほんの少し省くためのメソッドとして、 addPrefix()addPath() が用意されています。

  • addPrefix() はクラスのプレフィックスを受け取り、 それをもとにヘルパークラスのパスを決定します。 プレフィックスが、Zend Framework のクラス命名規約に沿っているものとみなして、 パスを決定します。

    1. // My/Action/Helpers/ にある、名前が My_Action_Helpers で始まるヘルパーを追加します
    2. Zend_Controller_Action_HelperBroker::addPrefix('My_Action_Helpers');
  • addPath() は、最初の引数にディレクトリ、 そして二番目の引数にクラスのプレフィックス (デフォルトは 'Zend_Controller_Action_Helper') を指定します。 これは、指定したディレクトリにある指定したプレフィックスのクラスを追加します。

    1. // Plugins/Helpers/ にある、名前が Helper で始まるヘルパーを追加します
    2. Zend_Controller_Action_HelperBroker::addPath('./Plugins/Helpers',
    3.                                              'Helper');

これらは静的メソッドなので、コントローラチェイン内の任意の場所で使用することができます。 これにより、必要に応じて動的にヘルパーを追加できることになります。

内部的には、ヘルパーブローカは PluginLoader のインスタンス を用いてパスを保持します。静的メソッド getPluginLoader() で PluginLoader を取得することもできますし、また独自の PluginLoader インスタンスを setPluginLoader() で設定することもできます。

ヘルパークラスがヘルパーブローカ内に存在するかどうかを調べるには hasHelper($name) を使用します。$name には、ヘルパーのショートネーム (プレフィックスを除いたもの) を指定します。

  1. // 'redirector' ヘルパーがブローカに登録されているかどうかを調べます
  2. if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
  3.     echo 'Redirector helper registered';
  4. }

ヘルパーブローかからヘルパーを取得する静的メソッドには、さらに getExistingHelper()getStaticHelper() のふたつがあります。 getExistingHelper() は、すでに起動されているか、 あるいは明示的にヘルパーブローカに登録されているヘルパーのみを取得します。 存在しない場合は例外をスローします。 getStaticHelper()getExistingHelper() と同じですが、 ヘルパースタックに登録されていないヘルパーについてはそのインスタンスを作成しようとします。 自分で設定をしたいヘルパーを取得するには getStaticHelper() がおすすめです。

どちらのメソッドも、引数はひとつだけです。 この引数 $name には、ヘルパーのショートネーム (プレフィックスを除いたもの) を指定します。

  1. // 'redirector' ヘルパーがブローカに登録されているかどうかを調べ、取得します
  2. if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
  3.     $redirector =
  4.         Zend_Controller_Action_HelperBroker::getExistingHelper('redirector');
  5. }
  6.  
  7. // あるいは、登録されているかどうかを気にせずに単純に取得します
  8. $redirector =
  9.     Zend_Controller_Action_HelperBroker::getStaticHelper('redirector');
  10. }

最後に、登録済みのヘルパーをブローカから削除するには removeHelper($name) を使用します。$name には、ヘルパーのショートネーム (プレフィックスを除いたもの) を指定します。

  1. // 'redirector' ヘルパーがブローカに登録されている場合にはそれを削除します
  2. if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
  3.     Zend_Controller_Action_HelperBroker::removeHelper('redirector')
  4. }

組み込みのアクションヘルパー

Zend Framework には、いくつかのアクションヘルパーがデフォルトで組み込まれています。 AJAX のオートコンプリート機能用のレスポンスを作成する AutoComplete、 アクションに応じてレスポンスの形式を変更する ContextSwitchAjaxContext、セッション単位のフラッシュメッセージを扱う FlashMessengerJSON 形式へのエンコードとレスポンスの送信を行う Json、 アプリケーション内から内部あるいは外部へのリダイレクトを実装できるようにする Redirector、そして コントローラ内でのビューオブジェクトの設定とビューのレンダリングを自動化する ViewRenderer です。

ActionStack

ActionStack ヘルパーは、リクエストをフロントコントローラの ActionStack プラグインに格納します。これにより、 リクエストの実行時にアクションのキューを作成しやすくなります。 このヘルパーは、アクションを追加する際に 新しいリクエストオブジェクトを指定するか アクション - コントローラ - モジュール の設定を指定するかのいずれかを用います。

Note: ActionStack ヘルパーを起動すると ActionStack プラグインが初期化される
ActionStack を起動すると、暗黙のうちに ActionStack プラグインを登録します。 つまり、この機能を使う際に明示的に ActionStack プラグインを登録する必要はないということです。

Example #1 アクション、コントローラおよびモジュール名によるタスクの追加

単純にアクションとコントローラそしてモジュール (およびオプションでリクエストパラメータ) を指定して Zend_Controller_Action::_forward() をコールするのが一番シンプルな方法です。

  1. class FooController extends Zend_Controller_Action
  2. {
  3.     public function barAction()
  4.     {
  5.         // 2 つのアクションをスタックに格納して
  6.         // /foo/baz/bar/baz をコールします
  7.         // (FooController::bazAction() にリクエスト変数 bar == baz を指定したもの)
  8.         $this->_helper->actionStack('baz',
  9.                                     'foo',
  10.                                     'default',
  11.                                     array('bar' => 'baz'));
  12.  
  13.         // /bar/bat のコール
  14.         // (BarController::batAction()) を追加します
  15.         $this->_helper->actionStack('bat', 'bar');
  16.     }
  17. }

Example #2 リクエストオブジェクトによるタスクの追加

時にはリクエストオブジェクトのオブジェクト指向的な部分が使いたいこともあるでしょう。 そんな場合はこのオブジェクトを ActionStack ヘルパーに渡すこともできます。

  1. class FooController extends Zend_Controller_Action
  2. {
  3.     public function barAction()
  4.     {
  5.         // 2 つのアクションをスタックに格納して
  6.         // /foo/baz/bar/baz をコールします
  7.         // (FooController::bazAction() にリクエスト変数 bar == baz を指定したもの)
  8.         $request = clone $this->getRequest();
  9.         // コントローラやモジュールは指定せず、現在の値を使用します
  10.         $request->setActionName('baz')
  11.                 ->setParams(array('bar' => 'baz'));
  12.         $this->_helper->actionStack($request);
  13.  
  14.         // /bar/bat のコール
  15.         // (BarController::batAction()) を追加します
  16.         $request = clone $this->getRequest();
  17.         // モジュールは指定せず、現在の値を使用します
  18.         $request->setActionName('bat')
  19.                 ->setControllerName('bar');
  20.         $this->_helper->actionStack($request);
  21.     }
  22. }

AutoComplete

多くの AJAX 用 javascript ライブラリでは、 オートコンプリート機能を提供しています。 これは、ユーザがタイプした内容にマッチする可能性のある候補の一覧を表示するものです。 AutoComplete ヘルパーは、 このような場合に使用できるレスポンスを返すためのものです。

オートコンプリート機能の実装方法は JS ライブラリによって異なるので、 AutoComplete では多くのライブラリで使用する共通機能を抽象化しています。 そして、個々のライブラリにあわせた実装を用意しています。 返り値の型は、JSON 形式の文字列の配列か JSON 形式の配列の配列 (内部の配列は、選択リストを作成する際に使用するメタデータの連想配列) あるいは HTML となります。

どの実装についての基本的な使用法は同じです。

  1. class FooController extends Zend_Controller_Action
  2. {
  3.     public function barAction()
  4.     {
  5.         // 何かの処理をします...
  6.  
  7.         // エンコードしたレスポンスを送信します
  8.         $this->_helper->autoCompleteDojo($data);
  9.  
  10.         // あるいは明示的に
  11.         $response = $this->_helper->autoCompleteDojo
  12.                                   ->sendAutoCompletion($data);
  13.  
  14.         // あるいは単純にオートコンプリート用のレスポンスを準備します
  15.         $response = $this->_helper->autoCompleteDojo
  16.                                   ->prepareAutoCompletion($data);
  17.     }
  18. }

デフォルトでは以下のような作業を行います。

  • レイアウト機能と ViewRenderer を無効にする。

  • 適切なレスポンスヘッダを設定する。

  • レスポンスボディにエンコード/フォーマットしたデータを設定する。

  • レスポンスを送信する。

このヘルパーでは次のようなメソッドが使用できます。

  • disableLayouts() は、レイアウト機能と ViewRenderer を無効にします。一般に、これは prepareAutoCompletion() の中でコールされます。

  • encodeJson($data, $keepLayouts = false) はデータを JSON 形式にエンコードし、オプションでレイアウト機能の有効/無効 を切り替えます。一般に、これは prepareAutoCompletion() の中でコールされます。

  • prepareAutoCompletion($data, $keepLayouts = false) は、各種具象実装にあわせてレスポンスデータをフォーマットし、 オプションでレイアウト機能の有効/無効を切り替えます。 返り値は実装によって異なります。

  • sendAutoCompletion($data, $keepLayouts = false) は、各種具象実装にあわせてフォーマットしたレスポンスデータを送信します。 これは、 prepareAutoCompletion() をコールしたあとでレスポンスを送信します。

  • direct($data, $sendNow = true, $keepLayouts = false) は、このヘルパーをヘルパーブローカのメソッドとしてコールする場合に使用します。 $sendNow フラグは、 sendAutoCompletion()prepareAutoCompletion() のどちらをコールするかを指定するものです。

現在 AutoComplete がサポートしている AJAX ライブラリは、Dojo と Scriptaculous です。

Dojo でのオートコンプリート

Dojo には、オートコンプリートのためだけのウィジェットはありません。 しかし、ComboBox と FilteringSelect のふたつのウィジェットがオートコンプリート機能を持っています。 どちらのウィジェットも、QueryReadStore を実装したデータを必要とします。詳細は » dojo.data のドキュメントを参照ください。

Zend Framework では、単純な数値添字の配列を AutoCompleteDojo ヘルパーに渡します。 そうすると、適切な形式の JSON オブジェクトを返します。

  1. // コントローラのアクション内で
  2. $this->_helper->autoCompleteDojo($data);

Example #3 Zend MVC を使用した、Dojo でのオートコンプリート

Zend MVC で Dojo によるオートコンプリートを使用するには、 いくつかの準備が必要です。オートコンプリートを使用したい ComboBox 用にフォームオブj稀有とを作成し、 オートコンプリートの結果を提供するためのコントローラアクションを作成し、 オートコンプリートアクションに接続するための 独自の QueryReadStore を作成し、 サーバ側でオートコンプリートを行わせるための javascript を作成することになります。

まずは、必要となる javascript を見ていきましょう。 Dojo は javascript によるオブジェクト指向プログラミングを行うための 完全なフレームワークで、ちょうど PHP における Zend Framework のようなものです。その中には、 ディレクトリ構造を用いて擬似的な名前空間を作成する機能もあります。 ここでは、Dojo の配布ファイルの Dojo ディレクトリと同じ階層に 'custom' ディレクトリを作成します。 そのディレクトリの中に TestNameReadStore.js という javascript ファイルを作成し、次のようなコードを書きます。

  1. dojo.provide("custom.TestNameReadStore");
  2. dojo.declare("custom.TestNameReadStore", dojox.data.QueryReadStore, {
  3.     fetch:function (request) {
  4.         request.serverQuery = { test:request.query.name };
  5.         return this.inherited("fetch", arguments);
  6.     }
  7. });

このクラスは、単に Dojo 自身の QueryReadStore クラスを継承したものです。継承元のクラス自体は抽象クラスです。 そこにリクエスト用のメソッドを定義し、'test' 要素に割り当てています。

次に、オートコンプリートを行うためのフォーム要素を作成します。

  1. class TestController extends Zend_Controller_Action
  2. {
  3.     protected $_form;
  4.  
  5.     public function getForm()
  6.     {
  7.         if (null === $this->_form) {
  8.             $this->_form = new Zend_Form();
  9.             $this->_form->setMethod('get')
  10.                 ->setAction(
  11.                     $this->getRequest()->getBaseUrl() . '/test/process'
  12.                 )
  13.                 ->addElements(array(
  14.                     'test' => array('type' => 'text', 'options' => array(
  15.                         'filters'        => array('StringTrim'),
  16.                         'dojoType'       => array('dijit.form.ComboBox'),
  17.                         'store'          => 'testStore',
  18.                         'autoComplete'   => 'false',
  19.                         'hasDownArrow'   => 'true',
  20.                         'label' => 'Your input:',
  21.                     )),
  22.                     'go' => array('type' => 'submit',
  23.                                   'options' => array('label' => 'Go!'))
  24.                 ));
  25.         }
  26.         return $this->_form;
  27.     }
  28. }

ここでは、単に 'test' と 'go' メソッドのみを持つフォームを作成します。 'test' メソッドは、特別な Dojo 固有の属性 dojoType、store、autoComplete および hasDownArrow を追加します。dojoType では、これから ComboBox を作成することを指定します。そして、それを 'testStore' のデータストア (キー 'store') にリンクします。詳細は後ほど説明します。 'autoComplete' を FALSE に設定することで、 最初にマッチしたものを自動選択するのではなく マッチしたものの一覧を表示するよう Dojo に指示します。 最後に 'hasDownArrow' でセレクトボックス風の下向き矢印を作ります。 これで、マッチしたものを表示したり隠したりできるようになります。

では、フォームを表示するためのメソッドと オートコンプリートの処理用のエンドポイントを作成してみましょう。

  1. class TestController extends Zend_Controller_Action
  2. {
  3.     // ...
  4.  
  5.     /**
  6.      * 最初のページ
  7.      */
  8.     public function indexAction()
  9.     {
  10.         $this->view->form = $this->getForm();
  11.     }
  12.  
  13.     public function autocompleteAction()
  14.     {
  15.         if ('ajax' != $this->_getParam('format', false)) {
  16.             return $this->_helper->redirector('index');
  17.         }
  18.         if ($this->getRequest()->isPost()) {
  19.             return $this->_helper->redirector('index');
  20.         }
  21.  
  22.         $match = trim($this->getRequest()->getQuery('test', ''));
  23.  
  24.         $matches = array();
  25.         foreach ($this->getData() as $datum) {
  26.             if (0 === strpos($datum, $match)) {
  27.                 $matches[] = $datum;
  28.             }
  29.         }
  30.         $this->_helper->autoCompleteDojo($matches);
  31.     }
  32. }

autocompleteAction() ではいくつかの作業を行っています。 まず、POST リクエストを受け取ったことを確実にし、 'format' パラメータの値を 'ajax' に設定します。 これにより、余計なクエリがアクションに送られることを減らします。 次に、'test' パラメータの内容を確認し、私たちのデータと比較します (ここでは、 getData() の実装は意図的に控えています。 何らかのデータソースを使用することになるでしょう)。 最後に、マッチした内容を AutoCompletion ヘルパーに送信します。

これでバックエンド側の準備はすべて整いました。 次に、ページのビュースクリプト側ではどうすればいいのかを考えてみましょう。 まず、データストアを用意しなければなりません。 次にフォームをレンダリングし、最後に適切な Dojo ライブラリ (使用するデータストアも含む) を読み込みます。 ビュースクリプトを見てみましょう。 適宜コメントを入れてあります。

  1. <?php // データストアの準備 ?>
  2. <div dojoType="custom.TestNameReadStore" jsId="testStore"
  3.     url="<?php echo $this->baseUrl() ?>/unit-test/autocomplete/format/ajax"
  4.     requestMethod="get"></div>
  5.  
  6. <?php // フォームのレンダリング ?>
  7. <?php echo $this->form ?>
  8.  
  9. <?php // Dojo 関連の CSS の、HTML head での読み込み ?>
  10. <?php $this->headStyle()->captureStart() ?>
  11. @import "<?php echo $this->baseUrl()
  12. ?>/javascript/dijit/themes/tundra/tundra.css";
  13. @import "<?php echo $this->baseUrl() ?>/javascript/dojo/resources/dojo.css";
  14. <?php $this->headStyle()->captureEnd() ?>
  15.  
  16. <?php // 必要な Dojo ライブラリを含む javascript の、
  17.    // HTML head での読み込み ?>
  18. <?php $this->headScript()
  19.         ->setAllowArbitraryAttributes(true)
  20.         ->appendFile($this->baseUrl() . '/javascript/dojo/dojo.js',
  21.             'text/javascript',
  22.             array('djConfig' => 'parseOnLoad: true'))
  23.         ->captureStart() ?>
  24. djConfig.usePlainJson=true;
  25. dojo.registerModulePath("custom","../custom");
  26. dojo.require("dojo.parser");
  27. dojo.require("dojox.data.QueryReadStore");
  28. dojo.require("dijit.form.ComboBox");
  29. dojo.require("custom.TestNameReadStore");
  30. <?php $this->headScript()->captureEnd() ?>

headStyle や headScript といったビューヘルパーのコールに注意しましょう。 これらはプレースホルダで、ビュースクリプトをレンダリングする際に HTML の head セクションとなります。

これで、Dojo のオートコンプリートを動作させるための準備がすべて整いました。

Scriptaculous でのオートコンプリート

» Scriptaculous は、所定の形式の HTML レスポンスを受け取ることを想定しています。

このライブラリで使用するヘルパーは 'AutoCompleteScriptaculous' です。 このヘルパーにデータの配列を渡せば、Ajax.Autocompleter に対応した形式の HTML レスポンスができあがります。

ContextSwitch および AjaxContext

ContextSwitch アクションヘルパーは、 リクエストに対してさまざまなレスポンスを返す機能を実現するためのものです。 AjaxContext ヘルパーは ContextSwitch をより特化したもので、 レスポンスを XmlHttpRequests で返す機能を提供します。

いずれかを有効にするには、コントローラに対して 「どのアクションがどのコンテキストに対応するのか」 を教えてやる必要があります。 やってきたリクエストがそのアクションで有効なコンテキストである場合、 ヘルパーが行う処理は次のようになります。

  • レイアウト機能が有効な場合に、それを無効にする。

  • 別のビューサフィックスを設定し、 コンテキストに応じて別のビュースクリプトを効率よく扱えるようにする。

  • コンテキストに応じて適切なレスポンスヘッダを送信する。

  • オプションで、指定したコールバックを実行して コンテキストの設定や後処理を行う。

たとえば、次のようなコントローラを考えてみましょう。

  1. class NewsController extends Zend_Controller_Action
  2. {
  3.     /**
  4.      * トップページは listAction() に転送します
  5.      */
  6.     public function indexAction()
  7.     {
  8.         $this->_forward('list');
  9.     }
  10.  
  11.     /**
  12.      * ニュースの一覧
  13.      */
  14.     public function listAction()
  15.     {
  16.     }
  17.  
  18.     /**
  19.      * ニュースの閲覧
  20.      */
  21.     public function viewAction()
  22.     {
  23.     }
  24. }

ここで、 listAction() の結果を XML 形式でも返せるようにしたくなったとしましょう。 わざわざ別のアクションを作らなくても、 XML でレスポンスを返すように指示することができます。

  1. class NewsController extends Zend_Controller_Action
  2. {
  3.     public function init()
  4.     {
  5.         $contextSwitch = $this->_helper->getHelper('contextSwitch');
  6.         $contextSwitch->addActionContext('list', 'xml')
  7.                       ->initContext();
  8.     }
  9.  
  10.     // ...
  11. }

これが何を行っているかというと、

  • レスポンスヘッダ 'Content-Type' を 'text/xml' にします。

  • ビューのサフィックスを 'xml.phtml' (あるいは別のサフィックスをを使っているなら 'xml.[your suffix]') に変更します。

さて、次は新しいビュースクリプト 'news/list.xml.phtml' を作成しましょう。これが XML の作成とレンダリングを行います。

あるリクエストがコンテキストスイッチを起動するかどうかを判断するために、 このヘルパーはリクエストオブジェクト内のトークンを調べます。 デフォルトでは 'format' というパラメータを調べることになっていますが、 これは変更することもできます。つまり、 ほとんどの場合は、リクエストに 'format' パラメータを追加するだけで コンテキストスイッチを行えるということです。

  • URL のパラメータで指定する場合: /news/list/format/xml (デフォルトのルーティング方式では、アクションに続けて任意の キー/値 のペアを指定できたことを思い出しましょう)

  • GET パラメータで指定する場合: /news/list?format=xml

ContextSwitch では任意のコンテキストを指定することができます。 つまり (もし存在するなら) サフィックスを自由に変更したり 送信するレスポンスヘッダを任意のものに変更したり、 任意のコールバックで初期化や後処理を行ったりができるということです。

デフォルトで使用できるコンテキスト

ContextSwitch ヘルパーで 使用できるデフォルトのコンテキストは、json と xml のふたつです。

  • JSONJSON コンテキストは、 'Content-Type' レスポンスヘッダを 'application/json' に設定し、 ビュースクリプトのサフィックスを 'json.phtml' とします。

    しかし、デフォルトではビュースクリプトは不要です。 これは、すべてのビュー変数を単純にシリアライズして JSON レスポンスを直接発行するものです。

    自動 JSON シリアライズ機能を使わないようにすることもできます。

    1. $this->_helper->contextSwitch()->setAutoJsonSerialization(false);
  • XMLXML コンテキストは、 'Content-Type' レスポンスヘッダを 'text/xml' に設定し、 ビュースクリプトのサフィックスを 'xml.phtml' とします。 このコンテキスト用に、新しいビュースクリプトを作成する必要があります。

独自のコンテキストの作成

デフォルトのコンテキストだけでは対応しきれないこともあるでしょう。 たとえば結果を YAML で返したり、PHP のシリアライズ文字列で返したり、 あるいは RSSATOM フィードで返したりといったようにです。 ContextSwitch を使用すればそれも可能です。

新たなコンテキストを追加する最も簡単な方法は addContext() メソッドを使用することです。 このメソッドの引数は 2 つで、コンテキストの名前と 設定の配列を指定します。設定には、以下のうちのひとつあるいは複数を指定します。

  • suffix: ViewRenderer で登録されているデフォルトのビューサフィックスの 前に追加するサフィックス。

  • headers: ヘッダ/値 のペアの配列で、レスポンスとともに送信したいもの。

  • callbacks: キー 'init' や 'post' を含む配列で、それぞれ コンテキストの初期化や後処理の際に使用する PHP コールバックを指定します。

    初期化コールバックは、ContextSwitch が コンテキストを検出した場合に実行されます。 これを使用して、任意のロジックを実行することができます。 たとえば JSON コンテキストでは、 このコールバックを使用して 自動 JSON シリアライズが有効な場合に ViewRenderer を無効化しています。

    後処理はアクションの postDispatch() で発生します。これを使用して、任意のロジックを実行することができます。 たとえば JSON コンテキストでは、このコールバックを使用して 自動 JSON シリアライズ機能が有効か無効かを調べています。 有効な場合はビュー変数を JSON にシリアライズしてレスポンスに送信し、 無効な場合は ViewRenderer を再度有効にします。

コンテキストを操作するメソッドには次のようなものがあります。

  • addContext($context, array $spec): 新しいコンテキストを追加する。 そのコンテキストが既に存在する場合は例外をスローします。

  • setContext($context, array $spec): 新しいコンテキストを追加、あるいは既存のコンテキストを上書きする。 addContext() と同じように指定します。

  • addContexts(array $contexts): 複数のコンテキストを一度に追加する。配列 $contexts は、コンテキスト/設定 のペアの配列となります。 既に存在するコンテキストを指定した場合は例外をスローします。

  • setContexts(array $contexts): 新しいコンテキストを追加、あるいは既存のコンテキストを上書きする。 addContexts() と同じように指定します。

  • hasContext($context): そのコンテキストが存在する場合に TRUE、存在しない場合に FALSE を返します。

  • getContext($context): 指定した名前のコンテキストを取得する。 addContext() で使用する設定とあわせた配列を返します。

  • getContexts(): すべてのコンテキストを取得する。 コンテキスト/設定 のペアの配列を返します。

  • removeContext($context): 指定した名前のコンテキストを削除する。成功した場合に TRUE、 そのコンテキストが見つからない場合に FALSE を返します。

  • clearContexts(): すべてのコンテキストを削除する。

アクションごとのコンテキストの設定

使用するコンテキストの設定には 2 通りの方法があります。 コントローラ内で手動で配列を作成する方法、 そして ContextSwitch のメソッドでそれを作成する方法です。

アクションとコンテキストの関連を追加するメソッドは addActionContext() です。 このメソッドには 2 つの引数を指定します。 ひとつはコンテキストを追加したいアクション、 もうひとつはコンテキスト名あるいはコンテキスト名の配列です。 たとえば、次のようなコントローラクラスを考えてみましょう。

  1. class FooController extends Zend_Controller_Action
  2. {
  3.     public function listAction()
  4.     {
  5.     }
  6.  
  7.     public function viewAction()
  8.     {
  9.     }
  10.  
  11.     public function commentsAction()
  12.     {
  13.     }
  14.  
  15.     public function updateAction()
  16.     {
  17.     }
  18. }

ここで、'list' アクションに XML コンテキストを、 そして 'comments' アクションに XML コンテキストと JSON コンテキストを追加してみることにします。これは init() メソッドで行います。

  1. class FooController extends Zend_Controller_Action
  2. {
  3.     public function init()
  4.     {
  5.         $this->_helper->contextSwitch()
  6.              ->addActionContext('list', 'xml')
  7.              ->addActionContext('comments', array('xml', 'json'))
  8.              ->initContext();
  9.     }
  10. }

あるいは、単純に配列プロパティ $contexts を設定することもできます。

  1. class FooController extends Zend_Controller_Action
  2. {
  3.     public $contexts = array(
  4.         'list'     => array('xml'),
  5.         'comments' => array('xml', 'json')
  6.     );
  7.  
  8.     public function init()
  9.     {
  10.         $this->_helper->contextSwitch()->initContext();
  11.     }
  12. }

このほうがオーバーヘッドが少なくなりますが、 書き間違える可能性もあります。

コンテキストの関連付けを行うメソッドには次のようなものがあります。

  • addActionContext($action, $context): ひとつあるいは複数のコンテキストを、あるアクションで使用できるようにする。 関連付けがすでに設定されている場合は、それに追記します。 $context は、単一のコンテキストか コンテキストの配列となります。

    コンテキストとして TRUE を指定すると、 すべてのコンテキストをそのアクションで使用できるようにします。

    $context に空の値を指定すると、 そのアクションではどのコンテキストも使用できないようにします。

  • setActionContext($action, $context): ひとつあるいは複数のコンテキストを、あるアクションで使用できるようにする。 関連付けがすでに設定されている場合は、指定したものでそれを置き換えます。 $context は、単一のコンテキストか コンテキストの配列となります。

  • addActionContexts(array $contexts): いくつかの アクション/コンテキスト のペアを一度に追加する。 $contexts は、アクション/コンテキスト のペアの連想配列です。これは addActionContext() へのプロキシとなります。つまり、既に別のペアが登録されている場合は そこに追記します。

  • setActionContexts(array $contexts): addActionContexts() と同様だが、既存の アクション/コンテキスト のペアは上書きする。

  • hasActionContext($action, $context): 特定のアクションにそのコンテキストが存在するかどうかを調べる。

  • getActionContexts($action = null): 指定したアクションのすべてのコンテキスト、 あるいはすべての アクション/コンテキスト のペアを返す。

  • removeActionContext($action, $context): ひとつあるいは複数のコンテキストを、指定したアクションから削除する。 $context は、単一のコンテキストか コンテキストの配列となります。

  • clearActionContexts($action = null): すべてのコンテキストを、指定したアクションから削除する。 あるいはすべてのアクションのすべてのコンテキストを削除する。

コンテキストスイッチの初期化

コンテキストスイッチを初期化するには、アクションコントローラで initContext() をコールする必要があります。

  1. class NewsController extends Zend_Controller_Action
  2. {
  3.     public function init()
  4.     {
  5.         $this->_helper->contextSwitch()->initContext();
  6.     }
  7. }

時には、使用するコンテキストを決めてしまいたいこともあるでしょう。 たとえば、コンテキストスイッチが起動したときには XML コンテキストだけを使わせたいという場合などです。 その場合は、そのコンテキストを initContext() に渡します。

  1. $contextSwitch->initContext('xml');

追加機能

さまざまなメソッドを使用することで、 ContextSwitch ヘルパーの挙動を変更することができます。 たとえば次のようなメソッドが存在します。

  • setAutoJsonSerialization($flag): デフォルトでは、JSON コンテキストはビュー変数をすべてシリアライズし、 JSON 記法にしたものをレスポンスとして返します。 レスポンスを自分で作成したい場合はこれをオフにしなければなりません。 これは、 initContext() をコールする前に行う必要があります。

    1. $contextSwitch->setAutoJsonSerialization(false);
    2. $contextSwitch->initContext();

    このフラグの値を取得するには getAutoJsonSerialization() を使用します。

  • setSuffix($context, $suffix, $prependViewRendererSuffix): このメソッドは、指定したコンテキストに対して 別のサフィックスを設定します。 3 番目の引数を使用すると、 ViewRenderer のサフィックスの前に 新しいサフィックスをつけるのかどうかを指定することができます。 このフラグはデフォルトで有効になっています。

    サフィックスに空の値を指定すると、 ViewRenderer のサフィックスのみを使用します。

  • addHeader($context, $header, $content): 指定したコンテキストにレスポンスヘッダを追加します。 $header はヘッダの名前で、 $content はそのヘッダに渡す値となります。

    各コンテキストは複数のヘッダを持つことができます。 addHeader() は、 そのヘッダをコンテキストのヘッダスタックに追加します。

    指定した $header がそのコンテキストに既に存在する場合は、 例外をスローします。

  • setHeader($context, $header, $content): setHeader()addHeader() とほぼ同じですが、 既存のコンテキストヘッダを上書きします。

  • addHeaders($context, array $headers): 指定したコンテキストに一度に複数のヘッダを追加します。 addHeader() へのプロキシとして動作するので、 そのヘッダがすでに存在する場合は例外をスローします。 $headers は ヘッダ/コンテキスト のペアの配列です。

  • setHeaders($context, array $headers.): addHeaders() と似ていますが、これは setHeader() へのプロキシとして動作し、 既存のヘッダは上書きします。

  • getHeader($context, $header): 指定したコンテキストのヘッダの値を取得します。 見つからない場合は NULL を返します。

  • removeHeader($context, $header): 指定したコンテキストの単一のヘッダを削除します。

  • clearHeaders($context, $header): 指定したコンテキストのすべてのヘッダを削除します。

  • setCallback($context, $trigger, $callback): 指定したコンテキストにおける指定したトリガーのコールバックを設定します。 トリガーに指定できる値は 'init' あるいは 'post' (それぞれ、コンテキストの初期化時と postDispatch 時を表します) です。 $callbackPHP のコールバックとして正しい形式でなければなりません。

  • setCallbacks($context, array $callbacks): 指定したコンテキストに複数のコールバックを設定します。 $callbacks は トリガー/コールバック のペアとなります。実際のところ、登録できるコールバックは ほとんどふたつだけで、初期化用のものと後処理用のものです。

  • getCallback($context, $trigger): 指定したコンテキストにおける指定したトリガーのコールバックを取得します。

  • getCallbacks($context): 指定したコンテキストにおけるすべてのコールバックを取得します。 トリガー/コールバック のペアを返します。

  • removeCallback($context, $trigger): 指定したコンテキストにおける指定したトリガーのコールバックを削除します。

  • clearCallbacks($context): 指定したコンテキストにおけるすべてのコールバックを削除します。

  • setContextParam($name): コンテキストスイッチが要求されたかどうかを調べるための リクエストパラメータを設定します。デフォルトは 'format' ですが、このアクセサを使用することで変更することができます。

    getContextParam() で、現在の値を取得することができます。

  • setAutoDisableLayout($flag): デフォルトでは、コンテキストスイッチが発生したときには レイアウト機能が無効になります。これは、 レイアウト機能は通常は普通のレスポンスの時に使用するものであって それ以外のコンテキストでは無意味だからです。 しかし、時にはレイアウト機能を使いたいこともあるでしょう (新しいコンテキスト用のレイアウトがある場合など)。 その場合は、 setAutoDisableLayout()FALSE を渡します。これは、 initContext() をコールするより 前に 行わなければなりません。

    このフラグの現在の値を取得するには、アクセサ getAutoDisableLayout() を使用します。

  • getCurrentContext() を使うと、 現在のコンテキストを取得することができます。 コンテキストスイッチが発生していない場合や initContext() の起動前にコールした場合は NULL を返します。

AjaxContext の機能

AjaxContext ヘルパーは ContextSwitch を継承したものです。 ContextSwitch の機能はすべて使用することができます。 しかし、いくつか重要な違いがあります。

まず、コンテキストを決めるアクションコントローラのプロパティは $ajaxable となります。これにより、 AJAX 用と通常の HTTP リクエスト用で別のコンテキストを使用できるようになります。 AjaxContext の *ActionContext()* 系のメソッドは、このプロパティに書き込みます。

次に、これは XmlHttpRequest が発生した場合にのみ起動します。 リクエストオブジェクトの isXmlHttpRequest() メソッドで判断します。したがって、たとえコンテキストパラメータ ('format') をリクエストで渡したとしても、そのリクエストが XmlHttpRequest でない場合はコンテキストスイッチが発生しません。

3 番目に、AjaxContextHTML コンテキストを追加します。 このコンテキストでは、サフィックスを 'ajax.phtml' として通常のリクエストのコンテキストと区別しています。 追加のヘッダは返しません。

Example #4 Ajax リクエストに対してアクションに応答させる

この例では、アクション 'view'、'form' および 'process' に対する AJAX リクエストにレスポンスを返させるようにしています。 最初のふたつ 'view' および 'form' では、HTML コード片を返してページを更新させます。最後の 'process' については JSON を返しています。

  1. class CommentController extends Zend_Controller_Action
  2. {
  3.     public function init()
  4.     {
  5.         $ajaxContext = $this->_helper->getHelper('AjaxContext');
  6.         $ajaxContext->addActionContext('view', 'html')
  7.                     ->addActionContext('form', 'html')
  8.                     ->addActionContext('process', 'json')
  9.                     ->initContext();
  10.     }
  11.  
  12.     public function viewAction()
  13.     {
  14.         // 単一のコメントを表示します
  15.         // AjaxContext の場合は comment/view.ajax.phtml
  16.         // を使用します
  17.     }
  18.  
  19.     public function formAction()
  20.     {
  21.         // 新規コメントの追加フォームをレンダリングします
  22.         // AjaxContext の場合は comment/form.ajax.phtml
  23.         // を使用します
  24.     }
  25.  
  26.     public function processAction()
  27.     {
  28.         // 新規コメントを処理します
  29.         // 結果を JSON で返します。結果をビュー変数に格納するだけで、
  30.         // JSON でそれを返してくれます
  31.     }
  32. }

クライアント側では、AJAX ライブラリからエンドポイント '/comment/view'、'/comment/form' そして '/comment/process' へリクエストを送ることになります。 その際に、'format' パラメータを '/comment/view/format/html'、'/comment/form/format/html' そして '/comment/process/format/json' のように指定します (あるいはクエリ文字列で "?format=json" のようにしてもかまいません)。

ライブラリ側で 'X-Requested-With: XmlHttpRequest' ヘッダが設定されていれば、 このアクションは適切な形式でレスポンスを返します。

FlashMessenger

導入

FlashMessenger ヘルパーは、 次のリクエストの際にユーザに見せる必要のあるメッセージを渡すためのものです。 この機能を実現するため、FlashMessengerZend_Session_Namespace を使用してメッセージを保管しています。 Zend_SessionZend_Session_Namespace を使用する際には、起動ファイル中で Zend_Session::start() を実行するようにしましょう (詳細な使用例は Zend Session のドキュメントを参照ください)。

基本的な使用例

以下の使用例は、もっとも基本的なフラッシュメッセンジャーの使用法を示すものです。 アクション /some/my がコールされると、フラッシュメッセージに "Record Saved!" が保存されます。そして、その次のアクション /some/my-next-request へのリクエストの際にそれを取得 (そして削除) します。

  1. class SomeController extends Zend_Controller_Action
  2. {
  3.     /**
  4.      * FlashMessenger
  5.      *
  6.      * @var Zend_Controller_Action_Helper_FlashMessenger
  7.      */
  8.     protected $_flashMessenger = null;
  9.  
  10.     public function init()
  11.     {
  12.         $this->_flashMessenger =
  13.             $this->_helper->getHelper('FlashMessenger');
  14.         $this->initView();
  15.     }
  16.  
  17.     public function myAction()
  18.     {
  19.         /**
  20.          * Zend_Controller_Action_Helper_FlashMessenger
  21.          * のインスタンスを必要に応じて取得するための
  22.          * デフォルトメソッド
  23.          */
  24.         $this->_flashMessenger->addMessage('Record Saved!');
  25.     }
  26.  
  27.     public function myNextRequestAction()
  28.     {
  29.         $this->view->messages = $this->_flashMessenger->getMessages();
  30.         $this->render();
  31.     }
  32. }

JSON

JSON レスポンスは、AJAX リクエストでデータセットを受け取るときの 形式としてすっかり定着しました。JSON はクライアント側で すぐにパースすることができ、すばやく実行できます。

JSON アクションヘッダは次のようなことを行います。

  • レイアウト機能が有効になっている場合はそれを無効にする。

  • 任意で、オプションの配列を Zend_Json::encode() の 2 番目の引数として渡す。 このオプションの配列で、レイアウト機能を有効にしたり Zend_Json_Expr によるエンコードを有効にしたりする。

    1. $this->_helper->json($data, array('enableJsonExprFinder' => true));
  • ViewRenderer が有効になっている場合にそれを無効にする。

  • 'Content-Type' レスポンスヘッダを 'application/json' に設定する。

  • デフォルトでレスポンスをすぐに返す。 アクションの実行が終了するのを待たない。

使い方は簡単です。ヘルパーブローカのメソッドとしてコールするか、 encodeJson() あるいは sendJson() といったメソッドをコールするだけです。

  1. class FooController extends Zend_Controller_Action
  2. {
  3.     public function barAction()
  4.     {
  5.         // 何らかの処理をして...
  6.         // JSON レスポンスを返します
  7.         $this->_helper->json($data);
  8.  
  9.         // あるいは...
  10.         $this->_helper->json->sendJson($data);
  11.  
  12.         // あるいは JSON を取得します
  13.         $json = $this->_helper->json->encodeJson($data);
  14.     }
  15. }

Note: レイアウトの維持
JSON レスポンスでレイアウト機能を使用したい場合 (いくつかの JSON レスポンスをひとつにまとめて処理するなど) のために、JSON ヘルパーの各メソッドには 2 番目の引数が用意されています。 この引数はオプションのフラグで、レイアウト機能を有効あるいは無効にします。 TRUE を渡すと、レイアウト機能を有効なままにします。

  1. $this->_helper->json($data, true);
オプションで、2 番目の引数に配列を渡すことができます。 この配列には、keepLayouts のオプションを含むさまざまなオプションを指定することができます。
  1. $this->_helper->json($data, array('keepLayouts' => true);

Note: Zend_Json_Expr を使用したエンコードの有効化
Zend_Json::encode() は、ネイティブ JSON 式を Zend_Json_Expr オブジェクトを使用してエンコードすることができます。 このオプションはデフォルトでは無効になっています。 有効にするには、enableJsonExprFinder オプションに TRUE を設定します。

  1. $this->_helper->json($data, array('enableJsonExprFinder' => true);
これを行いたい場合は、2 番目の引数に必ず配列を渡さなければなりません。 また、たとえば keepLayouts のような他のオプションと組み合わせることもできます。 これらすべてのオプションが Zend_Json::encode() に渡されます。
  1. $this->_helper->json($data, array(
  2.     'enableJsonExprFinder' => true,
  3.     'keepLayouts'          => true,
  4. ));

Redirector

導入

Redirector ヘルパーは、 アプリケーション内で必要となるリダイレクト処理用のオブジェクトとして使用します。 _redirect() メソッドと比べた場合の利点としては、 サイト全体で使用する設定を事前に組み込んでおけることがあります。また、 Zend_Controller_Action::_forward() の場合と同様に、組み込みのインターフェイス gotoSimple($action, $controller, $module, $params) が使用できることも利点となります。

Redirector では、 リダイレクトの設定を行うメソッドとして次のようなものが用意されています。

  • setCode() を使用して、 リダイレクトの際に使用する HTTP レスポンスコードを設定します。

  • setExit() を使用して、 リダイレクトの後で強制的に exit() を実行させるようにします。 デフォルトは TRUE です。

  • setGotoSimple() を使用して、 gotoSimple() に何も渡されなかったときのデフォルトの URL を設定します。 Zend_Controller_Action::_forward()API である setGotoSimple($action, $controller = null, $module = null, array $params = array()) を使用します。

  • setGotoRoute() を使用して、 登録済みのルートにもとづいた URL を設定します。 キー/値 のペアの配列とルート名を渡し、 それをもとにルートの型と定義から URL を作成します。

  • setGotoUrl() を使用して、 gotoUrl() に何も渡されなかったときのデフォルトの URL を設定します。 URL を表す文字列を受け取ります。

  • setPrependBase() を使用して、 setGotoUrl()gotoUrl() あるいは gotoUrlAndExit() で指定した URL の前にリクエストのベース URL を追加します。

  • setUseAbsoluteUri() を使用すると、 Redirector がリダイレクトの際に絶対 URI を使用するようになります。 このオプションを設定すると、 $_SERVER['HTTP_HOST']$_SERVER['SERVER_PORT']、そして $_SERVER['HTTPS'] の内容をもとにして リダイレクト用の完全な URI を作成します。 このオプションのデフォルト値はオフですが、 将来のリリースではデフォルトで有効になるかもしれません。

さらに、実際のリダイレクトを行うためのメソッドとして以下のものが用意されています。

  • gotoSimple() は、 setGotoSimple() ( _forward() 風の API) を用いて作成した URL にリダイレクトします。

  • gotoRoute() は、 setGotoRoute() (ルートの作成) を用いて作成した URL にリダイレクトします。

  • gotoUrl()setGotoUrl() (URL 文字列の指定) を用いて作成した URL にリダイレクトします。

リダイレクト先の URL を知るには getRedirectUrl() を使用します。 これはいつでも使用できます。

基本的な使用例

Example #5 オプションの設定

この例ではデフォルトのオプションを少し変更します。 HTTP ステータスコードを 303 にし、リダイレクト後に exit() しないようにして、そしてリダイレクトの際のデフォルト URL を指定しています。

  1. class SomeController extends Zend_Controller_Action
  2. {
  3.     /**
  4.      * Redirector - defined for code completion
  5.      *
  6.      * @var Zend_Controller_Action_Helper_Redirector
  7.      */
  8.     protected $_redirector = null;
  9.  
  10.     public function init()
  11.     {
  12.         $this->_redirector = $this->_helper->getHelper('Redirector');
  13.  
  14.         // リダイレクタのデフォルトのオプションを設定します
  15.         // このオブジェクトはヘルパーブローカに登録されるので、
  16.         // これ以降のすべてのアクションで有効となります
  17.         $this->_redirector->setCode(303)
  18.                           ->setExit(false)
  19.                           ->setGotoSimple("this-action",
  20.                                           "some-controller");
  21.     }
  22.  
  23.     public function myAction()
  24.     {
  25.         /* 何かを行います */
  26.  
  27.         // 先ほど登録した URL にリダイレクトし、その後で
  28.         // exit() します
  29.         $this->_redirector->redirectAndExit();
  30.         return; // 決してここには到達しません
  31.     }
  32. }

Example #6 デフォルト設定の使用

この例ではデフォルト設定を使用しています。 つまり、リダイレクトするとすぐに exit() が実行されるということです。

  1. // 別の例
  2. class AlternativeController extends Zend_Controller_Action
  3. {
  4.     /**
  5.      * Redirector - defined for code completion
  6.      *
  7.      * @var Zend_Controller_Action_Helper_Redirector
  8.      */
  9.     protected $_redirector = null;
  10.  
  11.     public function init()
  12.     {
  13.         $this->_redirector = $this->_helper->getHelper('Redirector');
  14.     }
  15.  
  16.     public function myAction()
  17.     {
  18.         /* 何かを行います */
  19.  
  20.         $this->_redirector
  21.             ->gotoUrl('/my-controller/my-action/param1/test/param2/test2');
  22.         return; // リダイレクト後に自動的に exit() されるので、決してここには到達しません
  23.     }
  24. }

Example #7 goto() での _forward() API の使用

gotoSimple()API は、 Zend_Controller_Action::_forward() と同じ形式です。違う点は、このメソッドは渡されたパラメータから URL を作成し、デフォルトルータのデフォルトフォーマットである :module/:controller/:action/* を使用するということです。 また、アクションチェインではなくリダイレクトを行います。

  1. class ForwardController extends Zend_Controller_Action
  2. {
  3.     /**
  4.      * Redirector - defined for code completion
  5.      *
  6.      * @var Zend_Controller_Action_Helper_Redirector
  7.      */
  8.     protected $_redirector = null;
  9.  
  10.     public function init()
  11.     {
  12.         $this->_redirector = $this->_helper->getHelper('Redirector');
  13.     }
  14.  
  15.     public function myAction()
  16.     {
  17.         /* 何かを行います */
  18.  
  19.         // 現在のモジュールの 'my-controller' コントローラの
  20.         // 'my-action' アクションにリダイレクトします。
  21.         // パラメータは param1 => test、param2 => test2 となります。
  22.         $this->_redirector->gotoSimple('my-action',
  23.                                        'my-controller',
  24.                                        null,
  25.                                        array('param1' => 'test',
  26.                                              'param2' => 'test2'
  27.                                              )
  28.                                        );
  29.     }
  30. }

Example #8 gotoRoute() でのルートアセンブリの使用

次の例は、ルータassemble() メソッドを使用して、 パラメータで指定した連想配列に基づく URL を作成しています。 次のようなルートが登録されているものと仮定します。

  1. $route = new Zend_Controller_Router_Route(
  2.     'blog/:year/:month/:day/:id',
  3.     array('controller' => 'archive',
  4.           'module' => 'blog',
  5.           'action' => 'view')
  6. );
  7. $router->addRoute('blogArchive', $route);

year を 2006、month を 4、day を 24、そして ID を 42 として配列を渡すと、結果の URL/blog/2006/4/24/42 となります。

  1. class BlogAdminController extends Zend_Controller_Action
  2. {
  3.     /**
  4.      * Redirector - defined for code completion
  5.      *
  6.      * @var Zend_Controller_Action_Helper_Redirector
  7.      */
  8.     protected $_redirector = null;
  9.  
  10.     public function init()
  11.     {
  12.         $this->_redirector = $this->_helper->getHelper('Redirector');
  13.     }
  14.  
  15.     public function returnAction()
  16.     {
  17.         /* 何かを行います */
  18.  
  19.         // blog の過去記事にリダイレクトします。URL は
  20.         // /blog/2006/4/24/42 になります。
  21.         $this->_redirector->gotoRoute(
  22.             array('year' => 2006,
  23.                   'month' => 4,
  24.                   'day' => 24,
  25.                   'id' => 42),
  26.             'blogArchive'
  27.         );
  28.     }
  29. }

ViewRenderer

導入

ViewRenderer ヘルパーは、 以下のような要件を満たすために作られたものです。

  • コントローラ内でいちいちビューオブジェクトのインスタンスを 作成しなくても済むようにする。 ビューオブジェクトは自動的にコントローラに登録されます。

  • ビュースクリプトやヘルパー、そしてフィルタのパスを 現在のモジュールに基づいて自動的に設定し、 モジュール名をヘルパーやフィルタのクラス名の先頭に自動的に関連付ける。

  • すべてのコントローラとアクションで使用できる グローバルなビューオブジェクトを作成する。

  • すべてのコントローラで使用する、 デフォルトのビューレンダリングオプションを設定できるようにする。

  • 何も指定しなくても、 自動的にビュースクリプトをレンダリングできる機能を追加する。

  • ビューの基底パスやビュースクリプトのパスを 独自に指定できるようにする。

Note: _forward()redirect()、 あるいは手動での render() を行う場合は、 自動レンダリングは不要です。これらの処理を行う場合は、 出力を自前で行うことを ViewRenderer に対して指示します。

Note: ViewRenderer はデフォルトで有効になっています。 これを無効にするには、フロントコントローラのパラメータ noViewRenderer を指定する ($front->setParam('noViewRenderer', true);) か、 あるいはヘルパーブローカからヘルパーを削除 ( Zend_Controller_Action_HelperBroker::removeHelper('viewRenderer')) します。
フロントコントローラでのディスパッチ処理の前に ViewRenderer の設定を変更したい場合は、 次のいずれかの方法を使用します。

  • 独自の ViewRenderer のインスタンスを作成し、 ヘルパーブローカにそれを渡して登録する。

    1. $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
    2. $viewRenderer->setView($view)
    3.              ->setViewSuffix('php');
    4. Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
  • ViewRenderer オブジェクトを、 ヘルパーブローカから必要に応じて作成、取得する。

    1. $viewRenderer =
    2.     Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
    3. $viewRenderer->setView($view)
    4.              ->setViewSuffix('php');

API

もっとも基本的な使用法は、単に ViewRenderer のインスタンスを作成してそれをヘルパーブローカに渡すというものです。 インスタンスの作成と登録を一度に行うには、ヘルパーブローカの getStaticHelper() メソッドを使用するのがいちばん簡単です。

  1. Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');

アクションコントローラのインスタンスが最初に作成されたときに、 ViewRenderer がビューオブジェクトのインスタンスを作成します。 コントローラのインスタンスが作成されるたびに、ViewRendererinit() がコールされます。 ここでアクションコントローラのビュープロパティを設定し、 現在のモジュールからの相対パスを指定して addScriptPath() をコールします。 これは現在のモジュール名に基づいたプレフィックスをクラス名の先頭につけてコールされるので、 ヘルパーやフィルタのクラスをモジュール内で効率的に管理することができます。

postDispatch() がコールされるたびに、現在のアクションの render() を自動的にコールします。

例として、次のようなクラスを考えてみましょう。

  1. // foo モジュールのコントローラクラス
  2. class Foo_BarController extends Zend_Controller_Action
  3. {
  4.     // デフォルトで bar/index.phtml をレンダリングするので、特に何もする必要はありません
  5.     public function indexAction()
  6.     {
  7.     }
  8.  
  9.     // 変数 'foo' の値を 'bar' に設定して bar/populate.phtml をレンダリングします
  10.     // ビューオブジェクトは既に preDispatch() で定義されているので、既に使用可能です
  11.     public function populateAction()
  12.     {
  13.         $this->view->foo = 'bar';
  14.     }
  15. }
  16.  
  17. ...
  18.  
  19. // ビュースクリプトの中では、たとえば次のように書きます
  20. $this->foo(); // Foo_View_Helper_Foo::foo() をコールします

ViewRenderer には、 ビューのオプションを取得したり設定したりするためのメソッドも豊富に用意されています。

  • setView($view)ViewRenderer が使用するビューオブジェクトを設定します。 これは、クラスのプロパティ $view の値を設定します。

  • setNeverRender($flag = true) を使用すると、自動レンダリング機能を全体的に (すべてのコントローラに対して)無効にしたり有効にしたりできます。 TRUE を指定すると、そのコントローラの postDispatch() では render() をコールしなくなります。 getNeverRender() は、現在の設定を取得します。

  • setNoRender($flag = true) を使用すると、自動レンダリングを無効にしたり有効にしたりできます。 TRUE を指定すると、現在のコントローラの postDispatch() では render() をコールしなくなります。 この設定は、 preDispatch() がコールされるたびにいったんリセットされます (つまり、自動レンダリングを無効にしたいすべてのコントローラで 個々にこれを設定する必要があるということです)。 getNoRender() は、現在の設定を取得します。

  • setNoController($flag = true) を使用すると、 render() がコントローラ名のサブディレクトリにあるアクションスクリプトを 読みにいかなくすることができます (デフォルトでは読みにいきます)。 getNoController() は、現在の設定を取得します。

  • setNeverController($flag = true)setNoController() と似ていますが、 こちらは全体に影響を与えます。つまり、 ディスパッチ処理を行っても設定はリセットされません。 getNeverController() は、現在の設定を取得します。

  • setScriptAction($name) を使用すると、レンダリングするアクションスクリプトを指定することができます。 $name は、スクリプト名から拡張子を除いたもの (そして、noController が指定されていない限り、 コントローラのディレクトリ名も除いたもの) となります。 指定しなかった場合は、リクエストオブジェクト内のアクションに基づいた名前の ビュースクリプトを探します。 getScriptAction() は、現在の設定を取得します。

  • setResponseSegment($name) を使用すると、レンダリング結果を出力する レスポンスオブジェクトのセグメント名を指定することができます。 指定しなかった場合は、デフォルトのセグメントにレンダリングします。 getResponseSegment() は、現在の設定を取得します。

  • initView($path, $prefix, $options) は、ビューの基底パスを指定します。 また、ヘルパースクリプトとフィルタスクリプトの先頭につけるクラスプレフィックスや ViewRenderer のオプションも設定します。 オプションには、 neverRendernoRendernoControllerscriptAction および responseSegment のいずれかのフラグを指定します。

  • setRender($action = null, $name = null, $noController = false) を使用すると、scriptActionresponseSegment そして noController のいずれかまたは複数を 一度に指定することができます。 direct() はこのメソッドのエイリアスで、コントローラ内から簡単にコールすることができます。

    1. // 現在のアクションスクリプトではなく 'foo' をレンダリングします
    2. $this->_helper->viewRenderer('foo');
    3.  
    4. // form.phtml の内容をレスポンスセグメント 'html' にレンダリングします。
    5. // コントローラのビュースクリプト用サブディレクトリは使用しません。
    6. $this->_helper->viewRenderer('form', 'html', true);

    Note: setRender() および direct() は、実際にはビュースクリプトをレンダリングしません。 実際にレンダリングを行うのは postDispatch()render() で、 それらのメソッドに対するヒントを指示するだけです。

コンストラクタのオプションとして、 ビューオブジェクトを渡したり ViewRenderer のオプションを渡したりすることができます。 このオプションで指定できるのは、 initView() で説明したフラグと同じものです。

  1. $view    = new Zend_View(array('encoding' => 'UTF-8'));
  2. $options = array('noController' => true, 'neverRender' => true);
  3. $viewRenderer =
  4.     new Zend_Controller_Action_Helper_ViewRenderer($view, $options);

さらに追加のメソッドがあり、 ビューオブジェクトで使用するビューの基底パスを変更することができます。 また、ビュースクリプトが自動レンダリングを行う際に使用するパスも変更することができます。 これらのメソッドでは、以下のプレースホルダのいずれかあるいは複数が使用できます。

  • :moduleDir は、現在のモジュールの基底ディレクトリを指します (規約では、これはモジュールのコントローラディレクトリの親ディレクトリとなります)。

  • :module は、現在のモジュール名を指します。

  • :controller は、現在のコントローラ名を指します。

  • :action は、現在のアクション名を指します。

  • :suffix は、ビュースクリプトのサフィックス ( setViewSuffix() で設定したもの) を指します。

パス指定を制御するメソッドは次のとおりです。

  • setViewBasePathSpec($spec) は、ビューオブジェクトを追加する際に使用する基底パスを 決める際に使用するパス指定を変更します。 デフォルトの設定は :moduleDir/views です。 現在の設定を取得するには getViewBasePathSpec() を使用します。

  • setViewScriptPathSpec($spec) は、個々のビュースクリプトのパス (からビュースクリプトの基底パスを除いた部分) を決める際に使用するパス指定を変更します。 デフォルトの設定は :controller/:action.:suffix です。 現在の設定を取得するには getViewScriptPathSpec() を使用します。

  • setViewScriptPathNoControllerSpec($spec) は、noController が有効な場合に 個々のビュースクリプトのパス (からビュースクリプトの基底パスを除いた部分) を決める際に使用するパス指定を変更します。 デフォルトの設定は :action.:suffix です。 現在の設定を取得するには getViewScriptPathNoControllerSpec() を使用します。

パス指定をよりきめ細かく行うには、 Zend_Filter_Inflector を使用します。実は、ViewRenderer はパスのマッピングを行う際に既にインフレクタを使用しています。 インフレクタに手を入れたい (独自のインフレクタを使用したり、 デフォルトのインフレクタに手を加えたりしたい) 場合は、 以下のメソッドを使用します。

  • getInflector() は、インフレクタを取得します。 まだ ViewRenderer にインフレクタが存在しない場合は、 デフォルトの規則にもとづいたインフレクタを作成します。

    デフォルトでは、サフィックスやモジュールディレクトリへの参照に静的ルールを使用します。 また静的な対象を使用します。これにより、さまざまな ViewRenderer のプロパティから 動的にインフレクタを変更できるようになります。

  • setInflector($inflector, $reference) は、 ViewRenderer で使用する独自のインフレクタを設定します。 $referenceTRUE の場合は、 対象だけでなくサフィックスやモジュールディレクトリも ViewRenderer のプロパティへの静的な参照とします。

Note: デフォルトの検索方式
ViewRenderer は、 パスの正規化を行ってビュースクリプトによる検索を簡単にします。 デフォルトのルールは次のようなものです。

  • :module: MixedCase および camelCase 形式の単語がダッシュで分割され、 すべて小文字になります。たとえば "FooBarBaz" は "foo-bar-baz" となります。

    内部的には、インフレクタはフィルタ Zend_Filter_Word_CamelCaseToDash および Zend_Filter_StringToLower を使用します。

  • :controller: MixedCase および camelCase 形式の単語がダッシュで分割され、 アンダースコアはディレクトリ区切り文字に変換され、 すべて小文字になります。たとえば "FooBar" は "foo-bar" となり、そして "FooBar_Admin" は "foo-bar/admin" となります。

    内部的には、インフレクタはフィルタ Zend_Filter_Word_CamelCaseToDashZend_Filter_Word_UnderscoreToSeparator および Zend_Filter_StringToLower を使用します。

  • :action: MixedCase および camelCase 形式の単語がダッシュで分割され、 英数字以外の文字はダッシュに変換され、 すべて小文字になります。たとえば "fooBar" は "foo-bar" となり、"foo-barBaz" は "foo-bar-baz" となります。

    内部的には、インフレクタはフィルタ Zend_Filter_Word_CamelCaseToDashZend_Filter_PregReplace および Zend_Filter_StringToLower を使用します。

ViewRenderer API の最後に紹介するのは、 実際にビュースクリプトのパスを決定するメソッドと ビューのレンダリングを行うメソッドです。以下をご覧ください。

  • renderScript($script, $name) は、指定したパスのスクリプトをレンダリングします。 オプションで、パスセグメントの名前を指定することもできます。 このメソッドを使用する際には、ViewRenderer はスクリプト名を自動的に決定することはありません。 そのかわりに、$script で指定された内容を直接 ビューオブジェクトの render() メソッドに渡します。

    Note: レスポンスオブジェクトにビューがレンダリングされると、 自動的に noRender を設定します。 これにより、同じビュースクリプトを間違って複数回レンダリングしてしまうことを防ぎます。

    Note: デフォルトでは、 Zend_Controller_Action::renderScript()ViewRendererrenderScript() メソッドへのプロキシとなります。

  • getViewScript($action, $vars) は、渡されたアクションや $vars で指定した変数の値に基づいてビュースクリプトのパスを作成します。 $vars 配列のキーは、パスを指定するためのキー ('moduleDir'、'module'、'controller'、'action' および 'suffix') のいずれかとなります。渡された変数の値をもとにしてパスを作成します。 なにも渡されなかった場合は、現在のリクエストの内容をもとにしてパスを作成します。

    getViewScript() は、noController フラグの内容によって viewScriptPathSpec あるいは viewScriptPathNoControllerSpec のいずれかを使用します。

    モジュール名やコントローラ名、アクション名にあらわれる 単語の区切りは、ダッシュ ('-') に置き換えられます。 したがって、たとえばコントローラ名が 'foo.bar' でアクション名が 'baz:bat' だったとすると、 デフォルトのパス指定をもとにしたビュースクリプトのパスは 'foo-bar/baz-bat.phtml' となります。

    Note: デフォルトでは、 Zend_Controller_Action::getViewScript()ViewRenderergetViewScript() メソッドへのプロキシとなります。

  • render($action, $name, $noController) は、まず $name あるいは $noController が指定されているかどうかを調べます。 指定されている場合は、ViewRenderer の対応するフラグ (それぞれ responseSegment と noController) を設定します。 次に、$action 引数が指定されていれば、 それを getViewScript() に渡します。 最後に、取得したビュースクリプトのパスを renderScript() に渡します。

    Note: render() を使用する際には、その副作用に注意しましょう。 レスポンスセグメント名や noController フラグに指定した内容は、そのオブジェクト内で残り続けます。 さらに、レンダリングが完了した際に noRender も設定されます。

    Note: デフォルトでは、 Zend_Controller_Action::render()ViewRendererrender() メソッドへのプロキシとなります。

  • renderBySpec($action, $vars, $name) は、パス指定用の変数を渡してビュースクリプトのパスを決定します。 $action および $vars の内容を getScriptPath() に、そしてその結果得られたスクリプトのパスと $namerenderScript() に渡します。

基本的な使用例

Example #9 基本的な使用法

最も基本的な使用法は、起動ファイル内で ViewRenderer を作成してヘルパーブローカに登録し、 アクションメソッドで変数の値を設定するというものです。

  1. // 起動ファイル内で
  2. Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
  3.  
  4. ...
  5.  
  6. // 'foo' モジュールの 'bar' コントローラ
  7. class Foo_BarController extends Zend_Controller_Action
  8. {
  9.     // デフォルトで bar/index.phtml をレンダリングするので、特に何もする必要はありません
  10.     public function indexAction()
  11.     {
  12.     }
  13.  
  14.     // 変数 'foo' の値を 'bar' に設定して bar/populate.phtml をレンダリングします
  15.     // ビューオブジェクトは既に preDispatch() で定義されているので、既に使用可能です
  16.     public function populateAction()
  17.     {
  18.         $this->view->foo = 'bar';
  19.     }
  20.  
  21.     // 何もレンダリングせずに別のアクションに転送します
  22.     // 転送先のアクションで何らかのレンダリングを行います
  23.     public function bazAction()
  24.     {
  25.         $this->_forward('index');
  26.     }
  27.  
  28.     // 何もレンダリングせず別の場所にリダイレクトします
  29.     public function batAction()
  30.     {
  31.         $this->_redirect('/index');
  32.     }
  33. }

Note: 命名規約: コントローラ名やアクション名の単語の区切り
コントローラやアクションの名前が複数の単語からなるものである場合、 ディスパッチャには、特定のパスや区切り文字を使用して単語を区切った URL を指定しなければなりません。 ViewRenderer は、コントローラ名の中にあるパス区切り文字を 実際のパス区切り文字 ('/') に置き換え、単語区切り文字をダッシュ ('-') に置き換えてパスを作成します。したがって、 アクション /foo.bar/baz.bat をコールすると FooBarController.phpFooBarController::bazBatAction() へディスパッチされ、 foo-bar/baz-bat.phtml をレンダリングすることになります。 また、アクション /bar_baz/baz-bat をコールすると Bar/BazController.php (パス区切り文字に注意) の Bar_BazController::bazBatAction() へディスパッチされ、bar/baz/baz-bat.phtml をレンダリングすることになります。
二番目の例では、モジュールはデフォルトモジュールのままであることに注意しましょう。 しかし、パス区切り文字があるために、 Bar/BazController.php にある Bar_BazController を受け取ることになります。 ビューレンダラはコントローラのディレクトリ階層を模倣します。

Example #10 自動レンダリングの無効化

アクションやコントローラによっては、自動レンダリングを無効にしたいこともあるでしょう。 たとえば、HTML 以外 (XMLJSON など) を出力したい場合や 単に何も出力したくない場合などです。 そんな場合には以下のいずれかの方法を使用します。 つまり、すべての自動レンダリングを無効にする ( setNeverRender()) か、あるいは現在のアクションでだけ 自動レンダリングを無効にする ( setNoRender()) かです。

  1. // Bar モジュールの Baz コントローラクラス
  2. class Bar_BazController extends Zend_Controller_Action
  3. {
  4.     public function fooAction()
  5.     {
  6.         // このアクションでは自動レンダリングを行いません
  7.         $this->_helper->viewRenderer->setNoRender();
  8.     }
  9. }
  10.  
  11. // Bar モジュールの Bat コントローラクラス
  12. class Bar_BatController extends Zend_Controller_Action
  13. {
  14.     public function preDispatch()
  15.     {
  16.         // このコントローラのアクションでは決して自動レンダリングを行いません
  17.         $this->_helper->viewRenderer->setNoRender();
  18.     }
  19. }

Note: たいていの場合は、自動レンダリングを全体で無効にする ( setNeverRender()) のは無意味です。 なぜなら、ViewRenderer の唯一の存在意義が、 ビューオブジェクトを自動的に設定することだからです。

Example #11 別のビュースクリプトの選択

アクション名から自動的に決まるスクリプトではなく、 それ以外のものをレンダリングしたくなる場合もあるでしょう。 たとえば、add アクションと edit アクションのふたつを持つコントローラがあったとしましょう。 どちらのアクションも同じ 'form' ビューを表示しますが、 そこに設定する値が異なります。 そんな場合に、それぞれでスクリプト名を変えるのは簡単です。 setScriptAction()setRender() を使用するか、あるいはヘルパーをメソッドとしてコールします。 これは setRender() を起動します。

  1. // Foo モジュールの Bar コントローラクラス
  2. class Foo_BarController extends Zend_Controller_Action
  3. {
  4.     public function addAction()
  5.     {
  6.         // 'bar/add.phtml' ではなく 'bar/form.phtml' をレンダリングします
  7.         $this->_helper->viewRenderer('form');
  8.     }
  9.  
  10.     public function editAction()
  11.     {
  12.         // 'bar/edit.phtml' ではなく 'bar/form.phtml' をレンダリングします
  13.         $this->_helper->viewRenderer->setScriptAction('form');
  14.     }
  15.  
  16.     public function processAction()
  17.     {
  18.         // 何かのチェックをした後で...
  19.         if (!$valid) {
  20.             // 'bar/process.phtml' ではなく 'bar/form.phtml' をレンダリングします
  21.             $this->_helper->viewRenderer->setRender('form');
  22.             return;
  23.         }
  24.  
  25.         // その他の処理を続けます...
  26.     }
  27.  
  28. }

Example #12 登録されているビューの変更

ビューオブジェクトの設定を変更したくなったとしましょう。 たとえば、ヘルパーのパスやエンコーディングを変更したくなったらどうしますか? そんな場合は、コントローラに設定されているビューオブジェクトを変更するか、 あるいは ViewRenderer の外部からビューオブジェクトを取得します。 どちらも同じオブジェクトへの参照を取得することになります。

  1. // Foo モジュールの Bar コントローラクラス
  2. class Foo_BarController extends Zend_Controller_Action
  3. {
  4.     public function preDispatch()
  5.     {
  6.         // ビューのエンコーディングを変更します
  7.         $this->view->setEncoding('UTF-8');
  8.     }
  9.  
  10.     public function bazAction()
  11.     {
  12.         // ビューオブジェクトを取得し、エスケープ用のコールバックを 'htmlspecialchars' に設定します
  13.         $view = $this->_helper->viewRenderer->view;
  14.         $view->setEscape('htmlspecialchars');
  15.     }
  16. }

高度な使用例

Example #13 パスの指定方法の変更

場合によっては、デフォルトのパス指定があなたのサイトに うまく当てはまらないこともあるでしょう。 たとえば、すべてのテンプレートを単一のディレクトリ配下にまとめ、 デザイナにはそのディレクトリに対するアクセス権だけを与えたいといった場合です (» Smarty を使用する場合などにありがちです)。 そんな場合は、ビューの基底パスをハードコーディングし、 それをアクションのビュースクリプトのパスとして使用することになります。

この例では、ビューの基底パスを '/opt/vendor/templates' とし、ビュースクリプトのパスは ':moduleDir/:controller/:action.:suffix' となるようにします。noController フラグが設定されている場合は、サブディレクトリ (':action.:suffix') からではなくトップディレクトリからのパスとして探すことになります。 最後に、ビュースクリプトのファイルの拡張子として 'tpl' を設定します。

  1. /**
  2. * 起動ファイル
  3. */
  4.  
  5. // 別のビュー実装を使用します
  6. $view = new ZF_Smarty();
  7.  
  8. $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
  9. $viewRenderer->setViewBasePathSpec('/opt/vendor/templates')
  10.              ->setViewScriptPathSpec(':module/:controller/:action.:suffix')
  11.              ->setViewScriptPathNoControllerSpec(':action.:suffix')
  12.              ->setViewSuffix('tpl');
  13. Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);

Example #14 単一のアクションから複数のビュースクリプトをレンダリングする例

時には、複数のビュースクリプトをひとつのアクションで処理したいこともあるでしょう。 これは、非常に直感的な方法で実現できます。単に render() を必要なだけコールすればいいのです。

  1. class SearchController extends Zend_Controller_Action
  2. {
  3.     public function resultsAction()
  4.     {
  5.         // $this->model に現在のモデルが設定されているものとします
  6.         $this->view->results =
  7.             $this->model->find($this->_getParam('query', '');
  8.  
  9.         // render() は、デフォルトでは ViewRenderer へのプロキシとなります。
  10.         // まず form を、そして results をレンダリングします
  11.         $this->render('form');
  12.         $this->render('results');
  13.     }
  14.  
  15.     public function formAction()
  16.     {
  17.         // 何もしなくても、ViewRenderer が自動的にビュースクリプトをレンダリングします
  18.     }
  19. }

独自のヘルパーの作成

アクションヘルパーは、抽象クラス Zend_Controller_Action_Helper_Abstract を継承して作成します。 ここには、基本的なインターフェイスやヘルパーブローカが使用する必須機能などが含まれています。 具体的には、次のようなメソッドです。

  • setActionController() を使用して、現在のアクションコントローラを設定します。

  • init() はヘルパーブローカによって起動時に実行され、 ヘルパーを初期化します。これは、 アクションチェイン内の複数のコントローラで同一のヘルパーを使用している場合に 状態をリセットする際などに便利です。

  • preDispatch() はディスパッチアクションの前に実行されます。

  • postDispatch() はディスパッチアクションが終了した後で実行されます。 preDispatch() プラグインがアクションの処理をスキップした場合も、 これは実行されます。後始末などをここで行います。

  • getRequest() は現在のリクエストオブジェクトを取得します。

  • getResponse() は現在のレスポンスオブジェクトを取得します。

  • getName() はヘルパーの名前を取得します。 クラス名にアンダースコアが含まれる場合は最後のアンダースコア以降の文字、 そうでない場合はクラス名全体を返します。たとえば、クラス名が Zend_Controller_Action_Helper_Redirector の場合は Redirector を、クラス名が FooMessage の場合はそのままの名前を返します。

オプションで、ヘルパークラスに direct() メソッドを実装することもできます。これを定義しておくと、 ヘルパーブローカのメソッドであるかのようにそのヘルパーを扱えるようになります。 これにより、一度だけ使用するようなヘルパーが扱いやすくなります。 たとえば、redirectordirect()goto() のエイリアスとなっているので、このようにして使用することができます。

  1. // /blog/view/item/id/42 にリダイレクトします
  2. $this->_helper->redirector('item', 'view', 'blog', array('id' => 42));

内部的には、まずヘルパーブローカの __call() メソッドが redirector という名前のヘルパーを探し、 それからそのヘルパーで direct() メソッドが定義されているかどうかを調べ、 渡された引数でそのメソッドをコールしています。

独自のヘルパークラスを作成した場合は、 上で説明したようにしてそれを利用できるようにしておきましょう。

Copyright

© 2006-2021 by Zend by Perforce. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.

Contacts