前回はZFをインストールして、バージョン表示を行いました。
でもバージョン表示ができるくらいじゃ役に立ちそうにありません。
フレームワーク(FW)は使うことが目的ではなく、開発を楽にするための手段の１つと考えることができます。
便利な使い方ができてこそ、FWを使う意味がようやく見えてくるでしょう。
ではその第一歩として、MVCという設計モデルで作ることを考えます。
このMVCというものは役割分担の概念で、ほとんど全てのFWで採用されているようです。
それだけ開発において有効な概念ということになります。
Model-View-Controllerの頭文字がMVCというわけです。
これら３つがそれぞれ自分の仕事に徹することで、全体として処理が進行していくことになります。
それではシンプルな例としてMVCを使って、「Hello world!」を表示させることを考えてみます。
まず必要なものは「Controller」です。
これが全てのリクエストを受付けるところから処理は始まります。
この「全てのリクエストを受付ける」ということを実現するために、Apacheモジュールのmod_rewrite機能を利用してリクエストの全てを「Controller」に集めるリライト設定をすることになります。
リライト設定 - .htaccess
上記リライト設定は、リクエストされたファイルが実在しなければすべて index.php に処理を集めるように書いています。
なのでこの設定では index.php がコントローラとなります。
このリライト設定は設置したらあとは書き換えることはありません。つまり固定です。
さてコントローラindex.phpがリクエストを受けたら、後はアプリケーションとしての処理を行う必要があります。
今回は「Hello world!」を表示させるアプリケーションを作ろうとしているので、この場合、MVCでどういう役割分担にしたらいいかを考えていきます。
従来だったらリクエストを受けたindex.phpから直接「Hello world!」を表示させて終わらせた方が手っ取り早いやり方でした。
しかしMVCでは将来のシステム拡張（機能、ファイル数が増える）のことも考えて、管理しやすくなるよう整理した作りにします。
ここで重要なことがあります。
リクエストを受けるindex.phpにアプリケーション機能を含めてしまうと、複数のアプリケーションを混在させようとした場合にindex.phpの機能分けや統合が面倒なことになります。
なのでindex.php内容はアプリケーションに依存しない部分として切り分けた作りをする必要がありそうです。
理想を言えばどのアプリケーションを作った場合でもindex.phpが同じ内容であることが望ましいということです。
なのでイメージとしては以下のような配置関係になります。
※htdocsがドキュメントルートの例
リクエストを受けたindex.phpは、すぐにアプリケーション側へ処理を丸投げすることでアプリケーションの処理が開始できそうです。
そうなるとアプリケーション側にもコントローラのような指示役がいてくれないと処理が先に進みません。
ということでコントローラは「リクエストを受ける側」と、「アプリケーション側の指示役」の２つに分離して存在することになります。
「リクエストを受ける側」コントローラを『フロントコントローラ』、
「アプリケーション側の指示役」コントローラを『アクションコントローラ』と呼ぶようになっています。
ちゅーことで先にフロントコントローラを書いてみます。
フロントコントローラ - index.php
Zendクラス群へのパスを通してクラスを呼んでいます。
フルパス指定ではなく相対パス指定する場合はrealpath()も使った方がいいと思います。
getInstance()メソッドを使ってオブジェクト取得を行い、setControllerDirectory()メソッドを使ってアクションコントローラの置き場所を教えています。
最後のdispatch()メソッドにより処理を丸投げします。
ではフロントコントローラからアプリケーション処理を任されるアクションコントローラを書いてみます。
アクションコントローラ - IndexController.php
まずクラス定義を呼び出しています。
でもあとはなんだか抜け殻です。
以上で指示役のコントローラ２つが書けたことになります。
次は「Hello world!」ページを描画するための雛形「ビュースクリプト」を書いていきます。
ビュースクリプト - index.phtml
ここでは描画の要らない固定のHTMLを書いた形になってしまいました。
まずは全体の動き、連携を見るためにシンプルになるようにこうしてみました。
これまで書いてきたファイルをどう配置するかを以下に書いておきます。
ファイル配置
配置できたらApacheが起動済みなのを確認してページ表示を試みます。
トップページを表示させたいので、ベースURL（基準となるURL）にアクセスしてみます。
ここでは「Hello world!」が画面に出たらＯＫです。
application側にアプリケーション１つ分が丸々含まれているので開発においてはこちらを編集していくことになります。
htdocs側はドキュメントルート直下で、編集なし（固定）が基本です。
もちろんドキュメントルート直下よりも深い階層に設置する場合も考慮すべきです。
そのために常にベースURLを頭に入れて開発していく必要があります。
ドキュメントルートより深い階層の例
トップページ表示をする場合は以下のようにベースURLをリクエストします。
では話は戻ってファイル配置を見てみると、application直下にはMVCを象徴するかのごとくmodels、views、controllersが並んでいます。
これは覚えやすい配置ですね、アプリケーション内がMとVとCにファイル分けされてるわけですから。
ただcontrollersの方は直下にファイルがありますが、viewsの場合は少々深い階層に配置されています。
これはビューには「ビュースクリプト」の他、「ビューヘルパー」「ビューフィルター」もあるのが１つと、
views/scripts以下はシステムの全画面の雛形が配置されることになるのでファイルを整理するための配置構造というわけです。
今回はMVCのうちコントローラとビューは使いました。
ただビューの描画はしていないことと、モデルを全く使ってないので次回フォローしたいと思います。
でもバージョン表示ができるくらいじゃ役に立ちそうにありません。
フレームワーク(FW)は使うことが目的ではなく、開発を楽にするための手段の１つと考えることができます。
便利な使い方ができてこそ、FWを使う意味がようやく見えてくるでしょう。
ではその第一歩として、MVCという設計モデルで作ることを考えます。
このMVCというものは役割分担の概念で、ほとんど全てのFWで採用されているようです。
それだけ開発において有効な概念ということになります。
Model -----データの出し入れ専門
View ------ページの描画専門
Controller --指示専門
View ------ページの描画専門
Controller --指示専門
Model-View-Controllerの頭文字がMVCというわけです。
これら３つがそれぞれ自分の仕事に徹することで、全体として処理が進行していくことになります。
それではシンプルな例としてMVCを使って、「Hello world!」を表示させることを考えてみます。
まず必要なものは「Controller」です。
これが全てのリクエストを受付けるところから処理は始まります。
この「全てのリクエストを受付ける」ということを実現するために、Apacheモジュールのmod_rewrite機能を利用してリクエストの全てを「Controller」に集めるリライト設定をすることになります。
リライト設定 - .htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
上記リライト設定は、リクエストされたファイルが実在しなければすべて index.php に処理を集めるように書いています。
なのでこの設定では index.php がコントローラとなります。
このリライト設定は設置したらあとは書き換えることはありません。つまり固定です。
さてコントローラindex.phpがリクエストを受けたら、後はアプリケーションとしての処理を行う必要があります。
今回は「Hello world!」を表示させるアプリケーションを作ろうとしているので、この場合、MVCでどういう役割分担にしたらいいかを考えていきます。
従来だったらリクエストを受けたindex.phpから直接「Hello world!」を表示させて終わらせた方が手っ取り早いやり方でした。
しかしMVCでは将来のシステム拡張（機能、ファイル数が増える）のことも考えて、管理しやすくなるよう整理した作りにします。
ここで重要なことがあります。
リクエストを受けるindex.phpにアプリケーション機能を含めてしまうと、複数のアプリケーションを混在させようとした場合にindex.phpの機能分けや統合が面倒なことになります。
なのでindex.php内容はアプリケーションに依存しない部分として切り分けた作りをする必要がありそうです。
理想を言えばどのアプリケーションを作った場合でもindex.phpが同じ内容であることが望ましいということです。
なのでイメージとしては以下のような配置関係になります。
※htdocsがドキュメントルートの例
Zend/ {ZFコンポーネント群}
application/ {1つのｱﾌﾟﾘｹｰｼｮﾝを内包}
htdocs/
.htaccess {リライト設定}
index.php {コントローラ}
application/ {1つのｱﾌﾟﾘｹｰｼｮﾝを内包}
htdocs/
.htaccess {リライト設定}
index.php {コントローラ}
リクエストを受けたindex.phpは、すぐにアプリケーション側へ処理を丸投げすることでアプリケーションの処理が開始できそうです。
そうなるとアプリケーション側にもコントローラのような指示役がいてくれないと処理が先に進みません。
ということでコントローラは「リクエストを受ける側」と、「アプリケーション側の指示役」の２つに分離して存在することになります。
「リクエストを受ける側」コントローラを『フロントコントローラ』、
「アプリケーション側の指示役」コントローラを『アクションコントローラ』と呼ぶようになっています。
ちゅーことで先にフロントコントローラを書いてみます。
フロントコントローラ - index.php
<?php
// Zendパスを通す
set_include_path('C:\xampp');
// 必要なクラス定義を読み込む
require_once 'Zend/Controller/Front.php';
// アクションコントローラへ丸投げ
$front = Zend_Controller_Front::getInstance();
$front->setControllerDirectory('../application/controllers');
$front->dispatch();
// Zendパスを通す
set_include_path('C:\xampp');
// 必要なクラス定義を読み込む
require_once 'Zend/Controller/Front.php';
// アクションコントローラへ丸投げ
$front = Zend_Controller_Front::getInstance();
$front->setControllerDirectory('../application/controllers');
$front->dispatch();
Zendクラス群へのパスを通してクラスを呼んでいます。
フルパス指定ではなく相対パス指定する場合はrealpath()も使った方がいいと思います。
set_include_path(realpath('../..'));
getInstance()メソッドを使ってオブジェクト取得を行い、setControllerDirectory()メソッドを使ってアクションコントローラの置き場所を教えています。
最後のdispatch()メソッドにより処理を丸投げします。
ではフロントコントローラからアプリケーション処理を任されるアクションコントローラを書いてみます。
アクションコントローラ - IndexController.php
require_once 'Zend/Controller/Action.php';
class IndexController extends Zend_Controller_Action
{
public function indexAction() {
}
}
class IndexController extends Zend_Controller_Action
{
public function indexAction() {
}
}
まずクラス定義を呼び出しています。
でもあとはなんだか抜け殻です。
以上で指示役のコントローラ２つが書けたことになります。
次は「Hello world!」ページを描画するための雛形「ビュースクリプト」を書いていきます。
ビュースクリプト - index.phtml
<html>
<body>
Hello world!
</body>
</html>
<body>
Hello world!
</body>
</html>
ここでは描画の要らない固定のHTMLを書いた形になってしまいました。
まずは全体の動き、連携を見るためにシンプルになるようにこうしてみました。
これまで書いてきたファイルをどう配置するかを以下に書いておきます。
ファイル配置
Zend/
application/
models/
views/
scripts/
index/
index.phtml
controllers/
IndexController.php
htdocs/
.htaccess
index.php
application/
models/
views/
scripts/
index/
index.phtml
controllers/
IndexController.php
htdocs/
.htaccess
index.php
配置できたらApacheが起動済みなのを確認してページ表示を試みます。
トップページを表示させたいので、ベースURL（基準となるURL）にアクセスしてみます。
http://localhost/
ここでは「Hello world!」が画面に出たらＯＫです。
application側にアプリケーション１つ分が丸々含まれているので開発においてはこちらを編集していくことになります。
htdocs側はドキュメントルート直下で、編集なし（固定）が基本です。
もちろんドキュメントルート直下よりも深い階層に設置する場合も考慮すべきです。
そのために常にベースURLを頭に入れて開発していく必要があります。
ドキュメントルートより深い階層の例
htdocs/
foo/
.htaccess
index.php
foo/
.htaccess
index.php
トップページ表示をする場合は以下のようにベースURLをリクエストします。
http://localhost/foo/
では話は戻ってファイル配置を見てみると、application直下にはMVCを象徴するかのごとくmodels、views、controllersが並んでいます。
これは覚えやすい配置ですね、アプリケーション内がMとVとCにファイル分けされてるわけですから。
ただcontrollersの方は直下にファイルがありますが、viewsの場合は少々深い階層に配置されています。
これはビューには「ビュースクリプト」の他、「ビューヘルパー」「ビューフィルター」もあるのが１つと、
views/scripts以下はシステムの全画面の雛形が配置されることになるのでファイルを整理するための配置構造というわけです。
今回はMVCのうちコントローラとビューは使いました。
ただビューの描画はしていないことと、モデルを全く使ってないので次回フォローしたいと思います。