Smartyを使用するときのMVCのMとC。
連投でSmartyネタ。
今関わってる案件で、クライアント要望でSmarty必須な案件があるんだけど、
Smartyはまぁいいとして、MVCの残り、MとCをどうするか思案中。
Mは条件揃えばなんだけど、Doctrine試してみたい。
Doctrine使ったことないんだけど、サンプルソースを見る限りはPropelよりソースの可読性がいいと思うので。
あと、Propelはスキーマ定義がXMLだったり、Propel1.2で使ってるDB抽象レイヤのCreoleが開発終了だったりするし、Propel1.3はまだβだしってのもあり。
で、Mはもうある意味結論は8割方出てるんだけど、問題はC。
Modelはまぁある程度どんなフレームワークでも融通効くと思うんだけど
ControllerはViewと結構密接だったりしますよね。。。
Smarty前提でうまく組み込めるController、というかフレームワークないかなぁ。。。と思っていろいろ探してみたものの、結局断念。
symfonyは論外（笑）*1、
その他cakePHP、CodeIgniter、rhaco、Ethna、guess framework classic、ちいたんなどいろいろ仕様調べたけど・・・自分が求めてるものと違う。
かろうじて近いかなと思ったのがZendだったけど、これも最終的には蹴り。
何が問題かというと、Smartyが前提で、かつクライアントも納品後にシステムに触る可能性があるんだけど、
そういう前提だと、あんまフレームワークフレームワークしたフレームワークは採用しづらいんですよねぇ。。。
軽量で、かつ、「ベタで公開ディレクトリ以下に置くようなページコントローラ的な感覚で使える」ようなのってないかなぁ、と思ったんですが、そんな変態的なもの（笑）は需要がないですかねぇ。。。
ページコントローラだとどうがんばってもDRY原則に反するソースを書かなければいけないのが悩みどころ。
なので、ページコントローラベースであっても、重複コードを如何に少なくするかを思案しております、はい。。。
