- 締切済み
PHPフレームワーク環境でのSmartyの必要性
PHP でシステムを開発する際ですが、恐らく何かしらのフレームワークを利用した場合は大半だと思います。そう言った時にテンプレートエンジンの Smarty を合わせて利用するかどうか意見が別れる時があります。 PHP でフレームワークが今ほど使われていなかった大昔は、素の PHP 実装 + Smarty で、ロジックとテンプレートを分離する流れがありました。 しかし、現在利用されるほとんどのフレームワークでは当たり前のように MVC の思想で構成されており、ロジックとテンプレートは初めから分離されています。 そう言った状況の中、Smarty を各フレームワークと連携してテンプレートエンジンとして利用する必要がどれほどあるのか、判断に苦しみます。 皆さんはどう考えるでしょうか?
- みんなの回答 (4)
- 専門家の回答
みんなの回答
- shockatz
- ベストアンサー率80% (153/191)
そもそも、CakeやZend Framework、Fuelなどほとんどのフレームワークが、設計コンセプトにおいて、Smartyの存在を無視している以上、あえて過去の遺物を引きずる必要はないです。 Smartyはテンプレートエンジンですらない、単なるタグパーサであり、モダン・フレームワークのアーキテクチャに合いません。 最新のMVCであるLaravelなどは、自前でBladeというテンプレートエンジンを装備していますし、WordpressのようなCNSでもSmartyは用なしです。 Smartyを採用したがるのは、開発をレガシーphpの手法に引き戻して、何とか仕事を自分たちの手の届く範囲に止めたい、オールドデベロッパーの悪アガキに思えます。
- hue2011
- ベストアンサー率38% (2801/7250)
cakeだと、viewはE-R図を描いた上bakeで生成されてしまいますので、それを使わないと連携が危うくなります。 modelとの密接な連携も、フレームワークが囲い込んでいますし。 ただし、全くmodelと無関係なオブジェクトを使用するというのであれば、smartyは名前の通りスマートにできます。 Zendは書き方・書式がうるさい系統ですから、smartyを使うと、コードチェックに引っかかる可能性があります。 設計者の頭の中で、ここからはsmartyの領域だと区分けがきっちりできれば原則問題はないかと思います。 が、そんなに頭脳はクリアではないのです。 cakeが1から2になったときの混乱は今もひきずっていますが、smartyと一緒に使った場合、次に3ができて移行しようとしたときかなり混乱するようには思います。
お礼
ご意見ありがとうございます。 設計はシンプルな方が絶対いいですね。 後から参加した方に頭を悩ませたくないですし、メインでも無いところで考えるのが勿体無いです。 ベース部分(プロジェクトの骨組み)は限りなくシンプルが理想です。
- goro123123123
- ベストアンサー率8% (1/12)
MVCになっていても搭載されているViewの機能が貧弱の場合があります。 その場合、Smartyを使った方が楽な場合があります。 (SmartyはViewに機能を絞って開発されている分、Viewとしての機能は高機能なので)
お礼
ご意見ありがとうございます。 確かに、Smartyにある機能が各フレームワークのテンプレート機能にないというのは、話している方がいました。 簡単な処理だったので、それならビューヘルパーか何かで自前で用意することもできるはずなんですけどね。 どう説明するか、難しいときもあります。。
- asuncion
- ベストアンサー率33% (2127/6289)
Zend FrameworkとかCakePHPといった MVCフレームワークを使うのであれば、 Smartyの必要性はあまりないような気がします。 素人の浅はかな考えですが…。
お礼
ご意見ありがとうございます。 基本、私も同様の考えです。
お礼
ストレートなご意見ありがとうございます。 共感部分が多いです。 こちらの開発リソースが特別なのか、Smarty有りきの方が割と多いんです。 (昔からPHP + Smartyで開発してきているからなのか) よく言われるのが、Smartyでないとコードが汚い。 Smartyには便利機能が豊富でテンプレート処理が簡単。 個人的は、Smartyを定義してSmartyに情報を設定するコード自体が、フレームワーク標準ではなくSmartyの拡張コードという認識なので汚い?というか不要なコードに感じてます。 シンプルでなくなっている認識です。 本当にメリットがあるのか、その場では理解した風でいますが、本当はイマイチ腹に落ちてきていない感じです。