そんな大層なものでもないし、ちゃんとまとめる自信が無くなってきたので、
とりあえず簡単に説明すると…
スクリプトを埋め込めるんだから、PHP 自体がテンプレートシステム。
- メリット
-
テンプレートシステムを導入しなくて良い。
- デメリット
-
PHP そのものなので、何でもできてしまうという意味で、リスクがある。
テンプレート上の HTML コードは、関数として定義する(必要であればブロックに分けて)。
例えば、テンプレート上に、ループするブロックがある場合、そのブロックの始まりと、終わりに、関数定義の始まりと、終わりを埋め込む。
つまり、
<? function hoge_loop($_){ ?>
と、
<? } /* function hoge_loop($_) */ ?>とで、囲む。
ブロック内で展開したい変数は、'$_' という連想配列に入れて引数として渡す。
残りのブロックも同様に関数化する。
「レンダリング」= 関数のコール。
- メリット
-
「レンダリング」を、ブロック単位で制御できる。
- デメリット
-
テンプレートに、<? function foo_bar($_){ ?> とか記述されていてキモい(が、もう慣れた)。
間違って消されると「そんな関数見つかりません」系のエラーが発生する。
ヴューに対してリクエストがあって、対応するコントローラが読み込まれる。
テンプレートたる PHP ファイルから、ロジックが別ファイルとして分離されて、ヴュー → コントローラ の対を成す。
»「ページ・コントローラ」!
ヴューがリクエストを受けて、ヴューがコントローラを読み込むイメージ。
(フロント・コントローラの逆…)
»「リア・コントローラ」!!
特定のヴューに対応するコントローラは、
ヴューの SCRIPT_FILENAME から 1 対 1 に自動決定され、include 系の命令で読み込まれる。
そのコントローラの中で、
ブロック単位で、テンプレートの「レンダリング」(=関数のコール)が行われる。
ついでに、拡張子 html で mod_php が動作するように設定して、
テンプレートたる PHP ファイルの拡張子は html とする。
- メリット
-
「ページ・コントローラ」の〜:
ロジックがページ単位で分割されるので、
工数を見積もる際に見通しが良く、メンテナンスも容易。
「リア・コントローラ」の〜:
mod_rewrite やら、ルーティングやら、による仮想 URL じゃなくて、
静的 HTML と同様に、URL に対応するパスに
HTML っぽいファイル(実は PHP)が実在するので分りやすい
(テンプレートを担当するデザイナにも受け入れられやすい)。
- デメリット
-
「同一の URL に対するリクエストだけれど、
リクエスト変数によって条件分岐してヴューを切替えたい」というような場合には、
例外的にフロント・コントローラ的なものを配置する必要がある。
モロモロの処理を auto_prepend, auto_append .
上記の、 ヴュー → コントローラ の対応付けや、その他、お決まりの処理(セキュリティ対策、DB接続、セッション、認証など)は、
1 つのファイル(prepend.php とか)にまとめておいて、それを auto_prepend .
更に、コントローラの読み込みや、その他、後始末系の処理も、
1 つのファイル(append.php とか)にまとめておいて、それを auto_append .
- メリット
-
テンプレートたる PHP ファイルに、include 系の命令が一切露出しないので、
テンプレートとしてスッキリするし、ちょっとだけセキュアな気もする。
- デメリット
-
あるのかもしれないが特に感じない。
include 系を随所で使う。
フロント・コントローラでは、全ての処理が一箇所に集まるので DRY にしやすいが、「ページ・コントローラ」では事情が違う。
代わりに、include 系の命令を多用する事で、DRY を追求する。
- メリット
-
あるのかもしれないが特に感じない。
- デメリット
-
ルールが無いと見通しが悪くなる。
という感じなんだけど…
PHP でしかあり得ない仕組みなので、他の言語から見ると気持ち悪いだろうけれど、デザイナとの分業のし易さを追求した結果の産物であって、
実際、その意味では充分な効果が得られたと思う。
幸か不幸か、私がまともに使えるのは PHP だけなので、
今でも、特に違和感も不便も感じず、普通に使っているけれど、
そろそろ、その違和感とか不便さを理解しといたほうが良い気がする(汗笑)。
それには、PHP 以外を使ってみる必要があるだろう、
というわけで、 Perl を改めて勉強しようと思った次第。
