さて本題だけど

> 196が良いって、グローバル変数かつ、ショートタグかつ、エスケープ無しがView的にOKって事かい？

その考え自体がモダンじゃないんだよな。

<?=$name?>を実行するファイルの先頭に書いたら、何が表示される？
Noticeが出るだけだよね（PHP4だと出ないかも）。当たり前のことだ。

「PHP単体」という言葉自体がおかしくて、(SmartyだってPHPだしな)
<?=$name?>を実行するためには、まず$nameに値を代入する必要があるんだよ。
ロジックから$nameに値を代入する過程が必ずあり、そこで、
スコープの決定と、エスケープなどのビュー用の加工処理が行われる。

ちなみに、スコープの決定条件は、196とSmartyで等価だよ。
パーサのメソッドの中でincludeしたら、スコープはそのメソッドの中になる。

212のコードの欠点は、ビュー用の加工処理が、
本来HTMLであるべきファイルの中で行われることだ。Smartyも同様。

まあ、俺はSmartyを否定したいのではなく、
別の選択肢を提示して、それに対する意見を聞きたかっただけなので、
とにかくSmartyを褒めてくれなきゃヤダヤダ、という話なら正直困る。

>>248-249
DreamWeaverでしかページを作れないへぼデザイナーと仕事をするとか、
外注には出すがソースレビューしたくないという場合は、
大人しくWeb製作として依頼して、コーディングは自分でやった方がいいとおもう。

結局Smartyだろうが何だろうがビューはビューなので、
MVCが理解出来ない人にビューを作らせようとしてもうまくいかんし、
テストとデバッグは結局やらなきゃいけないんだよ。

デザイナーから見たら、実際どう描画されるかわからない記号の羅列を
マニュアルと変数名の指示書どおりにHTMLに書き込んでみたりして、
「たぶんこれで出来たと思うんですがどうでしょうか」と言わないといけない時点で、
それはプログラマー仕事としての負荷を被っているわけだよ。
実質的に、分業にもなっていなければ、責任の切り分けにもなっていない。

Smartyの良くないところをあえて挙げるならば、
「Smartyを使えば、へぼデザイナーとへぼプログラマーが協力出来る」という幻想を
蔓延させた事かも知れんねｗ

>>251
おまえさんはSmartyを否定してるんじゃなく、テンプレートエンジンを否定してるんだろ？
なら選択肢なんかじゃなくて具体的にどのように実装すべきかを提示してみてくれ

>>253
「PHPはテンプレートエンジンとしての要件を満たす」というのが196の主張だ。
>>229はそれを否定していたので、そこからして論外なのだ。

テンプレートエンジンとしての要件みたいなものを脳内で想像してるなら、
まずそれを考えなおして、表現してみてくれ。

「必ずキャッシュ機能が無いといけない」とか
「PHPとして実行できてはいけない」とか
そういう特殊な前提があるんなら、それを踏まえないとお前さんの役には立てんよ。

俺の要件に則って具体的な実装を述べて良いなら、
196こそが「テンプレートファイル」の答えなのだ。
$nameに何をどこでどうやって代入すればいいのかについては、>>251に書いた。

そうそう、ディスパッチャの存在が前提になるんだ。そこはSmartyと同じだな。

>>254
いや、だからな
>ロジックから$nameに値を代入する過程が必ずあり、そこで、
>スコープの決定と、エスケープなどのビュー用の加工処理が行われる。
の具体例を提示してみてくれって話なんだが

ぐだぐだ言い分けしてないで、
Smartyのここがだめ、俺ならこう書く！ってのをサンプル出せや。

PEARとかライブラリとか出してきてる時点で、ピュアPHPじゃねーし。
使う事を否定しないが、君なりの構築術があるわけだろ？

それを示せよ。何と比較してダメなのか、要所要所わかりやすく上げてくれ。

単にSmartyに馴染めなかった、Smarty使ってる人うぜぇ！
ってだけならすれ違いだから、よそで最高のテンプレートエンジンを開発してくれよな！

>>254
>「PHPはテンプレートエンジンとしての要件を満たす」というのが196の主張だ。
>>>229はそれを否定していたので、そこからして論外なのだ。

うむ、同意だな。PHPはそれ自体でテンプレートエンジンとして使える。

> テンプレートエンジンとしての要件みたいなものを脳内で想像してるなら、
> まずそれを考えなおして、表現してみてくれ。

テンプレートエンジンとしての要件は、ビューを分離できること、でいいと思う。

>「必ずキャッシュ機能が無いといけない」とか

キャッシュ機能はビュー層が単体で持つべき機能じゃないよな。
もつべきならコントローラ層だ。

>>256
>ぐだぐだ言い分けしてないで、
>Smartyのここがだめ、俺ならこう書く！ってのをサンプル出せや。
前スレ読め。とっくに出てる。

>PEARとかライブラリとか出してきてる時点で、ピュアPHPじゃねーし。
はあ？ライブラリを使っちゃだめとか、頭どうかしてんじゃねーの。
Smartyだってライブラリだろ。なんでSmartyはよくて、他はだめなの？ばかなの？
それにPHPだけで書かれたライブラリはpure PHPだろ。言葉の意味間違ってるぞ素人さん。

>使う事を否定しないが、君なりの構築術があるわけだろ？
>
>それを示せよ。何と比較してダメなのか、要所要所わかりやすく上げてくれ。
だから前スレよめって。>>193以降全部読め。

>まあ、俺はSmartyを否定したいのではなく、
別の選択肢を提示して、それに対する意見を聞きたかっただけなので、

>>193をそう解釈しろと言われても困る

>>256

>何と比較してダメなのか
→ PHPと比較して。

>要所要所わかりやすく上げてくれ。
>>238からのコピペ。
・SmartyでやろうとしていることはPHPでできる
・Smartyは学習コストがかかる
・Smartyは遅い
・Smartyのテンプレートでエラーがあった場合、その行番号がずれている


で、Smarty擁護派が>>240で反論してるけど、Smarty反対派が>>245-246で再反論してて、今はSmarty擁護派の再々反論待ち。
特にエラー行番号についての見解を期待。

何が見解だよｗｗ

>>エラーについて
君の出してるエラーは「Smartyエラー」じゃなくて「PHPのエラー」だねｗ
Smarty自体の処理ははあっておりコンパイルも通っている。
コンパイル後のPHP実行時に、ストリングに変換出来ないクラスをそのままassignして表示してるからPHPがエラー出してるんだろ。
Smarty以前の問題だ。素人レベルのミスだ。

行が違う！とか行ってるけど、
コンパイル後のクラスのライン5みりゃ1発で原因わかるよね。

PHP Catchable fatal error: Object of class MyClass could not be converted to string in /tmp/templates_c/%%C3^C35^C35E7879%%sample1.tpl.php on line 5


Smatyでのエラーは以下のように正しく表示される。

Fatal error: Smarty error: [in sample.tpl line 4]: syntax error: unrecognized tag 'test' (Smarty_Compiler.class.php, line 590) in /xxxx/Smarty.class.php on line 1092

＞PEARにいくらでもライブラリあるけど。プラグインは普通に関数でいいだろ。コンフィグも普通にPHPファイル。
ライブラリを組み合わせるのもSmarty使うのも同じだと思うが？PEARの優位性は何だろね。
関数はグローバル関数かい？ｗ

＞なんでPHPよりSmartyのほうが簡単で学習環境も整っているといえるんだよ。
逆もしかり。PHPの方が覚える事も少ないし、文法も完結だからだ。
何度も言うがショートタグが使えない現場は多い。

＞おまえこそほんとに測定したのかよ。明らかにSmarty遅いじゃねーか。
したよ。他のエンジンと比べて大差ねーよ。
View処理が 5 : 10 だとしてもビジネス処理に 50 かかれば 55 : 60 程度の差って事だよ。

＞エラーコード
上に書いた。PHPの変数の使い方から出直してこい。

＞必要な機能はPHP自体がもっている。
PEARとか別のライブラリや、スコープ確保の為にクラス化、関数化は必要だよね？
そうされた一式がSmartyって事なんだが。

＞拡張がし易い
プラグイン、フィルタ、リソース等、かなり楽に拡張できるが？

＞PHPそれ自体はSmartyよりはるかにメジャー
何度も言わせるな。「PHP単体」じゃ無理だろ。同じ事実現する為のライブラリの学習コストを考えろ。

＞フレームワーク
cake、Zend、CodeIgniter使ってる。全部ViewはSmarty拡張クラス組込済。

＞別の選択肢を提示して、それに対する意見を聞きたかっただけなので、

解ったから、具体的に選択肢を提示してくれよ。

ショートタグで値を表示するだけじゃ甲乙つけられないだろ？
ループ、エスケープ、インクルード、条件分岐が入ったViewテンプレートサンプルを上げてくれ。
それを見て「これならSmarty使う必要は無いな」と思わせてくれよ。

俺が出すサンプルは以下だ、
「ヘッダ、フッタを合成して配列の中身をテーブルに出力するだけの簡単な処理」

PHP側はこれでも処理が全然足りない。
インクルードファイルの管理や、ローカルスコープ化処理、エラー処理、etc。
結局細かい処理を考えるとSmartyと同程度までの実装は欲しくなってくる。(文法はおいておいて)
そこをライブラリや関数で補うって事なんだろうけど、
実際にそうした場合のテンプレートコードを上げてみてくれ。

>>262
>君の出してるエラーは「Smartyエラー」じゃなくて「PHPのエラー」だねｗ
>Smarty自体の処理ははあっておりコンパイルも通っている。

あほかお前、なんでSmartyのエラーかPHPのエラーかをここで区別する必要があるんだ?
エラーといわれた場所の行番号が違っていることが問題なんだろうが。
Smartyのエラーなんて、ただの構文解析でのエラーしかでねーじゃんか。
実行時のエラーには無力なうえ、変な行番号ででるんじゃ、使い勝手悪すぎだろ。
PHPなら実行時のエラーも行番号がずれることはない。こんなのあたりまえ。
実行時エラーを変な行番号でしか報告できないSmartyを必死に擁護するほうがどうかしてる。
「Smartyエラー」ってなんだよ、構文解析でのエラーじゃないからSmartyのせいじゃありませんって、アホか。
エラーの種類に関係なく、行番号がずれるのが問題なのに、
構文レベルエラーと実行時エラーを区別する必要がどこにある。

>>268
デザイナとプログラマの分業がなされているとき
構文エラーはデザイナ責任、実行時エラーはプログラマ責任。
PHPエラーがでたらプログラマが対処すりゃいい。

そもそも、>246のエラーは文字列に変換できないクラスをassignしないもしくは、
assignしたものが直接扱えない変数であることをデザイナに伝えていれば起きない。

>>268
アホはお前だろｗ
実行時エラー制御したいなら、Smartyに限らずassign時点で型判別しろよ無能ｗ
それこそSmartyとかPHP以前の話だよ。


＞エラーの種類に関係なく、行番号がずれるのが問題なのに、
ずれてねーよｗ　コンパイル後のソースでの行数で、ご丁寧にファイル名まで出てるじゃん。
スクリプト言語しか触った事無い素人には、実行時エラーのデバッグは難しいのかもしれんが、
普通のPGなら上のエラーコード読むだけで、エラー内容もエラー位置も特定出来るわ…

むしろ構文エラーじゃなくて、実行時エラーだって理解出来て問題識別しやすいわｗ


無能を晒してないで、
はやく>>265-266を君の考えた素敵で使い勝手の良いテンプレートに書き換えてくれよ。
はやく>>265-266を君の考えた素敵で使い勝手の良いテンプレートに書き換えてくれよ。
はやく>>265-266を君の考えた素敵で使い勝手の良いテンプレートに書き換えてくれよ。

こういう無能がdisplay_errorsをonにしたまま本番公開しちゃって恥ずかし思いするんだろうねぇ('_｀

>>268
＞エラーといわれた場所の行番号が違っていることが問題なんだろうが。

言いたいことはわかる。
でも、関数なんだから当然だろ。
引数が不適切なせいで、呼び出し先でエラーが出た場合を考えればわかりやすい。

いや、行番号の話はSmartyとsymfonyを混同した人の指摘？みたいだし、
エラーを追いかけたかったら良いデバッグツールを使えばいいと思うぞ。
PHP標準でスタックトレースも変数の中身も出せるわけだし。

>>263
SimplateいいぞSimplate。暢気な人には魅力がかわらんかも知れんが。
俺が考える「Smartyをわざわざ導入する際のデメリット」が結構解消されてる。
まあ、「SmartyはPHPで書かれている」という大きいメリットは殺ぐのだけど。

>>265-266はMVCを理解してない人の例という意味では良いサンプルだな。
>>271-273ありがとう。俺もせっかくなので一つ案を出す。

おはよう。

>>275
Simplateいいよね。 客先都合で使えない事が多くて泣けるけど。
>>265-266はMVC的にはどう書くのが正解？

レス番間違えた。272-273、素晴らしいコードをありがとう。
議論としては蛇足になってしまうかも知れないんだけど、
俺が個人的に>>212より>>196が良いと思うと言った部分を紹介します。

特徴（一長一短？）は、テンプレートファイルの可読性が高く、隠蔽されていること。
利点はHTMLからの移植性と習得の容易さ。
欠点は配列操作のコストを二重にかけていること。

改行が多いと叱られたので再挑戦。

>>276
>>272-273のように書くのが正解だと思う。
少なくとも、MとVとCがそれぞれどのファイルかわかるでしょ。

>>276
厳密には、こう考えると良いかも。やっつけだけど。

<? // こんとろーら
require_once 'init.php';
require_once 'model.php';
include_template('tpl.php', compact('rows'));

<? // もでる(model.php)
$rows = array(
array('time'=>time(), 'name'=>'foo', 'value'=>1),
array('name'=>'bar')
);

ちなみに俺は>>278のような書き分けをする時は、
tpl.phpの処理は、コントローラに近い場所に書いているかも。

>>196
君、MVCを全く理解出来てないよ。

データの表示フォーマット等に関するビューロジックは、ビュー側で処理するべき。
コントローラは必要なデータをモデルからひっぱってデータに渡すだけで表示内容には関与しない。
君の書き方だと、各種表示フォーマットやデフォルト値が変更になった時にビューで処理出来ないでしょう？

>>265-266と>>272-273の違いは何ですか？

MとCはコードに掲載していないだけでVとしては正しいと思います。
何が問題でしょうか？具体的に教えて下さい。

>>280
変更される度にtpl.phpに修正を入れるんだろうな
単純にテンプレートファイルとビュー用のデータ加工のphpを分けてるだけみたいだし

というか、やってる事はオレオレテンプレートエンジンな件について
要は生phpをテンプレートファイルにできればいいのかな？

>>282
ねｗ　多分中学生か高校生の熱血PG志望者だよきっと。

俺も若い頃は動作の重さに超敏感だったし、Smartyとか使う奴はアホかと思っていたｗ

>「Smartyをわざわざ導入する際のデメリット」

俺にはこれがわからん。
パッケージインストールもしくはダウンロード→インクルードパス下に解凍したらすぐ使えるよ？
習得の手間は人それぞれだろうけどおそらく196や周辺のPHP知ってるデザイナーは苦労したんだろうな。

>>281
んーと
「V」にだけ着目するならどっちもただしい、
それこそ全部echo文でもただしいのではとおもいます！

>>272-273は「SmartyでできることはPHPでできる」、の一部のサンプルとして
1. 変数・関数のスコープの限定の実現
2. 生PHP?のテンプレートとしての(そこそこの)書きやすさの実現
　(というかshort_open_tagの積極的な使用)
を主眼においてつくってみました。 >>266から>>273に代わって
何か問題が解決したとすれば、主にはView用変数・ユーザ定義関数がグローバルでなくなったこと
かなとおもいます(まちがってたらアドバイスください＞＜)。

じぶんはというと今テンプレートに
Smartyを使いつづけるか(といってもまだ使って一ヶ月ですが！)
否かまよっているところなので先人さんのいろいろな意見を参考にしたいところで、
最近このスレをみつけてせっかく興味のある話題にめぐりあえたのに
煽り合いばかりでおもしろくないなーとおもっているところです。

お前が煽ってんだろが

あ、>>277さん、こちらこそありがとうございます＞＜
最初はもっとボコボコに叩かれるかもとおもってたので…

>>286
煽ってないですが煽ってると思われたならあやまります。。
すみません

>>285
>>265-266
「V」に着目するだけというかVのサンプルですが…。
MVC的に見ても、MもCも混在していないので間違いがわかりません。
どこに違和感を感じたのでしょうか？


仕組みを学ぶのは良い事だと思います。
しかし、もう少しSmartyを使い続けてみて下さい。
不満点も沢山見つかると思いますが、メリットも沢山見つかると思います。
「SmartyでできることはPHPでできる」はパッと見出来てるように見えてるだけで、
細かい実装(商業では必須ね)考えると、相当な開発負荷がかかります。

>short_open_tagの積極的な使用
現バージョンのPHPの推奨設定ではshort_open_tag=offなので注意して下さい。
PHP6以降では廃止される可能性もあります。

>>285
Smartyでできる事を手間をかけてPHPだけで書いてもメリットないだろう
処理速度に多少のアドバンテージがあるくらいで、それも汎用的に書いていけば怪しい

個人的にはSmartyを使うメリットで一番大きいのは、使ってる人が多い事だと思ってる

SmartyもどきをPHPで作るくらいなら、俺はSmartyを使う。

short_open_tagは俺の趣味です。
「ファイルの末尾に ?> を書かない」と同じくらい、趣味の領域だと思う。
なので、xmlとか読み書きする人は気をつけてください。

>>280
そうだね。当然、MVCという区分上は、tpl.phpはビューに相当する。
「コントローラに近い場所に書いている」という実装が悪いのかな。
例えばsymfonyだったら、tpl.phpこそがhogeSuccess.phpであるべきで、
hogeSuccess.phpからhoge.htmlをincludeしたほうが妥当ってことだよね。
コントローラがinclude_templateを呼ぶのはイビツなんだな。なるほど納得。

それを踏まえて再度意見を戴きたいのだけど、
ビューが分かれててその一方がPHPだと、何かまずいだろうか？
モデルもコントローラも1ファイルじゃないといけないという理屈は無いよね。

>>282
そう。単純に「表示値の準備」と「表示処理」を分けているだけ。

> 要は生phpをテンプレートファイルにできればいいのかな？

ナマじゃなくてもいいんだけど、Smartyほど大げさなモノは、個人的には使わないかな。
テンプレートファイル部分は出来るだけ薄いほうが好き。

＞short_open_tagは俺の趣味です。
なんだ、ただのひねくれものか
お前、友達いないだろ？
お前、自分の事出来る職人だと思ってるだろ？
周りは確実に引いてるパターンが目に浮かぶ
もはやSmartyの話題でも無いので、MVCスレにでも行けや。

>>292
>>278のコードだけど、tpl.phpとbody.phpを合わせてSmartyで言うところのテンプレートだよね？
tpl.phpでデータを整形をして、body.phpは体裁のみを担当と…。

これは君の主張していた

　・Smartyより学習コストが低い
　・(デザイナが)Smartyで出来る事は実現出来る

には当てはまらないよね。

tpl.phpで扱える便利な関数群を提供してあげればいいんだろうけど、
それは>>290-291の言うとおり、結局は我流テンプレートエンジンを作る事態になってしまうよね。
であれば既に完成されたSmartyから乗り換える理由にはなり得ないと思うんだ。
もっとも君が我流テンプレートエンジンを完成させて、公開してくれれば別かもしれないが。

>>292
＞ビューが分かれててその一方がPHPだと、何かまずいだろうか？
＞モデルもコントローラも1ファイルじゃないといけないという理屈は無いよね。

ビューをファイル分割する事は、
メリットよりデメリットの方が多い気がするんだよね。

まず、ファイルが増えればバージョン管理やデプロイの手間が増える。

>>278の形式だとbodyの表示を修正したい場合、
読み込み元のtplを把握している必要があるし、
tplが読み込んでいるbodyが他に無いか等も把握していないといけない。

これは非常に面倒。

そんな理由で、どうしても整形処理を別ファイルにしたいのであれば、
tpl.phpからbody.phpを読むのではなく、
body.phpからtpl.phpを読むような形にするのが望ましいと思う。

<? // body.php ?>
<? include "tpl.php" ?>
<? $rows = $tpl->format($rows); // 整形 ?>
<? include "header.php" ?>

～ 表示処理 ～

<? include "footer.php" ?>

そうすると構文こそ違うものの、Smartyとやってる事はほとんど同じになる。
で、Smartyに相当するtpl.phpを作るのは誰がやるんだ…って話になる。

>>289
じぶんは>>264-267を見てつくってみたのですが
おっしゃってることがよくわかりませんでした。。

Smartyはまだ触ってみるつもりではいます！
>>290さんのおっしゃっるとおり使う人が多いのはよいとおもいますし
たしかカスタムタグみたいなこともカスタム関数でできるんですよね？？

ただSmartyに不満を持つたびに、
PHPをちゃんとテンプレートとしてつかえたら、とおもいます。
PHPを使いはじめてから、short_open_tagとか制御構文の別構文(endif, ...)とか
テンプレートとしてのPHPはすごくいい感じだとおもったので
PHPがちゃんとテンプレートとして進化しなかったのがざんねんです。

テンプレートエンジン上にテンプレートエンジンをのっけるという感覚が
今割り切って理解できなくなっているのです。。
short_open_tagがXML処理命令の規則に合わないのはあきらめるしかないです。。

PHPはすでにテンプレートエンジンとしては不全なんだろ。
それならSmartyを良くするとかもっと良いテンプレートエンジンを作るとかしたほうが生産的だと思うのだが。

まあ、PHPを良くするというのもありか。
しかしテンプレートとプログラムを同居させるというのはどだい無理があると思う。
Smartyのプログラム的文法もかなり無理やりだしな。

>>296
PHPは正確にはテンプレートエンジンでは無いんですよ。
テンプレートエンジンのようにHTML内に組み込めるようになっているだけなんです。

＞PHPをちゃんとテンプレートとしてつかえたら、とおもいます。
Smartyのテンプレートの中にPHPを直接書く事も出来ますよ。(非推奨ですが)
{php}echo "Hello World"{/php}

＞たしかカスタムタグみたいなこともカスタム関数でできるんですよね？
PHPが解る人なら簡単に作れますよ。

(例) タグ内の文字列を置換するタグ{replace}{/replace}タグを作る場合

block.replace.php というファイルをpluginsディレクトリの中に作成し、次のコードを記述するだけです。
function smarty_block_replace($params, $content, &$smarty)
{
retrurn str_replace($p["search"], $p["replace"], $content);
}

以降Smartyテンプレートで次のように記述出来るようになります。

{replace search="本当ですか" replace="マジッスカ"}
　{replace search="凄いですね" replace="パネェっす"}
本当ですか。
　　　　凄いですね。
　{/replace}
{/replace}

// 出力：マジッスカ。パネェっす。

一見、PHP単体でも簡単に実装出来そうに見えますが、タグの入れ子処理等を考えると地味に面倒だったり、テンプレートの可読性が下がったりしますよね。

>>294
tpl.phpが難しいから学習コストが高いということかな？

・PHPが理解出来ないレベルのへぼデザイナーはbody.phpだけ触らせるしかない
・Smartyで出来る事は理論上すべてPHPで出来る（し、その手段もそれなりに用意されている）

というのが俺の意見かな。
俺の環境はsymfonyで、sfFormか、helperか、sfSmartyViewPluginかの選択が必要なので、
既にSmartyで完成されたサイトとかを、わざわざリプレースする必要は無いと思う。

「SmartyはわかるけどPHPは触れません」というデザイナーって、結構多いのかな？

>>295
なるほど、俺にとっては斬新な発想だった。
ファイルの命名規則をしっかり決めれば、関連性はわかりやすいかと思ってたんだが。

tpl.phpは、デザイナーが作るのが理想だが、プログラマーがやっても構わない。
「$nameの表示はescapeしてnl2brしてください」という要件を把握出来るのが、
デザイナーなのかプログラマーなのかによって話が大きく変わるんだろうな。