>>350の言う事で決着じゃん。
テンプレートがフレームワーク依存するのが嫌ならSmarty使えばいい。
使い分けるってこと出来ないの？

Zend <?php echo $this->escape($val); ?>
Cake <?php echo h($val); ?>
Symfony <?php echo $sf_data->get('hoge'); ?>

テンプレートも弄る自分的には、エスケープ一つでここまで構文が違うのは辛い。
手放せないほど便利な固有ヘルパーがあるわけでもないから、FW固有の方言やノウハウを学ぶ意欲も続かない。
そんな理由でSmartyを手放せずにいる。

>>352
学習意欲も無いのに高性能なものを無理して使うことは無いな。
Smartyで済む人は騒ぎ立てずにSmartyを使い続ければいいと思う。

>>350
Smartyと生PHPを「構文の差」として解釈してる時点で頓珍漢だと思う。

hogeFW > hogeSmartyAdapter > smarty構文のtemplate
hogeFW > php構文のtemplate

だから、Apapterパターンにはなり得ない、という話だと思うけど。

>>353
＞Smartyと生PHPを「構文の差」として解釈してる時点で頓珍漢だと思う。
論点が変わってるね。Smartyと生PHPの話じゃなくて、
>>352が書いているように「テンプレートとしての構文の差」を無くす為にアダプタをかまそうって話だよ。

生PHPのみで例えるなら、CakeのテンプレートをZendFWで使おうとした場合、
Cake･･･<?php echo h($val); ?>
ZendFW･･･<?php echo $this->escape($val); ?>
という「構文の差」が生まれるよね。
でもZendFW側に h() を $this->escape() に橋渡しするアダプタを作ってやれば、
テンプレート構文の差は埋まり、共通のテンプレートが使えるようになるね。

CakeのテンプレートをZendFWで使おうなんて考えは頓珍漢だと思うよね。
でも別にCakeのテンプレートをZendFWで使う事が目的じゃないからね。
「FWに依存しない共通のテンプレート」が使えればSmartyだろうが生PHPだろうが構わないんだ。

>>350 はtemplateに対するAdapterパターンでFA。
Smatyスレで必死にSmartyを批判してる君も十分頓珍漢だと思うよｗ

> 「FWに依存しない共通のテンプレート」が使えればSmartyだろうが生PHPだろうが構わないんだ。

論旨が意味不明だな。
だったらSmarty要らないじゃん。

> Smatyスレで必死にSmartyを批判してる君も十分頓珍漢だと思うよｗ

Smartyスレで必死に頓珍漢なフレームワーク叩きをして、
スレが荒れる原因を作っているほうがよっぽどスレには不利益だと思うけどな。

>>355
＞＞「FWに依存しない共通のテンプレート」が使えればSmartyだろうが生PHPだろうが構わないんだ。
＞論旨が意味不明だな。だったらSmarty要らないじゃん。

うん。だからSmartyじゃなくてもいいんだよ。
何が意味不明なんだい？
君は「FWに依存しない共通のテンプレート」を実現したい場合、どうするのが良いと思う？

俺は生PHPを使ってhtmlspecialchars()とか毎回書くのはだるいし、
変数を一括エスケープしたり、テンプレートディレクトリを精査したり等の機能が欲しいから、
何らかのライブラリは必要だと思うよ。
でも、そんなの作るの面倒だからSmartyを使うけどね。


＞Smartyスレで必死に頓珍漢なフレームワーク叩きをして、
誰も叩いてないよｗ
フレームワーク至上主義者がSmarty批判してブーメラン浴びてるだけの話だろｗ

ここまでの流れ

Smarty(テンプレートエンジン)否定派が沸く
↓
Smarty派は使う事のメリットを提示する
↓
否定派はメリットを絶対に認めずデメリットのみを主張
↓
Smarty派は使わない事のデメリットも提示する
↓
否定派ファビョル


PythonとかRubyを使っているモダンオナニストがPHPを否定しているような状況に似ているな。
所詮は道具なのに、なぜ使い分けが出来ない？

>>355
>>354, >>356←こいつは前から一貫して意味不明なことをホザくので
俺も対応に苦慮してる。
デザパタとかFWの理解がまったくもってなってないので
話がまったく通じない。
精神異常者と話すってこういうことなんだと思った。

>>355
認識の違いって怖いですよね。

否定派がSmartyを使うことのデメリットを提示する
↓
Smarty厨が必死に抵抗（しかも意味不明）
↓
否定派が冷静にツッコミを入れる。
↓
Smarty厨ファビョル

そんな複数人に見せかけなくても

↑>>357の間違いな

>>356
> 君は「FWに依存しない共通のテンプレート」を実現したい場合、どうするのが良いと思う？

フレームワークの仕様にあわせて導入するのが良いと思うけど。

> 何らかのライブラリは必要だと思うよ。
> でも、そんなの作るの面倒だからSmartyを使うけどね。

別にそれでもいいと思うけど。

それがどうして>>350みたいなアダプタになるの？

> ここがSmartyスレだって事忘れてない？ｗ
> Smarty自体がアダプタの役割も担うから。
> アダプタパターンって知ってる？
> Smarty本体がアダプタとして動いてくれるから、
> フレームワークのバージョンを変えようが、フレームワーク自体を変えようが、ビュー側のスクリプトには何ら影響は無い。

と言っていた過去の発言とも矛盾してるでしょ。
「Smartyにはアダプタとしての機能があるからフレームワークで提供されたテンプレートより良いんだ」
というのが君の主張だったんだから、しっかり責任を持って発言してくれないと。

＞＞ 君は「FWに依存しない共通のテンプレート」を実現したい場合、どうするのが良いと思う？
＞フレームワークの仕様にあわせて導入するのが良いと思うけど。

質問の答えになって無いよ。
ムキになって反論してるだけじゃないなら、簡潔でいいから具体案を出してくれよ？
例えばcakeとsymfonyで同じtemplateを使用するという要件を満たす場合どうするの？

＞それがどうして>>350みたいなアダプタになるの？
＞「Smartyにはアダプタとしての機能があるからフレームワークで提供されたテンプレートより良い」

「FWに依存しない共通のテンプレート」という要件を踏まえた上で、
>>350では共通テンプレートとフレームワークを繋ぐ為のアダプタと主張してるわけだが、それは理解出来るかい？
フレームワークで提供されたテンプレートにもメリットは有ると書いてるけど、日本語は理解出来るかい？

>> 362
>> ここがSmartyスレだって事忘れてない？ｗ
>> Smarty自体がアダプタの役割も担うから。
>> アダプタパターンって知ってる？
>> Smarty本体がアダプタとして動いてくれるから、
>> フレームワークのバージョンを変えようが、フレームワーク自体を変えようが、ビュー側のスクリプトには何ら影響は無い。
> と言っていた過去の発言とも矛盾してるでしょ。

何がどう矛盾してるの？
Smarty自体がアダプタとして動作するし、フレームワーク自体を変えようがビュー側のスクリプトには何ら影響は無いよ。
そういうメリットを得たいならフレームワークで提供されたテンプレートより良いと思うし、
そういうメリットを見いだせないなら別にSmartyはいらんよって話なんだが。

メリットを受ける為の前提となる要件を無視して、矛盾云々言われてもなぁ。
君の頭が固いだけだよ。それもフレームワーク依存脳かい？

>>364
餌与えるな馬鹿

実際のところフレームワークにSmartyをかませると、速さ的にどう？
やっぱり結構表示速度遅くなっちゃうかな？

>>364
また訳の分からないことを言い始めたよこのアホは。
デザパタのアダプタパターンのことを言ってるかと思ったら
Smarty自体がアダプタとか・・・

お前からみたらこのスレにはアホしかいないんだろうから
相手しなければいいのに
わざわざやって来て書き込むのをやめられないというのは
なんか精神的な病か？

フレームワーク使ってる時点で重くなってるから、影響はあまり考えなくて良いんじゃないかなぁ
Smartyと組み合わせるってのは考えた事も無いわ
フレームワーク側が持ってるキャッシュ機構とか使いにくくなるかもしれないし
ヘルパーも用意されてるし

誰かやった事ある？

>>366
フレームワークの基本処理に比べたら超が付くほど軽いよ。
ここ数年のサーバ+PHP5環境でSmartyに置き換えただけで、体感出来るような事はまず無い。

>>367
アダプタパターンでいう所のアダプタって意味だろ。
あとデザパタって略し方はアホっぽいからやめた方がいいよｗ

>>368
自分より格下だと思い込んだ相手には延々語る知ったかPGっているよね。
一種のメサイアコンプレックスだよ。

>>369
ZendFramework 1.9.x + PHP5.2 + xdebugで稼働中のシステムのステップ別ベンチを取ってみたよ

●DB接続(SELECT3回発行)、セッション管理を行った場合
Smartyのコストは全体処理の15%程

●加えて細かいモデル処理等の複雑な処理を行った場合
Smartyのコストは全体処理の8%程

Smartyのコストの内約70%がファイルI/Oに起因するもの(config_load()等のファイルアクセス系)で、
render()やoutput_filterによるCPUコストはSmarty内で見ても10%に至らず、
複雑なテンプレートを処理しても数値上はほぼ横ばい。

●Zend_Viewに置き換えて空のテンプレートを処理した場合、
コストは全体処理の5%程

こちらも同じくrequire_onceが重く、ヘルパを増やせば増やすほど重くなるとおもわれる。

●結論
一切チューニングをしていないVMWare上の環境なので実際の細かい数値は変わるだろうけど、
フレームワークのViewをSmartyに置き換えたところで体感速度は変わらないと思う

>>363-364
> 簡潔でいいから具体案を出してくれよ？
> 例えばcakeとsymfonyで同じtemplateを使用するという要件を満たす場合どうするの？

Smarty View Class と sfSmartyViewPlugin を使う。
フレームワークにあわせた個別の方法で、
Smarty本体以外のライブラリを導入して、Smartyを利用可能にするわけだ。

・これはアダプタパターンではない
・Smartyだけではフレームワークに組み込んで使う事ができない

という点で、お前の主張は間違っているから、
間違った主張から導き出そうとしている答えも間違っている。

> Smarty自体がアダプタとして動作する

きちんと説明したのだから、きちんとした反論をして貰うよ。
「cakeとsymfonyでSmarty自体をアダプタとして動作させる」方法を説明してくれ。

>>371
なんかベンチという割に説明や数値が曖昧だな。

経験則で言っていいなら、まともなアプリで最も重いのはORMだ。
次がDBとテンプレートで、その次が設定ファイル。
DBにセッションを入れてるとか、RDBで無茶なORMの使い方をしているとか、
アプリのつくりがまともじゃないケースでは、Viewの差は取るに足らないだろうね。

十分に適切なアプリなら、応答時間に占めるテンプレート処理の割合はもっと高いはず。
少なくとも1/3から半分くらいだ。

なので、「速さを求める時にはテンプレートエンジンは避けたほうが良い」というのは、
生PHPとSmartyの比較と同程度に考えておいたほうが安全だと思うけど、
「速さをさほど求めない場合に気になるほどの遅さでもない」と思う。
50ミリ秒が100ミリ秒になっても別に困らないというケースも往々にしてあるわけで。

>>372
＞Smarty View Class と sfSmartyViewPlugin を使う。
＞フレームワークにあわせた個別の方法で、
＞Smarty本体以外のライブラリを導入して、Smartyを利用可能にするわけだ。

お前はその「Smarty本体以外のライブラリ」の実装を読んだか？
インスタンス又は継承によるアダプタパターンだろ。
クラス名が異なっているが >>350 で書いてあるのと全く同じアプローチだよ。
継承によるアダプタパターン。

＞・これはアダプタパターンではない
＞・Smartyだけではフレームワークに組み込んで使う事ができない
という結論が間違ってるので論外です。
君はデザインパターンを応用する事が出来ない様ですね。

＞「cakeとsymfonyでSmarty自体をアダプタとして動作させる」方法を説明してくれ。
>>350に書いてあるが？Smatyを継承したアダプタクラスを挟むだけですよ？
CakePHP > CakeSmartyAdapter > template
symfony > sfSmartyAdapter > template

>>373
経験則で言っていいのなら、
管理画面はまだしも表向き表示で重さを気にするシステムにORMは極力使わない。
良くてコントローラ＆モデル処理が8割、ビューは2割ってとこだろ。
反論あるならお前さんも、ステップ単位で処理時間をベンチとってくれや。
そしたら俺のベンチも詳細上げてやるよ。

ケースバイケースな結果になると思うが、
俺は実際動かしてSmartyとZend_Viewは大差無いという結論を出したのみ。
比較対象が生PHPなら遅いかもしれんが、FWに組み込むという意味では体感はかわらん。

>>374
オープンソースライブラリの具体名を挙げてるんだから、
実際にソースを読んでみればいいのに。

それと、
「Smarty自体をアダプタとして動作させる」と
「Smatyを継承したアダプタクラスを挟む」って、意味がまったく違うだろ。

具体的にアダプタクラスとは何か、きちんと説明してみ。
自分の矛盾に気づくから。

>>372
＞・これはアダプタパターンではない
sfSmartyViewPluginは委譲による実装のアダプタパターンだな。
http://d.hatena.ne.jp/shimooka/20080714/1216021170

Smarty View Class も委譲による実装のアダプタパターンだな。
http://cakeforge.org/snippet/detail.php?type=snippet&id=6

以下は全く同じだな、委譲か継承したアダプタパターンだ。
CakePHP > CakeSmartyAdapter > template
symfony > sfSmartyAdapter > template
ZendFW > ZendSmartyAdapter > template

やっぱりお前デザインパターンすらわかってないよ。
基礎中の基礎アダプタパターンｗ　から再勉強してくればいいよ。


＞・Smartyだけではフレームワークに組み込んで使う事ができない

ちなみにFramework間の差異を吸収しないのであれば、Smartyをそのまま適用できるよ。
CakePHP > Smarty > template
symfony > Smarty > template
ZendFW > Smarty > template

使えないのは君の知識量だな。
cakeとか言ってる時点で駄目なにおいはぷんぷんするが。

>>376
お前さ「Smartyをアダプタにすればテンプレート共通化出来るよね」って言われて
「Smarty自体をアダプタとして動作させるのと、Smatyを継承したアダプタクラスを挟むって意味が全く違うだろ」
とか見当違いのツッコミするん？ｗ

Smartyをアダプタとして使うって時点で普通、継承なり委譲なりのラッパークラスを想像すると思うが
･･･>>350の例を見ても理解出来ないレベルなんか？･･･あまりに知識が無いのか、発想が貧弱なのか
･･･なんとなく君のレベルが見えて来たよｗ

誰も救われないから、大人しくcakeスレでシコシコbakeして設定ファイル量産してろよｗ

いつまで不毛な争いしてるんだか…
Smartyは内部でrequireしまくってるからけっこう重たかったな。
拡張モジュールで作られてるsimplateってやつはめっちゃ速かった。当然そこまで高機能ではないけどね。

確かに不毛だな。
実行環境(CPU/ネットワーク)自体の高速化と、フレームワークの肥大化によって、Smarty自体は相対的に軽いものになってしまった。
メリットデメリットはケースバイケースなのでひとくくりには出来ないし、
現場の知識や、制作者の好みで導入すればいいよ。

FWとSmartyどっちが良いか？両方メリットはあるよ。
FWとSmartyどっちが悪いか？両方デメリットはあるよ。

終結

メリットデメリットとかじゃなくて、Smartyを根絶やしにしたいだけだから

だからどういう目に遭ったらそんな深い憎しみを抱くんだよｗ

>>378
それは後だしジャンケンだな。

その屁理屈が成り立つなら、
「symfonyのテンプレートエンジンはアダプタである」とも言えるわけで、
「symfonyのテンプレートエンジンをcakeで使う」事も、
「symfonyのテンプレートエンジン自身がアダプタとして動作する」から、
まったく問題ないことになるじゃん。

Smartyとフレームワーク内蔵のテンプレートエンジンを比較して、
Smartyが有利であると主張していたはずなのに、
その根拠が、自分の屁理屈によって無くなってしまっているんだよ。
だから、間違った主張から導き出された答えが間違ってるよ、と指摘したんだけどな。

議論に勝ちたいからか知らんけど、自分の主張をころころ変えるから、
まわりから見てまったく意味不明になるんだと思うよ。

あと、cakeじゃなくてCakePHPだろ、といいたいのかも知れないけど、
最初にcakeという表現をしたのは>>363だろ・・・。
俺は別に意味が伝わってるからどっちでもいいけど、墓穴掘るのはだいぶ恥ずかしいぞ。

何言ってんだこいつ

このスレを見ていて思うことだが、
「Smarty否定論者がSmartyを叩く書き込みをする」のと、
「Smarty信者が特に優位性の無い部分でSmartyを絶賛する」のは、
同じくらいスレにとって害悪だよ。

極端に言えば、Smartyに利点がひとつも無くたっていいじゃん。
間違った理屈で絶賛しても否定されるだけなのは当然だよね。
それなのに、なんでわざわざ、絶賛して否定される流れを作り出してるの？

それが単に絶賛してる人の知識不足に過ぎなくて、
「それは間違っているよ」と指摘されたら受け止めるというならわかるけど、
意固地になっておかしな主張を続けるもんだからまったく意義が無い。

劣っていようがなんだろうが、Smartyは現存していて、
実際に使っているユーザがいるんだから、その情報交換をすればいいのに。

現に、少なくとも客観的な表現で、
「Smartyと別のもののどっちがいいだろう？」
と質問している場合は、スレは荒れてないじゃん。心がけの問題だと思う。

あまりにもアホすぎてかける言葉も見つからんわ。
ガキのケンカは他所でやれ。

>>383
主題を変えてるのはお前だよ(都合の悪い具体的な質問はスルーだし)
君こそ論破が目的になってないかい？

＞「symfonyのテンプレートエンジンはアダプタである」とも言えるわけで、
＞「symfonyのテンプレートエンジンをcakeで使う」事も、
＞「symfonyのテンプレートエンジン自身がアダプタとして動作する」から、

「symfonyのテンプレートエンジンはアダプタである」が成り立たないよ。
symfonyとテンプレート構文を繋ぐ為のアダプタである、という意味であれば間違いではないが、
異なるフレームワークとテンプレート構文を介するアダプタである、という意味では無理がある。

議論の発端は、
フレームワークに密結合されたテンプレートエンジンを、
他のフレームワークで使うのは困難だから疎結合のSmartyをって話だろ。
何で密結合のもので例えてるの？
symfonyじゃなくてTwigとかsimplateに置き換えれば問題無いよ。

＞Smartyとフレームワーク内蔵のテンプレートエンジンを比較して、
＞Smartyが有利であると主張していたはずなのに

何度も書いてるが「共通のテンプレート」という要件の下に、
Smartyのメリットを主張してるだけで、全てにおいてSmartyが勝ってる等誰も言ってないよ。

＞あと、cakeじゃなくてCakePHPだろ、といいたいのかも知れないけど、
違うよｗ 必死にSmartyを過去のモノにしたり、無駄知識と認定したいらしいが、
cakeも所詮はPHP4実装のレガシーフレームワークな上に、
Smarty以上に無駄知識が必要な設定ファイルが必要だよね。必死にbakeってれば？って事

いいからマズイケーキでも焼いてろよ。

>>380 で結論出てるじゃん。プロならケースバイケースで使い分ける。
>>383 有益な情報を得たいならまだしも、Smartyに興味も無く批判したいだけなら、他のスレに行けばいい。ここはSmartyスレ。

ふと読み返してみた。

>>314 Smartyを使うメリットってありますか？
>>315 フレームワークが生PHPなので、生PHPが主流だよ
>>317 フレームワークに依存しないSmartyが有利な面もあるよ
>>318 >>317を否定
>>320 疎結合のメリットもあるよ
>>324 疎結合より、フレームワークなら密結合の方が良いよ
>>327 密結合にもデメリットはあるよ
>>329 フレームワークの方が優れているよ。Smartyなんて誰もが知ってるわけでは無いし、使わない方がいいよ。

以下ループ(不毛なので読み返してない)

>>329 がフレームワーク至上主義かつSmarty批判が目的だったのが発端だな。
Smartyを使うメリットは？って話だったのに、1人だけ議論がフレームワークの優位性の話になっている。

俺はSmartyの組み込まれたソフトも使って儲けてます。

>>387
> 「symfonyのテンプレートエンジンはアダプタである」が成り立たないよ。

その根拠は？
疎結合なsfTemplateEngineなら成り立つって解釈ではないのか？

>>387-388
「Smartyマンセー発言にレスした奴はみんな工作員だ！」
みたいな物言いをして、やれレベルがどうだcakeの悪口だと下らん批判に終始して、
自分たちとSmartyは絶対に正義なんだ、みたいな主張をしていること自体が、
カルト宗教ばりの気持ち悪さを醸し出していて、
かえってよくない結果を生んでいる事に気づいたほうがいいと思うよ。

>>329
その説明も事実とは誤っていると思う。お前の自意識と解釈はわかったけど。

頼むから喧嘩するな

>>314-329に対しての意見も述べておこう。

フレームワークに搭載されているテンプレートエンジンには、
密結合なものだけではなく、疎結合なものもある。
すべて密結合だと断定するのは間違い。

Smartyをフレームワークで使うには、連携のための処理を追加する必要がある。
これらの処理はフレームワークに依存する。
Smarty自体が自動的に連携をおこなうわけではないし、
Smarty公式がフレームワーク毎の連携ライブラリを提供しているわけでもない。

なので、フレームワークのバージョンアップによって、
上記の追加処理に変更が必要になる場合も当然に存在する。

ゆえに、
「テンプレートとしての構文の差を無くす為にSmartyが優れている」
という根拠は存在しない。

昔Smartyを使っていた人が惰性でSmartyを使い続ける事に対しては俺は異論は無い。
特に昔有名になった定番アプリみたいなやつにはSmartyが使い続けられているよね。
これをわざわざ新しいものにリプレースする必要は、個人的には感じていない。

だけど、トンデモ信者がやってきて、フレームワークでSmartyを使えとのたまうのは嫌だ。
フレームワークとSmartyは、親和性がすこぶる悪いからね。
やったことも無い人が「Smarty自体がアダプタになります（ｷﾘｯ」とか言うのを見たら、
さすがに突っ込みも入れたくなるというものだわ・・・。

>>390
> 「symfonyのテンプレートエンジンはアダプタである」が成り立たないよ。
>その根拠は？疎結合なsfTemplateEngineなら成り立つって解釈ではないのか？

symfony を sfTemplateEngine に書き換えればえれば成り立つんじゃない？
>> 324からずっとフレームワークと密結合に拘ってるし、
Twig もあるし symfony=sfTemplateEngine という意味での発言とは思えないが。

ここに今、Smarty信者の敗北が決定したのでした。
（第一部完）

>>392
＞フレームワークのバージョンアップによって、
＞上記の追加処理に変更が必要になる場合も当然に存在する。
＞ゆえに、「テンプレートとしての構文の差を無くす為にSmartyが優れている」
＞という根拠は存在しない。

テンプレートエンジンとフレームワークの連携に調整が入る事もあるかもしれないが、
テンプレート構文自体に変更が入るような場面ってどんな時？
テンプレートエンジンが故意にフレームワーク依存を注入しない限り、
テンプレートがフレームワークの影響を受けることはあり得ないと思うが。

＞昔Smartyを使っていた人が惰性でSmartyを使い続ける事に対しては俺は異論は無い。
惰性というより、既存リソースを捨て、学習コストをかけてまでリプレースする対象か？
と問われれば絶対にYESでは無いと思うよ。

フレームワークの機能をMVC別に区切った場合、ModelとControllerの機能だけでも十二分に便利だ。
当然Viewも包括して導入すれば、より恩恵は増すと思う。

でも >>352 にも書いた通りフレームワークと一緒に毎回Viewまで覚えるのは手間がかかる。
自分1人ならまだしも、自分以外がテンプレートを担当しているような現場では、
新しいテンプレートを周知させるのはコスト的に厳しい面もあると思う。

Smartyはアダプタです(ｷﾘｯ

>>390
＞自分たちとSmartyは絶対に正義なんだ、みたいな主張をしている
･･･被害妄想怖いなぁｗ
自分たちとフレームワークは絶対に正義なんだ、みたいな主張をしだした >>329がブーメラン浴びた結果じゃないの？
あぁ、自演か。

>>392
＞ゆえに、「テンプレートとしての構文の差を無くす為にSmartyが優れている」
＞という根拠は存在しない。

わー、凄いね。
君にとって以下3パターンを各フレームワーク上で動かす事と、
Smartyなり外部テンプレートエンジンで書かれた構文を各フレームワーク上で動かす事の手間は同じなんだね。

Zend <?php echo $this->escape($val); ?>
Cake <?php echo h($val); ?>
Symfony <?php echo $sf_data->get('hoge'); ?>


あとさ、Smartyに限らず、
「フレームワーク＋外部テンプレートエンジン」ってソリューションは多々あるけど、
外部テンプレートエンジンを使いつつ、フレームワークに依存しちゃう構文ってどんなの？
遭遇した事ないんだけど、どんなロジック混ぜちゃってるの？

それともSmartyって言葉が嫌だったかな･･･？
「テンプレート構文を吸収する為にTwigやsfTemplateEngineが優れている」とか言えば満足かな？

＞「Smarty信者が特に優位性の無い部分でSmartyを絶賛する」

こんなことしてるやついるのか？
どのレスのこと指してるんだ？ベンチマークとかの部分か？

どうでもいい。

俺はSmartyを「使う」からこのスレに情報を求めにきてるんだ
「使うべきか、否か」という話は別のスレでやってくれ。

ここは「使う」としたらどう便利に使うかというスレなんだ。

Smartyを理解している、使っている人はいちいち反論とかせずスルーしてくれ。
そのうえで荒らすために、反論を装うレスを荒らしがつけるだろうが、中身を理解してないからすぐわかるんだし