dara-j

久々のZFネタっす。といっても自分でなんか書いたりするわけじゃなく、よそ様で紹介されていた資料の紹介。すまぬ。

すばらしい図面が紹介されてた

PHPSPOTさんで紹介されてたZF-users.jpというZendFrameworkユーザ向けのハブサイトさんで、Zend_Controller/Zend_View関連の図面が紹介されてました。

• How-to ZF Controller遷移図

このページで「シーケンス図 (http://www.kitpages.fr/zf_helper_plugin.php)」と「Zend_Controller と Zend_View 図でまとめ」という2つの図面が紹介されていて、どちらも非常に有用なのですが、特に「シーケンス図」がお勧め。個人的に。

ソース追っかけるときのお供に

この図、ブラウザからリクエストが発生して、Zend Frameworkのコントローラ群が処理を行ってブラウザにレスポンスを返すまでの流れをあらわしていて、これを片手にZend/Controller/Front.phpから流れを追っかけてくとコントローラ周辺の処理がよく理解できると思います。

ソース読めばまぁわかるんだけどもちと迷いそうなところだけ補足しておきます。

プラグインブローカー

まずカーキ色のボックス「Plugins」を呼び出しているところは、実際は Zend_Controller_Plugin_Broker （フロントコントローラ内の「_plugins」）に対する呼び出しです。ブローカーはこれらのメソッドを呼ばれると、自身に登録されている各プラグインクラスの同名メソッドを順次呼び出す仕組みになっています。この機構を利用すれば、例えばdispatchLoopStartupをフックして、特定条件下では必ずログインフォームへナビゲートさせるような認証プラグインなんかを実装することができます（フックメソッド中にリクエストオブジェクトのコントローラ名/アクション名を上書きしたりもできるので）。

ディスパッチループ

「12: preDispatch」～「28: postDispatch」まで（背景がカーキになっている部分）は「ディスパッチループ」で、特定の条件下、例えばアクションコントローラで _forward() した場合は再びpreDispatchへ処理が移るような流れになっています。

具体的な処理についてはソースを見てみてください。Zend_Controller_Action::_forward でリクエストオブジェクト（Zend_Controller_Request_Abstract）に対して setActrionNameメソッドで次に実行するアクションを登録し、 setDispatchedメソッドにfalseを渡しているのがわかると思います。この「setDispatched(false)」が、ディスパッチループを繰り返すという決定を下している部分になります。

その他の部分

その他の部分は特に解説はいらないと思います。「Helpers」（＝アクションヘルパー）の部分は考え方としてはプラグインブローカー/プラグインと同様に捉えられると思いますので。

まとめ

なんて具合に人様のコンテンツの尻馬に乗ってお茶を濁しましたが、本当はいずれこういうシーケンス図を書くつもりだったんですよ、いや、まじで。（つか、リファレンスマニュアルにこういうの載せてくれればいいのに）

今回紹介されていた2つの図面を見るとコントローラ（とビュー）の基本クラスの関連はぐっと把握しやすくなり、ソースを追っかけた場合の混乱も軽減されると思うので、ぜひ印刷するなりで手元においておいて、さらにZFのソースを読んでみることをお勧めします。