元スレ【PHP】 Smarty 隔離スレ【テンプレート】

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

252 = :

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

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

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

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

253 = :

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

254 = :

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

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

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

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

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

256 = :

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

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

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

257 = :

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

258 = :

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

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

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

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

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

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

259 = :

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

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

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

260 = :

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

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

261 = :

>>256

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

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

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

264 = :

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

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

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

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

267 = :

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

268 = :

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

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

270 = :

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

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

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

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

274 = :

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

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

275 = :

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

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

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

276 = :

おはよう。

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

277 = :

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

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

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

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

280 = :

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

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

283 = :

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

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

284 = :

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

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

286 = :

お前が煽ってんだろが

287 = :

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

288 = :

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

290 = :

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

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

291 = :

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

293 = :

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

294 = :

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

これは君の主張していた

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

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

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

296 = :

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

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

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

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

297 = :

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

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

299 = :

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

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

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

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

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

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