>>51
こいつ来るだろうなぁと思ってたらやっぱり来たwww

しかしまさかMySQLがオラクルのものになる日が来るとはね・・

Javaも脂肪したからむしろPHP復活ｗｗｗ

空気読まず貼りますね
http://www.cbook24.com/shop/ProductDetail.aspx?sku=9784798022574&CD=F1000049&WKCD=F1000037

Zendも買っちゃえよｗ

PHPにフレームワーク要るか？少なくとも自家製テンプレートは本当に邪魔なだけだろ。

自家製テンプレートってなに？

Yiiイイヨー

Yii よくねえよwwwwwwwwwwwww

Yiiって速いらしいじゃん、ほんと？

>>57
同意。

・PHPは簡単だから、デザイナーやHTMLコーダーでもすぐに理解できる（分業が目的でもテンプレートシステムは不要）
・生PHPの方が、テンプレートの独自記法よりも多機能で便利

条件分岐や繰り返しは、生PHPで書いても可読性は確保できます
http://codeigniter.jp/user_guide_ja/general/alternative_php.html
だから、MVCのVも、Smarty等のテンプレートシステムはなくてもOK

キャッシングは？

acom

>>62
テンプレートエンジンの思想は、PHP構文を置き換える目的では無いよ。

・デザイナに与える権限を最小限にする(PHPを直に触らせない)
・結果的にコード記述方法が統一される
・PHP以外の言語からも再利用出来る
・キャッシングや独自タグなどの拡張が楽
・可読性が生PHPと比べて高い

等メリットはあるし、ケースバイケースだね。

>>63
FWに付いているページキャッシュ機能が使えればOKでしょうか

>>64
計画はご利用的に

>>65
>・PHP以外の言語からも再利用出来る
その発想はなかった…１本！

記述内容（≒作業中の意識）をレイアウト層に特化するといった意味でもテンプレートエンジンは有用。
ただHTMLもレイアウトを記述するためのものでは無いので、PHPやHTMLに毛が生えたような構文である必要はなく、
独自のテンプレート記述言語もいいかもしれない。
生産性の観点から言うとひとつのテンプレートからPC用HTML、携帯用HTML、Ajax用データetc.を吐けたりすると嬉しい。

WEBサイトのシステムは、MVCに分割すれば、それだけでも保守性の確保は十分だと思う。
VのところでSmarty等のテンプレートエンジンを使うか、使わないか？

HTMLの中にPHPのコードを埋め込めるから、生PHPそれ自体が一つのテンプレートエンジンとして使える。
生PHPよりも高機能なPHP製テンプレートエンジンってないから、生PHPは便利ですよ。

以前はSmarty使っていたけど、今は生PHPに戻りました＾＾
テンプレートエンジンを使う人には、それなりに理由があるだろうから、別に否定はしないけど。

> 生PHPよりも高機能なPHP製テンプレートエンジンってないから、生PHPは便利ですよ。

lol

これはひどい

生PHPに自動escapeがあれば検討に値するんだがな

>>71
そのくらい作れよ

>>71
FW側でエスケープできないの？
テンプレートでエスケープするの？

viewにオブジェクトなんか持って行くようなつくりだと、FW側でのエスケープは難しい、というか煩雑だろうな。
テンプレートの記述でちょろっと書いたらescape（または非escape）ってのが今のところベターな気がする。

生のPHPで E() とかグローバル関数を作って使ってもいいんだろうが、一気にきちゃなくなりそうだ。

>>71
例えば、

<? ?> #=> <?php ?>
<?= ?> #=> <?php echo ?>

に加えて、

<?== ?> #=> <?php echo エスケープ処理(); ?> （処理内容はPHP_INI_ALLで設定可能）

みたいなタグを追加する、とか？
こんな感じで実装されれば、ショートタグ全盛時代がくるだろうな。

そこまでして数文字節約できて本当に嬉しいの

>>76

<input type="text" class="hoge page" style="text-align: right;" name="hoge" value="<?php echo htmlspecialchars($hoge, ENT_QUOTES, 'UTF-8');?>"/>

<input type="text" class="hoge page" style="text-align: right;" name="hoge" value="<?== $hoge ?>"/>

うん。下の方が嬉しいな。

「文字数を節約する」のは特にメリットはないけど、
読みやすくする、その場所で大事でないことはあんまり目に入らないようにするっていうのは
とてもメリットがある。

テンプレートエンジン使えよ

>>75
どうせphp本体に手を入れるのなら、「出力は全て自動エスケープされる」モードを作った方がよくね。

俺は今、テンプレートに変数を割り当てた時点(FW側)で全てエスケープされるようにして、
変数にHTMLタグを割り当てた場合、テンプレート側でデコードするようにしている。
但し、>>74の言うようにオブジェクトは除いて別扱いせざるを得ない。
<?php echo や <?= なら自動エスケープ。<?== ならそのままってなほうがいい。

>>79
理屈はわかるけど、あくまでも、特殊処理をする方を特殊な書き方にした方がいいと思うな。
magic_quotesの悪い前例もあることだし。
それにそうしないと、例えばファイルに書き出すときにはモードをオフに、とかしなきゃいけなくなる。

まあおれの場合は実装の絡まない妄想だが。

htmlのレンダリングにおいてはescapeしないほうが特殊な処理だし、
安全性を考えたらdefaultでescapeのほうがいいと思うけどね。

>>80
ちょっと書き方が悪かった。
あくまでFWのview出力において全て自動エスケープ。

たとえば $view->display()としたときにdisplayメソッド内で自動エスケープをONにして
テンプレートスクリプト(生PHP)を処理していく感じ。

defaultでescapeとかまともに考えたらありえない。
magic_quotes以上のゆとり思考だろ・・・

<?== ?> タグ程度なら、自前で実装出来そうだし、
用意された機能で実装すりゃいいんじゃねーの？

それをテンプレートエンジンと呼ぶかどうかは別にして

何か問題でも?

>>83
なんでdefaultでescapeがありえないの？
いや純粋に・・・ゆとりですまそ。

>>83
前段二行は、まあPHPとはそういう言語（？）だと。
他にもmb_stringの自動変換とかsafe_modeとか、もろもろの余計なお世話で
成り立ってるんだし、他の機能と比べればHTMLエスケープの標準オプション化くらい
なんてことはない。

ただ、エスケープの為だけにタグを"スクリプトでの"実装はあり得ないなｗ
後半はそういう意図に読めるが、それだけのテンプレートエンジンなんて筋が悪すぎる。
PHP拡張としてパーサレベルで実装してあれば便利かな、ってものだと思う。

だからsmarty使えばいいじゃん
{$var}で解決よ

>>87
>>68,71 （とそのちょっと前から）の流れだってば。
そりゃ現実的にはみんないろいろやってるだろうけど、
仮定の話はそんなに面白くないかな？

じゃSmarty使わない理由をまとめてくれ

>>89
すごく消極的だが、前提ライブラリは少なければ少ない方がいい、とか。
Smarty以外にもテンプレートエンジンはあるし、どれも標準にはなり得ない。
最近のFWでもテンプレートエンジンを必須の前提にしていないものが大半だが、
その理由と同じってのでどうだろう。

俺は使えればSmarty使う派だから想像だけど。

数年仕事で使っているが、magic_quotesも、mb_stringの自動変換も、ショートタグも、大半の環境ではオフにされているんだが・・・
実装出来る手段が用意されていて、特別困るものでも無いのに標準機能として盛り込んでしまうと、
裏側の処理を理解していないゆとりPGが泥沼にはまるのが目に見えるわ・・・

そもそもPHPはHTMLを出力するためだけのモノでも無いし、
HTML出力に関しても100%エスケープが必要なものでもない。

>>91
> 大半の環境ではオフにされているんだが・・・

これらがデフォルトになったのはごく最近の話って認識なんだが。
register_globalsだけが少し早かったと。
実際今までだってここら辺に嵌るのがある意味通過儀礼のようなもんだっただろｗ

んで、逆にそういう知識が常識として定着した現状なら、いろんな機能がついてても
それほど問題にもなるまいという風に考えてしまうな

デフォルトでエスケープするのは、いろんなテンプレートエンジンでもそういう機能がある。PHP自体にあってもいいと思う。<?=を別のマクロにすればいいんだろ。エスケープし損なうぐらいなら、余計なエスケープしてしまった方が安全だから。

つうか、まだ懲りずにSmartyを使っているやつがいるんだね。あおりぬきで驚かされる。

php5.3RC2がでたようだけど、5.3になってから
これからのフレームワークは具体的にどう変化するの？

namespaceを使うものが出てくるくらいか？
それだけではそんなに変わりそうな気もしない
何より、フレームワークはあんまりすぐには新バージョンに追随しないと思う

late static bindingsの導入で静的メソッド主体のユーティリティクラスを
継承して拡張するのは楽になりそう。

>>97
これか
http://jp2.php.net/lsb

self::、parent:: に static:: が加わるってことでいいのかな。
しかしこれを読んだだけでは、parent::のstatic::バージョンも欲しくなりそう。
無いって事は、普通はいらないってことなのだろうか。

インスタンス取ってからすべきでは？