02時08分59秒のっけからお詫びすみません、このエントリ書くまで気づきませんでしたが、前回示したフォルダツリーで、ビュースクリプト関連で1階層抜けてました。具体的には「htdocs/zf1/application/views/scripts/index/」の「scripts」部分が抜けてました。2つ目のアクションメソッド気を取り直して、本題です。期間が空いてしまいましたが、前回の続きでアクションコントローラを扱います。前回はデフォルトのアクションメソッド(indexAction)のみの実装でしたが、まずは2つ目のアクションメソッドを実装するところからはじめましょう。アプリケーションは前回のものをそのまま流用しますので、これからやる作業はIndexController.phpにアクションメソッド「secondAction」を追加するsecondActionに対応するビュースクリプト「second.phtml」を/views/scriptsに作成するの2点です。/application/controllers/IndexController.phpを以下のようにします。);}}IndexController.php対応するsecond.phtmlは、とりあえずindex.phtmlをそのままコピーしてリネームしてください。ここまでの作業で、ファイル一式は以下のようになります。Apacheを使用している方はこれを忘れずにこの状態で「http://<host名>/zf1/index/second」にアクセスすると、「2つ目のアクション」と表示されるはずです。以降、基本的には、「アクションメソッドを増やしたら、対応するビュースクリプトを追加する」というような拡張方法になります。相互にリンクを張ってみるさて、せっかくアクセスできるURLが2つに増えたのに、それぞれいちいちURLを直接打ち込んでいたら面倒この上ないので、それぞれのアクションメソッド(のビュー)からお互いにリンクを張ってみることにします。ビュースクリプト中に直接記述してもいいのですが、リンクアドレスの情報はコントローラ側で管理し、ビュースクリプトはそれをレンダリングするだけに分離するのが筋だと思いますので、そのようにしてみます。2つのアクションメソッド内で「$this->view」にリンクさせるアドレスをassignさせます。こんな感じでしょうか。);}}そしてビュースクリプトです。index.phtml、second.phtmlとも以下の内容に修正します。?></a></body></html>index.phtml、second.phtmlさて、まずは「http://<host名>/zf1/」にアクセスしてみてください。以下のようになるはずです。Frameworkへindex/secondhttp://<host名>/zf1/ここまでは従来と変化がほとんどないので問題ないはずです。確認点としてはリンクがちゃんと表示されているか、くらいでしょうか。次にページ中のリンク「index/second」をクリックしてみてください。以下のようになります。2つ目のアクションindex/indexhttp://<host名>/zf1/index/second/ちゃんと表示が変わっているでしょうか?リンク先がなんだかヘンさて、ここまで特に問題はないはずなのですが、どこかおかしい所はないでしょうか?index/secondに表示されているリンクをよく確認してください。未訪問の色のままになっていませんか?リンク「index/index」にカーソルを合わせてみるとわかると思いますが、実は現在のサンプルのままでは、リンク先が「http://<host名>/zf1/index/index/index」になってしまいます。Frameworkのコントローラモデルでは、すべてのアクセスがディレクトリパスに展開されるため、相対でリンクを示すと常に現在のパスに対して階層が追加されてゆくことになってしまいます。これが、アプリケーションがホストのトップであれば、「/index/second」などと絶対パスが使用できるので問題ありませんが、アプリケーションごとにホストを用意したりバーチャルホストを用意したりするのはあまり現実的ではありません。ドキュメント中に出現するURLはリンク先だけではありません。JavaScriptやCSSなどのリソース、画像、さらにはformのpost先など、1つのWebアプリケーション内でアプリケーション内のほかのURLを指定する必要があるところはたくさんありますので、このままではちょっと困ったことになってしまいます。やって解決したものでしょうか...base要素を活用これはdara-j的なアプローチですが、リンクの解決にbase要素を使用してみましょう。href="http://<host名>/zf1/"></base>」が出力されてさえいれば、前述のように「コントローラ名/アクション名」形式でリンクを指定することができます。base要素に指定するアプリケーションのルートURLですが、直接ビュースクリプト中に指定してもよいのですが、他のアプリケーションを構築する際にもそのまま流用できるように関数を作成することにします。起動スクリプト「index.php」に以下のような関数を追加します。$request->getBaseUrl();}引数として受け取る「$request」は、Zend_Controller_Request_Httpというオブジェクトになります。このオブジェクト(クラス)は従来$_GETや$_POSTなどのスーパーグローバル変数から取得していたリクエスト情報を一元的に集約したバリューオブジェクトです。Framework上でも従来のスーパーグローバル変数へアクセスはできますが、せっかくのオブジェクト指向プログラミングでもあり、なるべくこちらを使うようにしたほうがよいと思います。アクションコントローラの初期化機構では、このgeApplicationUrl関数を使用して、実際にbase要素を出力するようにしてみましょう。引数にZend_Controller_Request_Httpが必要ということもあり、アクションコントローラからgetApplicationUrlを呼び出して値を取得し、ビュースクリプトへassignするというアプローチにしてみたいと思います。これまでと同じように、各アクションメソッド内から$this->view->assignとしてもよいのですが、これはコントローラ内での共通処理とするような内容なので、どこか一箇所に集約しましょう。アクションコントローラは固有の初期化処理用として、「init」メソッドを用意しています。これはZend_Controller_Actionのコンストラクタから始まる一連の初期化処理の中でサブクラス固有の初期化処理用として用意しているもので、これをオーバーライドすることになります。initメソッドをオーバーライドし、base要素向けのベースURLをビューへassignするコードを追加したIndexController.phpは以下のようになります。);}}IndexController.php(初期化処理を追加)ちょっと補足になりますが、getApplicationUrl()に渡すリクエストオブジェクトを「Zend_Controller_Request_Http」と説明していましたが、コード中のコメントでは「Zend_Controller_Request_Abstract」としています。これは別に先の説明で嘘をついていたとか間違っているとかではなく、Zend_Controller_Action::getRequest()メソッドは抽象クラス「Zend_Controller_Request_Abstract」を返す仕様になっていて、httpアクセス環境化ではhttp通信向けサブクラスである「Zend_Controller_Request_Http」を返している、ということです。getApplicationUrl()内ではZend_Controller_Request_Httpであることを前提としているのであまりよいコードではないのですが、この連載中ではCLIなどは想定していないのでこのままでご容赦ください。secondActionメソッドの最後に「$this->_helper->viewRenderer('index')」という見慣れないコードを追加していますが、これはまったく同じ内容の2つのビュースクリプトを定義しているのが気持ち悪いため、2つのアクションメソッドで1つのビュースクリプトを共用するためのコードです。_helperやviewRendererがいったい何なのかはこの連載でもいずれ取り上げますが、「viewRendererヘルパーの(暗黙のメソッドである)setRenderメソッドでレンダリングするビュースクリプトを変更できる」ということができる、ということだけ理解してくだされば問題ないと思います。別のビュースクリプトの選択」をご覧ください。他のソースの改変init内で「baseUrl」として割り当てられたURLをbase要素として出力するよう改変したindex.phtmlは以下のようになります(second.phtmlは不要になったので削除してください)。?></a></body></html>index.phtml(base要素の出力を追加)base要素の出力時で、href属性の最後に「/」を記述しているのは、単にgetApplicationUrl()が末尾に「/」がない状態の文字列を返すからです。base属性は末尾が「/」ではない場合有効に機能しないので注意してください。getApplicationUrl関数を追加した、最終的なindex.phpは以下のようになります。$request->getBaseUrl();}index.php(getApplicationUrl関数追加)今回の最終的なファイルツリーは以下のようになります。getApplicationUrl()関数を追加.htaccess今回のまとめ今回のポイントは以下のようになります。次回は(今回やる予定だった)エラーの処理方法の概要と、関連して複数のアクションコントローラを使用する例を扱ってみたいと思います。[コメント(0)|トラックバック(0)]連載記事って大変だわ。03時34分51秒いやはや、思ったより大変だ...なにを思ったのか、先日より「ZendFramework入門」なる連載記事をはじめてみたのだが、これが思ったよりも大変。先ほどあげた記事なんかは、もともと漠然とした構成は頭の中にあったので「1時間くらいでできるかな?」などと考えていたのだが、結局3時間ほどかかってしまった。書いているうちに「あれも必要では?」「これはどこに差し込もう?」なんて迷いがいろいろでるというのもあるし、なによりテキストエディタでHTMLを直接書いているという前時代的な作業が遅くなる原因なんだろうけど。間違えるしもともとHTML書くのにツールを使う習慣がないので、通常の記事であればエディタでしこしこHTML書くのはそんなに苦にならないんだけど(量を書かないからね)、今回ネックになるのはHTMLのソースフォルダツリーの2点で、前者は実体参照が、後者はリストの入れ子が結構大変。こんなの手作業でやるのはなんか間違っている気はするのだが、ほどよいツールがなく結局しこしこと書くハメになってしまっている。うれしいこともあるもちろん大変なことだけではなく、うれしいこともある。はじめたばかりで海のものとも山のものともつかないしょぼい連載なのだが、いくつかのサイトさんでこの連載をご紹介くださっているのだ。紹介してくだすったお礼も兼ねて(兼ねられるのか?)、リンクを示しておこう。Framework入門・準備編あるSEのつぶやきさん、PHPの種さん、ご紹介ありがとうございます。へこむこともあるただ、上記の「PHPの種」さんのところで別の入門記事(というかクイックスタート)を紹介されているのだが、こんなの見ると「俺やってる意味あんのかな」とかへこんだりへこまなかったり。[ラボラット]ほんとにラボラットさんの記事は簡潔にうまくまとめてるので、正直ここの連載より役立つと思いますorzこっちなんか2回(準備編入れて3回か)も費やしてるのに内容的にはラボラットさんとこより薄いもんなぁ。今後はもう少し内容を濃くするようにがんばろう。吊ブックマークレットtumblrのキーボードショートカットが便利になっとる。Chrome編dataスキームの画像をブロックしてみるローカルストレージを確認したり消したりするブックマークレットそうそう、いまさらTwitter始めました。(9)このブログについてJavaScriptとかC#とかPHPとか。