元スレ【PHP】 Smarty 【テンプレートエンジン】　第2章

php覧 / PC版 /

みんなの評価 :

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

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

301 = :

それだと結局の意味がわからん

302 = :

つまり、テンプレートを他人に編集させるWebサービスには
Smartyが多く使われている、って解釈で良いだろ。

そう考えると、一概に無駄とは言えないぞ。

303 = :

Smartyかどうかは分からないんじゃないの？
gooブログの有料版はパスにSmartyって入ってた(今は知らない)からSmarty使ってるんだろうけどさ

304 = :

ここ荒らしてるアンチは自分が取り残されてて悔しいんだろう

305 = :

>>303
MTはSmarty使ってるけど、MT系のブログって多いからなぁ

306 = :

くやしいのうwwwくやしいのうwww

307 = :

なにが？

308 = :

アンチはSmartyだけじゃなく他のテンプレートエンジンもいらねーって考え方だから話にならない

309 = :

だったら、PHPも使わなきゃいいのにな

310 = :

なんだかんだ、ここまで周知された技術だと新たに学習するのは非常に楽だと思う。

Ｓｍａｒｔｙ3ではエラーメッセージのロケール対応とか出来たら嬉しかったなぁ、

「xxxx.tpl ××行目付近、{foreach}タグが閉じられていません → 参考リンク」
「xxxx.tpl ××行目付近、{$var|escpe}、　escpe修飾子は存在しません　→ 参考リンク」

とか出せたらデザイナ側からのくだらない質問は減ると思う

311 = :

お前らみたいに趣味でPHPやってるような奴は
どうぞ勝手にSmartyとか使ってくれて構わないが
実際にプロの現場には持ち込まないでくれよ？
あくまでも趣味の範囲内でな？

313 = :

プロは言語もライブラリもケースバイケースに使い分ける。
手段の選択肢を、宗教じみた個人的感情で排除する輩は、プロというよりオナニストだな。

314 = :

質問です。
本とか見るとSMARTYよく載ってるんでいちおう使ってみたんですけど
自分の場合デザインとかHTMLも自分でやるんですが
この場合あえてPHPとHTML分離させるSMARTYって使うメリットありますか？
まだ慣れてないってこともあると思いますが使ってみて
ファイルの管理面倒だなーとか、ちょっとこのまま使い続けていいものか
迷ったもので、同じようにデザインもやる人でSMARTY使ってる人っているでしょうか。

315 = :

>>314
PHPとHTMLを分離させることは必要ですが、
Smartyを使うメリットは余り無いと思います。

Smarty自体はPHP4時代に結構流行りましたが、
今はCakePHPやsymfony等の有名どころのフレームワークが
ビューの部分は生PHPにしてますので
それに習うのが現在の主流です。

316 = :

>>314
ファイル管理に関してはロジックとビュー分離する時点でさほど変わらないかと。
一番のメリットはテンプレートが読みやすいって事じゃないかな。

●Smartyで書いた場合
<ul>
{foreach from=$rows key=id item=row}
<li id="{$id|escape}">{$row|escape|default:"デフォルト"}</li>
{/foreach}
</ul>

●PHPで書いた場合
<ul>
<?php
foreach ($rows as $row) {
echo '<li id="' . htmlspecialchars($id) . '">' . (strlen($hoge) ? htmlspecialchars($hoge) : "デフォルト") . </li>;
}
?>
</li>

317 = :

>>315
＞今はCakePHPやsymfony等の有名どころのフレームワークが
＞ビューの部分は生PHPにしてますので
＞それに習うのが現在の主流です。

単にそれぞれのFWが独自ビュークラスを用意してくれているだけで、
「推奨」されているわけでも「主流」なわけでもありません。

逆にCakePHP/symfony/ZendFW等の標準のビュークラスを使ってしまうと、
フレームワーク移行時にビューの設定や構文の最習得が必要になりますし、
それは容易ではありません。

またフレームワークとビュー関係のクラスが密結合されている場合もあり、
フレームワークのバージョンアップでビュー側にもバージョンアップが必要になる、等の弊害もあります。

枯れ果てたSmartyが未だ解説書等に見られるのは、それなりの理由があるんですよ。

318 = :

>>317
＞単にそれぞれのFWが独自ビュークラスを用意してくれているだけで、
＞「推奨」されているわけでも「主流」なわけでもありません。

CakePHPもsymfonyも独自ビュークラスなんて用意されてませんよ？

＞逆にCakePHP/symfony/ZendFW等の標準のビュークラスを使ってしまうと、
＞フレームワーク移行時にビューの設定や構文の最習得が必要になりますし、
＞それは容易ではありません。

Smartyでビュークラスを作っても独自のライブラリに依存しているので
対して変わりありませんよ？

319 = :

Smartyはスマートじゃないという矛盾

320 = :

>318
＞CakePHPもsymfonyも独自ビュークラスなんて用意されてませんよ？
Cake/symfonyで言えばヘルパーとう名でビューを扱う為のクラス/ユーティリティ群が用意されているよね。
用語の違いでしか無いよ。

＞Smartyでビュークラスを作っても独自のライブラリに依存している
密結合と疎結合って言葉知ってる？
フレームワークに内包されるヘルパーは密結合。

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

321 = :

で、お前らデリミタタグは何にしてるの？

322 = :

>>321
{{　}}やー。

>>315－319
ありがとうございます。
勉強になりました。。
フレームワークとSMARTY組み合わせてもいいわけなんですよねー。
SMARTYはざっくりですが覚えたんで実用でもせっかくなんで使ってみたいと思います。
とりあえず今度フォーム系でなんか機械があったら使ってみる。

323 = :

>>321
<{ }>

324 = :

>>320
＞密結合と疎結合って言葉知ってる？
＞フレームワークに内包されるヘルパーは密結合。

そんな密結合になっているフレームワークのヘルパーを
ワザワザ引き剥がしてまでSmartyを使う必要ってあるんですかねぇ。

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

アダプタパターンは使わないと思いますけど（笑

325 = :

顔真っ赤になってレスしてるんだろ？ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
自分だけsmarty使えないからって２ちゃんで同意を求めに来てるんだよなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

326 = :

>>325
信者ならsmartyじゃなくてSmartyって書けよ。

327 = :

>>324
＞ワザワザ引き剥がしてまでSmartyを使う必要ってあるんですかねぇ。

上に書いてあるだろ、
・フレームワーク別にヘルパーを覚える必要がある
・フレームワーク自体のアップデートがビュー側に影響を与える恐れがある
というデメリットもあるってこった。

趣味プログラマにはいいかもしれんが、
開発人数が増えれば増えるほど、このデメリットは如実になる。

＞アダプタパターンは使わないと思いますけど（笑

そりゃ君が無能だからだろ(笑)
Smarty使わないにしろ、ビュー用のインターフェースは別途用意しておいて、
各ビュースクリプトとのアダプタを作るのが、君の好きなモダンフレームワーク実装。

328 = :

そもそも開発人数増えて規模が大きくなる前提なら
デザイナにテンプレート触らせるとかまずありえない。

329 = :

>>327
＞上に書いてあるだろ、
＞・フレームワーク別にヘルパーを覚える必要がある
＞・フレームワーク自体のアップデートがビュー側に影響を与える恐れがある
＞というデメリットもあるってこった。

フルスタックのフレームワークに無理やり
外部のテンプレートエンジンをねじ込むんですか？
フレームワークの思想をまるっきり無視って訳ですね。

あと、フレームワークのビューには変更が入るかもしれないけど
Smartyのインターフェイスには変更が入らないという前提で
物を言ってません君？随分と都合のいい話ですね。

＞趣味プログラマにはいいかもしれんが、
＞開発人数が増えれば増えるほど、このデメリットは如実になる。

趣味でやってるのではないのなら尚更
Smartyなんていう外部ライブラリを使わない方がいいんじゃないですか？
君はSmartyは誰でも知っているみたいな言い方してますけど
誰もが知ってるわけじゃないし、人によっては好みもあるでしょ？
ま、私は全くもって好みじゃないですが。

＞そりゃ君が無能だからだろ(笑)
＞Smarty使わないにしろ、ビュー用のインターフェースは別途用意しておいて、
＞各ビュースクリプトとのアダプタを作るのが、君の好きなモダンフレームワーク実装。

無能ですか？そうですか。
私が例にあげたCakePHPにもsymfonyにも
アダプタパターンは合わないと思いますけど。
そんなに自分が有能なのならコード書いてもらえません？
多分できないと思うけど（笑

330 = :

>>328
ホントそうですよね。
普通の開発じゃ考えられないようなこと言ってますよねここの人達。
しかもそれを正当化。笑い話にもならないっつーの。

331 = :

＞君はSmartyは誰でも知っているみたいな言い方してますけど
＞誰もが知ってるわけじゃないし、人によっては好みもあるでしょ？

ここがSmartyスレだって事忘れてない？ｗ
好みの問題を持ち出すなら、それこそSmartyスレ見なければいいんじゃないの。

＞フレームワークの思想をまるっきり無視って訳ですね。

思想？どこにそんな事書いてあるの？
ZF、symfony、cakeはなんら問題無く外部ビュースクリプトを載せられるようになっているし、
ZFに至っては疎結合をウリにしているけどな。

＞あと、フレームワークのビューには変更が入るかもしれないけど
＞Smartyのインターフェイスには変更が入らないという前提で

Smartyに機能追加があろうが、フレームワーク自体を変更しようが
テンプレート側がその変更を意識する必要は無い。
Smarty自体がアダプタの役割も担うから。

もちろん他のFWでも独自にビュークラスを作ってやれば吸収出来るんだろうけど、
それは車輪の再発明ってやつだ。

333 = :

何でSmarty知らないと恥ずかしいの？
Smarty以外でもHTMLテンプレートエンジンは色々あるわけだし、
それにこだわる必要なんてないと思うけど。

Smartyの利点は枯れたライブラリで多くの使用実績があるのと、
>>332が言っている通りの知名度。
後発ライブラリはそれ以上のメリットもあったりするわけだから、
状況によって使い分けるべきで、フレームワーク云々の話がでるのは筋違い。

334 = :

営業会議の場でも普通にSmartyって言葉が使われる程認知されているのに、
Smarty知らないんじゃ恥ずかしいだろうよ。
現役かどうかは知らんが、Smartyの普及率は相当なものだ。

もちろんSmarty以外を使うのも有りだと思うし、
その場合はSmartyと比較してこんなメリットがあるんですよ。
って言える方が賢いと思うのよ。

今の子達は、頭ごなしにSmartyが駄目駄目言ってるだけで、
具体的に何が駄目で、どう改善すればいいのか、って案も無いみたいだし。
話しすすまんなぁ

335 = :

抜けちゃったけど、

Smatry牙城を崩したいのであれば、
とりあえずSmartyを覚えて、他の技術とのメリットデメリットを提示するべきだと思うよ。

俺個人としては、新しい何かは好きなので触る価値があると思えば乗り換えるよ。

336 = :

＞Smatry牙城を崩したいのであれば

最初からSmarty牙城なんてなかった
メリットデメリット言う前に、使われてないし、これからも使われることはない
それがアンチの考えだから

337 = :

でもスレには来るという謎さ

338 = :

アンチはコテハン付けてくれ

339 = :

とりあえず、Top 25 PHP template enginesってタイトルで
いの一番にとりあげられてるという事実があるわけで・・・

リンク先は消えてたんで、それを紹介した日本語のページを
http://gigazine.net/index.php?/news/comments/20060803_php_template_engine/

340 = :

2006年か・・・

341 = :

2006年の時点で既にメジャーだったって事でしょ。
それなのに知名度云々言ってるのは、素人としか思えない。

最近はPEARもFWに食われて目にしなくなったけど、
使えば便利なケースは多々あるし、手段として身につけておいても損は無い。
Smartyもそんな感じだと思うよ。

342 = :

アンチうぜえなお前らPHPくだ質のチンピラかＯＣＮだろ

343 = :

>>331
面倒なので手短に・・
フルスタックのFWに無理やりビューという大きな外部ライブラリを
ねじ込まないで下さい。
あと、アダプタパターンは無いわ（笑

344 = :

>>343
無いのはお前の頭だろｗ
興味無いならCakeスレでなれ合ってろよｗ

345 = :

フルスタック(笑)

Symfony2からは低レベルの枠組みはフルスタックで提供するが、
外部ライブラリを積極的に採用する方針に変わるけどね。
http://www.symfony-project.org/blog/2010/03/04/symfony-2-0-and-the-php-ecosystem

流行り廃りで言えばフルスタック自体が廃りだよ。
フルスタックFWを学習する事は、Smarty以上にコストがかかる上に、Smarty以上に将来性が無い。

アンチはRoRに毒されたCake厨が多いのかねぇ。
シコシコ独自の設定ファイルでも量産してろよ(笑

346 = :

>>344
アダプタパターン最近覚えたのかな？
Gofの基礎中の基礎だからね。
でもアダプタパターンは無いわ（笑

>>345
君はフルスタックの意味とアダプタパターン（笑）の使いどころが
よく理解できてないみたいだからもう書き込まない方がいいよ。
能無しがバレますよ？
大人しくSmartyの勉強でもしてなさいっ！

347 = :

別に他スレでしつこくSmartyの話をしている奴が
いるわけでもないと思うし
皆このスレで「大人しく」していると思うんだけど
なにをしにこのスレに？

348 = :

>>346
アダプタパターンは基底パターンみたいなもんだが、
君はアダプタが全く適用されないコードを書いてるのかい？
フルスタックという言葉に拘りがあるみたいだけど、君こそ言葉遊びしたいだけじゃないの？(笑

Smartyすら理解できない頭じゃ無理も無いが、
大人しくCakeをBakeしてればいいんじゃないかな？

349 = :

>>348
アダプタパターンっていうのはアダプティとなるクラス（Smarty）と
ターゲットとなるクラスが比較的近いインターフェイスでないと機能しないんけど、
SmartyのようなテンプレートエンジンとCakePHPやsymfonyのような
生PHP＋ヘルパ関数のビューをどのようにアダプタパターンで繋げるんですか？

ま、デザパタ覚えたので言葉を使ってみたかっただけかもしれないけど、
言うほど経験も知識も無いんだから、もうちょっと頑張りなさい。

350 = :

>>349
＞生PHP＋ヘルパ関数のビューをどのようにアダプタパターンで繋げるんですか？
ん？それは実装の前提が違くないかい？
フレームワークとSmartyを繋ぐ事が目的じゃなくて、フレームワークとテンプレートを繋ぐことが目的で、
共通のテンプレート構文を使う為のアダプタって事だよ。

CakePHP > CakeSmartyAdapter > template
symfony > sfSmartyAdapter > template
ZendFW > ZendSmartyAdapter > template

CakePHP / symfony / Zend等フレームワーク固有のViewやヘルパ関数を使うと、
templateがフレームワークに依存するよね(当然メリットもあるけど)
だから、疎結合なViewクラスを挟むのもいいんじゃね？って話だが。