【総合】PHPフレームワークを語るスレ8

前スレ
http://pc11.2ch.net/test/read.cgi/php/1181350116/

過去スレ

【PHP】フレームワークについて語るスレ7【総合】
http://pc11.2ch.net/test/read.cgi/php/1181350116/

【PHP】フレームワークについて語るスレ6【総合】
http://pc11.2ch.net/test/read.cgi/php/1171896620/

[PHP]フレームワークについて語るｽﾚ5[総合]
http://pc10.2ch.net/test/read.cgi/php/1159579507/

[PHP]フレームワークについて語るｽﾚ4[総合]
http://pc8.2ch.net/test/read.cgi/php/1151706907/

[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/

[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/

【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/

【洋モノ】

symfony
http://www.symfony-project.com/

code igniter
http://codeigniter.com/

Zend Framework
http://framework.zend.com/manual/ja/index.html

CakePHP
http://www.cakephp.org/

【和モノ】

ちいたん
http://php.cheetan.net/

Ethna
http://ethna.jp/

guesswork
http://classic.guesswork.jp/

maple
http://kunit.jp/maple/

乙。

話の続きだが、MVCの分離がいらない（利点がつかめない）というやつは、オブジェクト指向も理解していない可能性が高いな。

すまん。こっちのスレで質問すればよかったorz

転載

990 ：nobodyさん ：sage ：2007/10/16(火) 19:21:01 ID:???
コントローラとビューって
本当にファイルとして分ける必要あんのかな？
大抵のFWはディレクトリが根本から分かれてるから、
対応関係の確認が微妙にもたついたりする。
同じファイルの前半はコントローラ、後半がビューでもいい場合も
多いんじゃないか。

991 ：nobodyさん ：sage ：2007/10/16(火) 19:32:35 ID:???
990 ：nobodyさん ：sage ：2007/10/16(火) 19:21:01 ID:???
コントローラとビューって
本当にファイルとして分ける必要あんのかな？
大抵のFWはディレクトリが根本から分かれてるから、
対応関係の確認が微妙にもたついたりする。
同じファイルの前半はコントローラ、後半がビューでもいい場合も
多いんじゃないか。
>>990
MVCを理解してくれ

992 ：nobodyさん ：sage ：2007/10/16(火) 19:38:00 ID:???
mvcは名前つけただけだからどうでもいいが、mvcが表す概念の価値が理解できないならいまの主流のフレームワークは使えないな。

993 ：nobodyさん ：2007/10/17(水) 15:10:03 ID:deo3V8qx
>>990
大昔はそうしてたよ。
処理を終えてからHTML部分に組み込んでいたyよ。
でも、それってMVCではないんだな。

転載その２

994 ：nobodyさん ：sage ：2007/10/17(水) 15:35:13 ID:???
>>990ではないんだが、俺もmvcあまりよくわかってないと思うんだ
相乗りさせてくれまいか

mが独立してるべきってのは納得なんだが、
c１にv１のとき１ファイルでもいいんじゃまいか？
とかおもっちまうんだが、１ファイルにしちゃだめな理由って何なのかな？

smartyとか使ってる＝なし崩し的にvをsmartyで独立実装
って感じになってるだけで、本当の意味でcとvを独立させる理由
ってのを理解してない気がするんだ＞俺

といいつつ、cとvが独立してれば、vを他のテンプレートシステム
での置き換えが用意なんだろうな。とは思うんだが、
cとv分けることのメリットってこんなもん？

経験豊富な人教えてくれまいか？

転載その３

995 ：nobodyさん ：sage ：2007/10/17(水) 15:41:10 ID:???
vにロジック書くと共有しにくいとか。
たとえばロジックは同じだけど状態によってviewが変わるケース

996 ：nobodyさん ：sage ：2007/10/17(水) 15:46:31 ID:???
ｖとｃを１ファイルにするくらいならｖとｍじゃね？

997 ：nobodyさん ：age ：2007/10/17(水) 15:47:15 ID:???
ロジック（プログラム）とデザインの分離で、C+MとVは分かれる。
ロジックは、データと処理に分離すると、MとCに分かれる。
だから、全体としてMとVとCに分かれると。
大雑把にはこんなかんじになるのでしょうか？

cがmとv、その他環境や条件などを制御する
c→m1→m2→v1、条件によってはv2・・的なことを実現する場合もある
そのcとvを１つにソースにって俺的にメリット無し
mとvを１つにってのは処理によっては考えられなくもないかな・・

つまりあれだ、簡単にいうとcはindex.phpと考えれば解りやすいかな？

index.phpは画面の遷移だけをするのがきれいじゃない？
FrontControllerで各々のControllerにディスパッチするのがMVCの主流なはず。

>>10
994さん宛てに、そこ(MVC)にたどり着く前の説明(例)として書いただけ

ついでに
＞index.phpは画面の遷移だけをするのがきれいじゃない？
index.phpはリクエスト受取り、cにdispatchするだけ。
画面遷移うんぬんはcの仕事

フロントコントローラーってちょっと好きじゃなかったけど、
最近はやっぱ便利だな〜って思えるようになった。

■Akelos
http://www.akelos.org/

■Rhaco
http://www.rhaco.org/

これらについても語ってくれ。

いじったことない

股間は毎日いじってるくせに！

なんで知ってるんだ

おいおい俺にこたえさせろよ同士

Python、Djangoを使ったことないから、Rhocoのメリットは正直分からない。
Djangoを使ってる人が、仕事でPHPを使わなきゃいけないときに役立つのかな？
いずれにせよ、選択肢が広がっていいことだ。
開発者さん、頑張れ！

チュートリアル、ドキュメントの乏しいFWは、あまり取り組みたくないかも。
中を調べるのが楽しい人はいいだろうけど。

携帯電話に対応したページを作るときに、セッション管理はどうしていますか？
各フレームワークは、簡単に対応できるのでしょうか？

よくブログで厨二病発言してるﾂｷﾐﾔﾀﾝが出来る言うてたよ。

PHP4ってpublicじゃないメソッドは_付ける作法あるじゃん
プロパティーは、
普通はpublicなものはない（protectedまたはprivate)から、
必ず_付けるの？
あるいは非publicは前提として
privateだけ_付けてprotectedは付けないとか？

多分privateだけ_つける。
CakePHPでは、__でprivate　_でProtectedをあらわしている。
本来のオブジェクト指向でいえば、プロパティは隠蔽すべきだからおっしゃるとおりだね。
本当なら、作法とかのレベルじゃなくて言語的に間違った実装したらエラーだすべきだよね。
Rubyなんかは、自然とオブジェクト指向で組めちゃうから組み方だけは、ペチパーも真似しちゃえばいいかも。

ありが�d
__でprivate　_でProtectedって発想はなかった
分かりやすいからcake方式でいこうかな

お役に立てて何よりです。

あまり気にする必要はないだろうけど
__（2つのアンダスコア）から始まるメソッド名はPHPによる予約とされてるので
そこだけ注意

関数の返り値で数字を返す時、
phpdocsの説明にintって書く？mixedって書く？
phpの場合、整数を返す時にも実際には文字型だったりするわけで・・・

んなわきゃねえ
integerで返せばintegerで返る
おまえが数値表現できる文字列を返してるだけだろう

いやその通りだけど
返却する時に、
数値表現文字列をわざわざintvalで数値型に変換してから返したりは普通しないだろ？
そうなるとphpdocにintと書くのは正確ではなくなる
とはいえ、意味としてはint…
という時に、他の人はどう書いてるのかと思ったのさ

ふむ
そういう場合で文字列が返るなら@return stringにする
数値表現できる文字列が返るってのを
明示的に書いておいた方がいいようなケースはその後にコメント書けばいい
integerって書くならちゃんとキャストして返す
とにかくPHPとしての型を厳密に書く

うーん
やっぱりintを明示したらキャストしなきゃいけないか…

>>30
当然のこと。
マニュアルでintとなっていれば===で比較できるものだとユーザは思う。

確かに===の比較の可能性があるな
勉強になりました

フレームワークって本当に生産性あげてるかと言えば微妙じゃね？
ファイルがやたら増えて、訂正の必要があっても
どのファイルを直せばいいか考える→それを探す
の人的シーク時間の累積が重い
railsで2年かかって完成できなかったのがphpだと3ヶ月で完成できたって話が
前にあったが
あれもruby vs phpというより
フレームワーク使用 vs フレームワーク非使用
に近いだろうし

それは何も考えずに適当につくってるからだろ

ファイルがやたら増えるのは
適当だろうが適当じゃなかろうが同じじゃん
設定ファイルがやたら分かれてるFWもあるが
必要が発生してからどこ触ればいいか直感的に分からん

フレームワークの生産性を否定するなら
もうちょっと説得力のある理由を提示しろよ
修正でどのファイルを直せばいいか探さないと分からないって
全然そのFWに慣れてきってもいない状態なのに
その時点で生産性も糞もないだろうが

探すって言ってもソースを見るんじゃなく（見ることもあるが）
ファイルを目で探すんだよ
でもそれにだんだんイライラしてくる
なんでこんなにファイルがバラバラにあんだよと

いったい何のファイルを探してるんだ。
基本的にMVCのそれぞれ、外部ライブラリ、設定ファイルぐらいしか無いだろう。

そんな苦労したこと無いよ。
どうやったらそんな事態になるのか、煽りじゃなくて教えてほしいよw

フレームワークという言葉に、生産性だけを
期待するのは幻想
フレームワーク使うことのメリットが小さいと
思うなら、使わなければよいさ
まぁ、生産性って何なのか？定義にもよるがな

module/C005105Action.class.php
module/E103592Action.class.php
module/E214163Action.class.php
module/S118626Action.class.php
module/S118629Action.class.php
template/C005105Template.class.php
template/E103592Template.class.php
template/E214163Template.class.php
template/S118626Template.class.php
template/S118629Template.class.php

みたいになってんじゃね？ｗ

findもgrepもできない奴が
FWの生産性がどうとか100年早いよ廃業しろ

フレームワーク病の患者が多いな

%%04^044^04484218%%Facdevfr.tpl.php
%%08^080^080A2CE8%%CedefrghRegistInput.tpl.php
%%09^094^094CDD11%%MailswdeTemplatexxx.tpl.
%%0A^0A2^0A2BEB0A%%DiaswdefrgtLoose.tpl.php
%%0A^0A5^0A593314%%WdefrvfbgInput.tpl.php
%%0A^0AD^0AD7EC35%%CfrxsnhSuccess.tpl.php
%%0E^0E4^0E407559%%footer.tpl.php
%%0E^0E8^0E807051%%CkodenbSuccess.tpl.php
%%0E^0EA^0EA391ED%%editsssfser.tpl.php
%%10^103^103D5C31%%GlpbcdgeExec.tpl.php
%%10^107^1072EA43%%CbgmqbcSuccess.tpl.php
%%11^115^115E53D5%%CksbwczyqInput.tpl.php
%%13^132^1324373B%%DlskdjfInput.tpl.php
%%13^134^134E030D%%Mailowksncty.tpl.php
%%13^13C^13C3A5EB%%addqs231.tpl.php
%%14^141^1411511F%%O1jsncb6t.tpl.php
%%14^141^1415AFDA%%Ekwiqofff.tpl.php
%%17^175^17581685%%inquirylwecoo.tpl.php
%%1A^1A5^1A56EE3E%%GbsvxoooImage.tpl.php
%%1A^1AF^1AF524A1%%Aixos9Mail.tpl.php

こんなとこ探してるんじゃね？ｗ

フレームワーク病って言葉があるなんてはじめて知ったｗ

HTMLでサイト作っているやつが、
PHP病と口走っているのを
見ている気分だｗ

フレームワーク病も知らずにフレームワークを使ってる技術者なんて・・・
銀の弾丸は存在せず
あらゆるソリューションはトレードオフでしか判断できないのだから
マイナス面も直視しなくてはいけないよ

>>45はPHPのくだすれにも出没して、見当違いのちゃちゃ入れてそうだなｗ

ファイルが分散したり、ドキュメント見ながらディレクトリ名やファイル名つけたりしなきゃならなかったり、余計めんどくさいことが多い。別に分業するわけでもないしよ。フレームワークに限らず、テンプレートなんかもそう感じる。

適材適所って言葉知ってる？

>>48みたいな人って汚いソースを書いてそうだな

俺は、フレームワークのおかげでソースがきれいになった
いままでが糞すぎただけだが・・・
乱雑なものが整列するさまは、まるで歯科矯正みたいだわ
俺にはこの縛りが心地よいよ

どMじゃん

俺もソースのキレイさに拘ってきたが
Google adsense for mobileのGooglerのコード見てちょっと考え変えた
グローバル空間を平気で汚してるんだぜ
俺は思ったね
これで必要かつ十分じゃないかと
PHPをJavaのように使う風潮が広まっているが
PHPはPHPの良さを活かして使うのが正しいと

「フレームワークのおかげでソースがきれいになった！」(51歳/無職)
友人に勧められて軽い気持ちで始めてみました。
戸惑う暇もなく、すぐにフレームワークの虜になってしましました！
乱雑なものが整列するさまは、まるで歯科矯正のよう。
この縛り心地は本当に癖になっちゃいます。

グローバル空間を簡単に汚せるのがPHPの良いところ、と？

ソースコードがきれいかどうかってのと、
コードの動作がきれいかどうかってのは、別問題だと思うよ

動きゃ良いよ。あとは慣れてる方で。

>>54
ちょっｗおまっｗｗ
俺のプロフ晒すなよｗ
ちなみに、プライベートでは縛るほうが好きです

他人の書いた綺麗なソースより
自分の書いた汚いソースが読みやすいのは当然だからな

１ヶ月前に自分の書いた汚いソースより
今自分が書いた汚いソースが読みやすいのは当然だからな

汚いソース量産無限ループ

ファイル1枚で済ませられる用事を、わざわざドキュメントルート外の深いところにスクリプト作って、それを呼び出してぐちゃぐちゃやる必要が本当にあるのか。

他人や未来の自分にとっても、ちょっとコメント書いてあれば済むのに、わざわざドキュメント書いたり読んだりしなきゃいなんて手間もかかるし、いったい誰が得するのかと。
いくらソースが美しくても、追いにくかったらそれは美しくないよ。

もちろん規模によりけりだが。

ちっさいバリーデーションクラスも一クラス一ファイルにしたりするからな
やってる処理はたいしたことないのに大げさすぎ

小さい処理は小さい処理をまとめたクラスとかにすればいいのにな

ファイル 1枚で済む用事にすべてフレームワーク使えだなんて
どんなフレームワーク信者でも言わないと思うが……

フレームワークじゃないoopが最強じゃね

hoge.php　←アクション
hoge_input.php　←テンプレート
hoge_confirm.php　←テンプレート

これを全部同じディレクトリに入れる形にすれば、
アクションとテンプレートが並んでいていいきゃもしんない。
アクションとテンプレートを大本でディレクトリから分けてたから
絵あわせするのが面倒だったが

ちーたんが変な名前じゃなかったらなぁ

なんで「ファイル 1枚で済む用事に」とか極端な例を出してくるんだろうね？
好きにすりゃいいのに。
詭弁で主張したいだけ？

JavaでStruts、PHPでSmartyを最初から使っている俺には
フレームワークは普通です。

それは良かったね。

>>67
Smartyがフレームワークだとでも?(w

語るに落ちるとはこのことだな。

Smartyは糞だってことくらい
今じゃ小学生でも知ってます

ふーん、ごりっぱですねｗ

>>69
君の勝利！！！
あんたが大将！！！

語(かた)るに落・ちる
《「問うに落ちず語るに落ちる」の略》問い詰められるとなかなか言わないが、
かってに話させるとうっかり秘密をしゃべってしまう。

日本語って難しいですねｗ

フレームワーク使うのと使わないのは
結局トレードオフを考慮して決めるもんだからな。

たとえばphpinfoを呼び出すだけのものに、
フレームワークを使ったら時間がかかる。

逆に、データベースを読み書きするもので、
リクエスト(post・get)を投げるアドレスが
5つ以上あるようなページではフレームワークを使ったほうが早い。

まあ、そういうトレードオフの間隔さえ持っていれば良いよ。

フレームワーク != テンプレートエンジン

YOU、フレームワークって何時も喧嘩の種になるからワクワクしちゃうYO!

普通はプログラムが大きくなれば、
開発・管理しやすくするために
ファイルを分けるもの。

これには誰も異存はないと思う。

そういうときに、どういう風にフォルダを作っていくか。
ロードするパスをどうするか
そういう決まりが作られているだけでも
フレームワークは便利だと思うな。

もちろん、URLにアクセスしたら、どのメソッドが呼ばれるかや
データベースにアクセスするにはどうするかというような基本的な土台が
できていることが一番便利なところなんだけどね。

>>75
お前はもういらない子

SEOのために、URL短くしたり、あるいは指定されたりした場合、どうすればいいの？
パラメータは良いけど、アクション名とか、イミフだからやめてって言われちゃったりした場合。

>>79
お前はフレームワークを無理して使わなくていいからw

自分が必要ないと思うなら使わなきゃいいだけの話。
他人にまでそれを押し付けるなよ＾＾；

routingの設定変えりゃいいだけじゃね
最近のFWならどれでもurl routingの機能ついてるっしょ

なぜパラメータは良くてアクション名がダメなのか？

seoとかいってるやつは大体業界のクズ

そのクズに仕事とられたのか？ｗ

yamadaフレームワークって知ってる？文字通り、日本人が開発したみたいなんだけど、
今度使う事になったんだ。

でまた、フレームワーク毎のお約束事を、ドキュメント読んだり覚え直したりググったりしなきゃならん訳だ。

同じフレームワークを使っていれば
一度覚えるだけで良いから楽なのにね。

それだとスキルが鈍磨していかね？

>>88
同じ言語を使っていれば
一度覚えるだけで良いから楽なのにね。

フレームワークを使わなければ、
フレームワークを覚えなくて良い代わりに、
自分でアプリの構成・骨格（＝俺俺フレームワーク）を
作らなくてはいけないから大変だな。

自分ひとりでやるのならそれでかまわないが、
複数人で開発（それが普通）するのなら、
他人は、俺俺フレームワークを覚えなくてはいけない。

フレームワークは効率いい流れをつかむもので
それ自体を使ってはいないな。アレンジして理解しながら
やってるんで時間はかかるｗあくまで参考書的位置づけだな

>>91
覚えるならまだしも、不具合が恐いな
有名なフレームワークなら使っている人も多いから
致命的な不具合はだいぶん取り除かれている

フレームワーク使ったら負け
そんなの常識だろ

>>94
見えない敵と戦っている人がこんなところにw

戦士に敬礼ッ

ある程度の規模のWebアプリを、
生産性や保守性、拡張性を考えながら何回か開発してると、
結局FW的なものに行き着くんだよね。

それでFW的なものが色んな所で開発されると。

仮にそのプログラマが十分に優秀な人なら、
それなりに出来の良いオレオレFWになるわけだけれど、
企業として考えるとオレオレFWだと学習コストやら、
何やらでトータルコストがかさむ。

雇われるプログラマ側としても、
第三者からは得体のしれない社内FWを使いこなす技術なんて、
身に着けても資産価値が大してない。

それに、優秀な人っていうのは数が少ないから優秀と呼ばれるわけで、うんこFWが世界中で開発されて、それを使わざる得ない状況なんてうんこな場面も世界中で繰り広げられていると。

実際、メジャー所のFWのソース読んでると勉強になるよ。
本当に良く考えられてるなぁ、頭いいなぁ、と。

巨人の肩に乗ってるから、っていうのは当然あるだろうけど、
巨人が気前良く肩を空けてくれてるんだから、
普通の人は戦うんじゃなくて乗ればいいんじゃないのと。

プログラマはプライド高いから無理だな
プライドすてれるやつがビジネス的に成功すんだが

プライド捨てても成功できない奴、沢山いるんだがｗ

×プライド捨てると成功できる
○成功する奴はプライド捨てれる

×捨てれる
○捨てられる

このスレを見ている人はこんなスレも見ています。(ver 0.20)
【トイプードル】プードル Part26【ﾐﾆﾌﾟｰｽﾀﾝﾌﾟｰ】 [犬猫大好き]

>>102
俺もそれ気になってたんだよなｗ
PHPerがトイプードルなんかに興味持ってんじゃねえぞ
PHP書きが飼っていいのは金魚までだ

フレームワークの勉強を教えてください。
よろしくお願いします。
（オススメのサイト、本など）

このスレの最初に出てるサイト見ていったらいいじゃん

>>101
言語学に詳しくないやつがそういうつっこみすると浅いからやめた方がよい。

いやそれは普通につっこまれるところだろｗ
言語学とかいうレベルじゃねー
一般常識の話だ

ら抜き言葉が微妙なのは認めるけど、いちいち指摘してる奴は気持ち悪いと俺は思う。

君がどう思うかには興味はない

そうですか。興味はなくても、まぁそう思う人もいるという事で。
俺以外にも結構いると思いますよ。

ら抜き言葉はいけません。

×ほれる
○ほられる

普通にらぬき言葉と呼ばれる表現は方言として存在している。つまりは関西人が関西弁話したら、正しく日本語を話なさいというのと同様に、方言を認めないということになる。
らぬき言葉が方言としてしゃべられているかは別として、言語がさらに日々、経済的になっているだけの話し。（無駄は口語では省かれていく法則）
100年前の年寄りも現代の言葉は乱れていると嘆いたそうだぞ。つまりは、繰り返される無駄な議論。
無知が半端な知識で語らないほうがよい。無知同士の馬鹿な話し合いならいいが、知識人にそんなこと言ったら恥ずかしいぞ。
長文失礼。

> 話し

はなしし?

揚げ足とろうとするまえに辞書引いたらいかが？

受身と可能をら抜きか否かで区別できるくらいまで
どちらかがどちらかとして定着してほしいなーと常々思っている
日本語は気をつけて使うとかなり論理的な会話が可能な言語だと思うのだけど
ここだけが非常に曖昧なんだよねー


フレームワークの話に結び付きそうで結びつかないが気にせず投稿

なーにが知識人だよｗ
ら抜きが通用してるなんてことは、誰でも知ってるだろ。

「話」は名詞
「話し」は「話す」の連用形

言葉には文法がある。
フレームワークにも使いかたがある。
言葉が乱れている人の思考回路では、フレームワークをうまく使いこなせない可能性はあるのだろう。

「ら抜き」言葉はよく聞くけど、会話ならOK＝言いたいことは分かる。文章に書くときは、らを入れるように気を付けている。
バグに敏感なプログラマーなら、「ら抜き」言葉に抵抗を覚えるはずに、一票。

perl プログラマなら気にしないかもしれないよ？ｗ

そもそも「乱れている」と捕らえること自体が
多様な受け止め方のひとつでしかないわけで。

自然言語と、自発的に変化できないプログラム言語とを、
混同して考えるのもよろしくないな。

いくらなんでも頭固すぎ。

smarty とか prado とか mojavi とか symfony とか、
なに使えばいいんだYO！

agavi

派生しすぎでよくわからん…

>>121
このスレでsmartyの名前を出すといろんな意味でバカにされるぞw

>>124
そうなの？テンプレート使った出力用のライブラリとしては
手軽だしいいと思うんだけど。

>>125
そうなの？と聞く前に過去レスくらい読め

ここでsmartyって見るたびにsymfonyと間違えてるのかと思う

smartyがﾃﾞﾌｫﾙﾄｽﾀﾝﾀﾞｰﾄﾞなのはｶﾞﾁ

smartyは昭和の遺物

smarty使うとトイプードルに噛まれる

smartyでちょっと聞きたいんだけど、デザイナーがdreamweaverとか使ってる時はどうしたらいい？
例えば、htmlとimgディレクトリが実際の場所と違う場所に置くことになるから、相対パスで指定できないじゃない？

src="/hoge.gif"と、ドキュメントルートからのパスで指定して貰えば良いけど、やりにくいらしく嫌がられるんだが…

Smarty使ったことあるけど、何であんなもん使うのか理解不能。
普通にPHPで書けばいいじゃんって思う。

>>132
１人で全部できるHPやｼｽﾃﾑ作ってるならそれでいいんじゃね
ちっちゃいちっちゃい規模ならね

俺、それなりの規模のアプリも作ったことあるけど、個人開発したことしかないからなぁ。

symfonyでも使われているらしいphpmailer触ってるが
setter,getterなしでプロパティーに直アクセスすんのな
これだからphpのoopは(　ﾟ,_･･ﾟ)ﾌﾟﾌﾟｯ

smarty(　ﾟ,_･･ﾟ)ﾌﾟﾌﾟｯ

Smartyのメリットを上げる時に、「プログラムとテンプレートが分かれているので云々」って
見かける事多いけど、Smartyじゃなくても普通やるだろｗｗって感じだからなぁ。

http://ihc.mydisk.jp/

Smartyの最大のメリットは、<?php echo $hoge ?>が { $hoge }と書ける事。
(<?= $hoge ?>でいいじゃんってツッこみしないでね。宗教戦争になるから。）
これだけでいいから、Symfonyもなんか考えて欲しいよ、テンプレート機構。
そこが解決されれば、文句無し最強PHPフレームワーク、だと思う。
CakePHPはその辺連携取り易いのにな。

CodeIgniterが軽い理由は、Vが良いせいか？

>>135
> setter,getterなしでプロパティーに直アクセスすんのな

setter,getterなんて使うのはJavaぐらいなもんだろ？

> Smartyの最大のメリットは、<?php echo $hoge ?>が { $hoge }と書ける事。

ところで、 { } を使っている人いる？
違う記号に置き換えたりしない？
<{ }>とか。

>>142
jsやcss部分を{literal}〜{/literal}なんて面倒だから
普通は変更してるんじゃないか？
<{}>とか<!--{}-->とか{{}}とか・・

>>141
PHPとJavaしか知らないのかな?

わざわざ煽ってないで「こういうのもありますよ」って事例を示せばいいのに。
日本人ってなんでこうなんだろうね。

異邦人乙ｗｗｗ

たとえば C# とか getter/setter あるじゃん。

まともなOO言語は普通getter/setterあるだろ
簡単に書けるようになってる言語もあるが
PHPはそうじゃないし

C# の Property 機構は良いねぇ．言語的にきれいにまとまってるし．

でもそれをもって C# に getter/setter ありといえるなら
PHP だと __get()/__set() があるから言語的には「getter/setterあり」といえると思うけど？
（どうせ後付け条件で「あんなのはgetter/setterじゃない」と言い出すんだろうけど）

ていうかむしろ Java にこそ getter/setter が存在しない（ただの命名慣習）わけだが．
Java 7 では getter/setter を廃して property 構文を新規に作ろうって動きもあるわけだし．

ｱｸｾｻﾒｿｯﾄﾞ

OOPって面倒くさいですね。
お役所の手続き事務みたいに決まりごとが多すぎる。
でも、それを悪いとは思わない。
仕組みを考えた人は頭がいいと思う。

プログラムって面倒くさいですね。
お役所の手続き事務みたいに決まりごとが多すぎる。
でも、それを悪いとは思わない。
仕組みを考えた人は頭がいいと思う。

PDTでsetterとgetterの生成やってくれればいいのに

getterはgetXxxって名前よりもプロパティ名そのものが好き

それだとプロパティーと区別付かないじゃん

ｱｸｾｻﾒｿｯﾄﾞ
↓
ｿｻｱｯ('A`)ﾒﾄﾞｸｾ

（操作、面倒くせ）

むしろアクセサ介さずにアクセスする方が気持ち悪い
内蔵に直接手を入れてうんこ取り出してるようなもの

readonly/writeonlyなプロパティは別として
読み書き可のプロパティをpublicにしない納得いく理由を挙げてくれ
気持ち悪いとかそういうもんだからとかは無しで

セックスって面倒くさいですね。
お役所の手続き事務みたいに決まりごとが多すぎる。
でも、それを悪いとは思わない。
仕組みを考えた人は頭がいいと思う。

まったく関係ないセックスの話がしたいのならよそにいけ

スレ違いだ。
よそ行って来い。

まったくだ、このスレの人間はセックスなんて・・・

>>158
後から変更する可能性があるから

プロパティを大量に晒すクラス書いたことないから、
セッターとかゲッターとかもあまり書いたことない＞おれ。

>>137
>Smartyのメリットを上げる時に、「プログラムとテンプレートが分かれているので云々」って
>見かける事多いけど、Smartyじゃなくても普通やるだろｗｗって感じだからなぁ。

同意。それをさもSmartyの利点のごとく語るやつがいてさ、は？とか思った。
Smartyなんていらない。PHPで十分。
つか、Smarty遅くね？PHPファイルをincludeするほうが3倍速かった。

>>165
Smartyはページキャッシュが欲しくて使ってる

つ PEAR::Cache_Lite

>>137とか>>165が作ったオナニープログラムよりはよっぽどマシ
速い遅いとかっていつの時代のサーバを使ってるんだ？w

ネイティブとSmarty比べてるのにSmartyのほうがマシらしい。

おまえらにSmartyの何がわかるんだよ！

Smartyはデビュー作だけ大ヒットしたものの
その後まったく鳴かず飛ばずで
今は地方のスーパーとかを回っている演歌歌手みたいなもの

テンプレートってのはそもそもが
htmlを吐き出すときに、コードで書かないといけない。
コードで書いたらごちゃごちゃして見にくい。
htmlをそのまま書いて、その一部に変数等を埋め込めばいいんじゃね？
という発想で作られたもの。

だからhtmlをそのまま書いて、そこにphpコード埋め込むことが
できるphpでは最初っからあまり意味が薄いものだった。

デザインとロジックは分離するよ。だけどディレクトリ構造まで分離させると、あちこちに散らばってめんどくさい。

変数出力の記述がシンプル、なんて利点をあげる奴もいるけど、出力用の関数を作っといて、
function o($arg,$escape=true){
     if($escape){
          $output=htmlentities($arg);
     }
     echo $output;
}
↑たとえばこういうの作って<?o($hensu)?>てな感じで書けばHTMLもスッキリでしょ。

ええとtruncateはー･･･ああマルチバイトだめなんだ、じゃあ自作修飾子をー･･･とかsmartyのドキュメント見ながらやったりするよりよっぽど早い。
大体、修飾子が連なると読みにくいから、そんなのはロジックの出力直前くらいで整えておく方がいいし。だったらSmartyの必要が無い。

キャッシュはPEAR::Cache_Liteなどで事足りる。


Smartyの素晴らしさを教えてくれ。マジで。

o('obj.arr.value') という書き方で

$obj['arr']['value']の値を表示させるってのもありだよな。

PHP自体がテンプレートだから
テンプレート(＝PHP)の上層に作られたテンプレート(＝Smarty)
って構造
SmartyはPHPに無い＋α提供してくれる
と理解してて、Smarty使いこなしてるなら何も言わないけど、
大多数はなんとなく時代の流れ（？）で Smartyって便利だぜー
って言ってる様な気がするんだヨナー

ごめん、$escape==falseの場合はもちろん$output=$arg;しといてね。

スレチだけど、似たようなパターンでよく使ってる関数をひとつ。

d($arr){
    echo "<pre>";
    print_r($arr);
    echo "</pre>";
}

デバッグ時によく使う。

そうそう、Smartyはほんと良く出来てるよね
<?php echo $hoge; ?>なんて書かずに{$hoge}だけだし
{foreach}{foreachelse}や{section}{sectionelse}、{if}まであるし
{strip}なんかも便利{$hoge|nl2br}なんてこともできるし・・その他多々いろいろ

まあつまり>>173みたいな素敵なコードをわざわざ書かなくていいってことだ！

制御構造とかの文法がださいのが嫌
自由度も低いし

177だが、要は使いたい奴は使えばおｋってこと
自分で作れる奴はそれを使えばおｋってこと

>>178
SmartyはHTMLテンプレートですよ
デザイナーが使えりゃいいんです 使いやすけりゃいいんです

>>179
実際デザイナーにsmartyのtpl丸投げできてるところってあるの？
foreachとか入ってて、結局デザイナーが作ったHTMLを
Smarty形式にマが組み込んでるほうが多い気がする。

>>180
まったくだ

デザイナーに使える奴がいないと、結局自分の余計な仕事が増える
ってか今まで使えるデザイナーに出会ったことが無い･･･orz

>>178
＞自由度も低い
とかいっているヤツは、だいたい使いこなせなかったヤツだったりするｗ

>>183
Smartyで自由度を使いこなすとデザイナがわからなくならない？

使いこなすほど醜くなるのがSmarty

PHPでSmartyのようなテンプレエンジンがなぜ必要なのかわからん。
デザイナーにシステムに組み込んでからHTMLなんぞいじらせるべきじゃない
デザイン云々はCSSでやらせるべき
その方が効率的

ｻﾞﾜｻﾞﾜ…

smartyが作られた国ではデザイナとの分業がはっきりしてるケースが多いのかね…。
日本のIT土木と違って。

使いにくいとか言うやつはだまって使わなければいいだけなのに、
なんでいちいち欠点をあげつらうのかね？
オレオレテンプレートエンジンを自慢したいだけか？

○ITドカタ

>>189
使わなくて済むならいいけど、つかうことを強要されてるんで
どこかで愚痴りたいとか

プログラマチームが全員完全にSmartyを理解していて、ドキュメント等を何も見なくてもサクサク書けるレベル、
かつ、デザイナーチームもテンプレートとドキュメントルートの位置関係とか、{Smartyのコード}等をちゃんとわかってる現場なら、使う意味はあるかも。
っていう程度。

>>191
日本には仕事をやめる自由くらいはあるぞｗ

>>189
お前の論調で行くと
使いやすいと言う奴は黙って使ってればいいってことになるな

なぜフレームワークのスレでここまでsmartyの話をするのかｗ

2007年ももう過ぎ行く季節だというのに
Smartyてｗ
Smartyてｗ

とっくの昔に結論出てるのに今更SmartySmarty言ってる奴は原始人

そこでPOHPですよ。
PHPではKwartzぐらい?

>>194
使いやすいと言う奴については何も言及はしていない
論理を勉強して来い

>>199
屁理屈の練習は別でやればいいよ。
ここはフレームワークを語るスレ

Smarty派頭悪すぎワロタ

>>200-201
おまえら頭悪すぎ
ろくなプログラム組めないんだろうな

>>202
外の空気吸ってきなよ
深呼吸すると落ち着くぜ

まあ、高校生くらいなんだろうな
匿名掲示板でも底は見透かされるから無理はすんなってことだ

言っとくけど>>202はスーパーハカーだからすごいプログラム組めるよ？

長期休みみたいなどうでもいい流れになってるな

smartyという単語が出てきた時から嫌な予感はしてたが

・・・そろそろ、やめようか・・・。

・・・そうだな・・・。

（ガッチリ握手）

俺がここらへんでペチパー全体を馬鹿にすりゃ丸くおさまるんじゃないか？

Ruby脂肪ｗｗｗｗ

底は見透かされるから(笑)

ここではSmartyイラネ派が優勢なのか・・・時代も変わったものよのう。
昔は、いくら「include()で十分」といっても、だれも賛成してくれなかったのに。
いい時代になったのう。

Smartyはのう、テンプレートのデザインを崩してしまうタイプのテンプレートエンジンじゃから、デザイナーにはウケが悪かった。Dreamweaverと相性が悪いでの。
XOOPSがはやっておった時代、XOOPSがSmarty使ってたもんじゃからデザイナーでも試してみた人がけっこう居たんじゃが、Dreamweaver使いからはいい評価を聞かんかった。テキストエディタ派は黙々と使っておったがの。

しかし素のPHPは <?php echo htmlspecialchars($var); ?> があまりにめんどいからの、プログラマーの中には嫌うものもいた。
しかしこれも>>173みたいにちょっとしたユーティリティ関数かけば済む話での。そんなことすらできんやつもいるから、PHPユーザがばかにされるでの。

>>177
>まあつまり>>173みたいな素敵なコードをわざわざ書かなくていいってことだ！
数行のコードを書く手間と、Smartyのマニュアルにらめっこする手間とを考えれば、結論はおのずとわかると思うんだがの。
だからPHPユーザがばかにされるでの。

今Smartyと遊んでいる俺に謝れ！

時代は変わったっていうか
2005年頃既にSmartyは終わってたと思うけど。
ちょうどsymfonyが出てきて
「templateは生phpでいいじゃん」「Smartyいらなくね？」「むしろ氏ね」
みたいな流れが大勢になった。
まさか今更Smartyなんて言葉をこのスレで見るとは思わなかったな

今テンプレートエンジン前提にしてるFWってどんだけあんの？

xoopsやらのwebアプリはsmarty使うのやめて欲しい。

Ethnaって違ったっけ？

>>216
お前が人間をやめれば解決する

smarty派のタチの悪さが
smartyの評判をますます落としていくｗ

Smartyはプラグインが蓄積されてたら{$hoge|huge|hage}で簡単にオレオレ関数呼べるし、
そう悪くはないと思うけどなあ。確かにOSSでの採用は微妙だけど。
そもそも重量級のサイトには使えないし、
DWで崩れちゃヤダヤダなデザイン屋にはPHPTALでも使うしかない？

とりあえずSmartyに限らずテンプレートエンジンが必要か否か、
から始めようじゃないか。

Smartyを使ってる人、
Smartyは使ってないけど別のテンプレエンジン使ってる人
生PHPの人がそれぞれいるだろう。

>>221
まだやる気か
○しますよ？

>>219
タチの悪さ( )笑

２ちゃんねるは初めてなのか？

>>214
>2005年頃既にSmartyは終わってたと思うけど。
>ちょうどsymfonyが出てきて
>「templateは生phpでいいじゃん」「Smartyいらなくね？」「むしろ氏ね」
>みたいな流れが大勢になった。

それはないのう。生PHPよりSmartyのほうがもてはやされてたし、いまもその傾向が強い。
Smartyイラネ派はいつもマイノリティーじゃい。今日がはじめてじゃないかの？勢力が逆転してるのは。
流れが悪くなったら船をコロコロ乗り換えるおまえさんみたいなやつは昔から多いがの。

まあ、生PHPだとテンプレートに何でもかけてしまうから、できることを制限させるという目的でSmartyを使うのはありだとは思うがの。

過去スレ読んでない奴多いなｗ
このスレでは毎回Smartyﾌﾙﾎﾞｯｺだったよ
てかもう飽きた
テンプレートエンジン専用スレなかったっけ
そっちでやってくれないか

２ちゃんが世間と一致していると思っている奴ハケーンw

smartyとか言いだしたのプードル飼ってる奴じゃね？
このスレじゃ歴史的に禁句なんだよ
毎回無駄に荒れて何も得るものがないから。

お前の職場にトイプードルを飼ってるPHPerはいないか？
そいつが犯人！

なんかこういう流れは前にもあったなー、と思ったら、JavaでのEJBとPOJOの流れによく似とらんかいの？
昔、EJBが全盛だったころは猫もしゃくしもEJBを使おうとしておっての、EJBが使えないと一人前とは見なされなかった。
その時期に「EJBは複雑すぎる。もっと簡単なソリューションがあるはずだ」といってみても、お前の頭が悪いからEJBを使いこなせないだけだろ、と一喝されたものだ。
でも結局はIoCだのDIだのPOJOだのがでてきて、SpringやHibernateが主役になった。あれだけベンダーが金をつぎこんだEJBはもはや誰も見向きもしない。
あの当時、EJBを誇らしげに語ってたやつやベンダーは、今はそんなことはまるでなかったかのように「これからはDIだ」とか語ってんの。自分たちが今まで間違ってたことはなかったことになってるらしい。

Smartyから素のPHPへの回帰も、規模は小さいけどよく似てないかの。みんながSmartyだと言ってたから、よく考えもせずにSmartyを採用してたというのが本当のとこじゃないかの。
みんながSmartyといえばそれを持ち上げ、Smartyいらないという流れになれば立場を変える。EJBのやつらとなんも変わらんわの。どっちも自分の頭を使ってない。
Ruby on Railsは変なテンプレートエンジンを使ってなくて、eRubyをそのまま使ってるけど、単に使ってるというんじゃなくて、自信を持って「他のテンプレートエンジンはいらない」と言い切ってる。
Railsの作者はよくわかってる。PHP陣営も見習ってほしいのう。

　　　　　　　　　　　　　　さて、アニメでもみるかの。今日は何があったかの。

>>229
それがこのｽﾚでとっくの昔に出てた結論だよ
PHPer馬鹿にすんなよ

言ってる内容は陳腐とはいえ特に問題ないが
「自分は分かってる。自分以外はバカだから分かってない」みたいな口ぶりがムカつくので
賛同してやらん。

またもやアニオタはダメだとの論拠が強化された。

>>176
単純だけど便利になったわ
今まで単にvar_dumpしてた

>>232
駄目っていうか思いこみが激しいな
まあどうでもいいけど

http://journal.mycom.co.jp/news/2007/10/29/013/images/001l.jpg
Rubyは公式ロゴが決定したというのにぺちぱーは醜い内部抗争ﾜﾛｽｗｗｗ

>>230
とっくの昔ってどのへん？
過去スレならどのスレのどのあたり？

>>231
Smartyユーザ乙。
おまえの賛同なんかだれもいらんと思うが
少なくともRailsの作者はわかってる、と書いてある。

>>221
生PHP + 自作関数　かな。

俺俺FW作ってるけど
リクエストパラメータとエラーメッセージを
どうやってviewに渡すかいつも迷う
mojavi系みたいにRequestクラスを作るかとか
関数の中のstatic変数に保持させようかとか
静的クラスに保持させようかとか・・・
選択肢が多くて決められねーyo

requestオブジェクト作ってcontextオブジェクトにぶち込んどけばいいんじゃね
と、勝手に思うけど、好きにやってみて改良改良・・がいいんじゃね
俺俺FWなんだから　そんなの考えてたら他のFWと同じに（ｒｙ

ZFでリクエスト周りってどうなってんの？
Zend_Requestみたいのないけど

Zend_Memory コンポーネントは、 限られたメモリ環境でデータを管理するためのものです。
メモリマネージャが要求に応じて メモリオブジェクト (メモリコンテナ) を作成し、
必要に応じて透過的にスワップ/読み込みを行います。
たとえば、あるオブジェクトを作成あるいは読み込むことによって
メモリの使用量が制限値を超えてしまう場合に、 管理しているオブジェクトのいくつかをメモリの外部の キャッシュにコピーします。 このようにして、管理しているオブジェクトのメモリ使用量が 制限値を超えないようにします。

どんな仕組みだこれ？
PHPの限界超えてねーか？

素敵コードを書けない>>177のために、かわりに書いてみた。
http://anond.hatelabo.jp/20071030034313
Smartyの倍は速いエンジンだ。アプリケーションが倍速くなるわけじゃないけど。

>>177
>そうそう、Smartyはほんと良く出来てるよね
><?php echo $hoge; ?>なんて書かずに{$hoge}だけだし
これでわかるだろ、自作関数をちょっと書けばSmartyなんかいらないことが。
それすらできないやつが「{$hoge} だけで済むSmartyはよくできてる」とかいってる。
そして今日もPHPユーザがばかにされる。残念よのう。

でもまあ foreachelse みたいなのは PHP にもあっていいかもな。
Pythonにはあるようだし。

素敵。
これにゴテゴテ機能をつけずに、1枚includeすれば便利に使えるってのが一番美しいと思う。

>>242-243
こいつら、昔のLinuxユーザと同じ間違いを犯してる

>>242
つっこむのもなんだけど、 #{} の中に } が入るとエラーになるよ。

convert_template のコメントを見て思いだしたのだが、
file_put_contents には LOCK_EX の指定ができるのに、
file_get_contents には LOCK_SH の指定ができないのは何故なんだ。

>>242-243
ｶﾜｲｿｳ..

何故クラス化しなかったのかが気になる。

Smartyを擁護する気は毛頭無いが、自作関数自作関数言ってる人は、
よっぽどでかい案件か、もしくは自分で遊ぶアプリしか作ってないのかな？って思う。
何件もやってると、如何に「自分流」を入れないか、という事を気にするな、俺は。
メンテするの俺じゃないし。
・・・、本音を言えば・・・、自分流を入れると、後々それが間違ってたとして
バカにされるのが怖いっていうのもあるｗ 純正で対応してくれるならそれが一番！
でかい案件だと、色々と手を加えないとダメなんだろうな、とは思う。
俺は<%　%>を廃止しなければ幸せになれるんじゃないだろうか・・・と思ってる。

置き換えだけだったら意味薄くね？
かといって制御構造取り入れるとブクブク太って醜くなる
生php最強

ちゃんと学校に行ってるのかが気になる。

60行でバグ出すなら実績とるわな…

>>251
激しく同意
「自作で」とか言っている奴はこのあたりが分かっていない

>>252
>>251は俺に対する皮肉（？）でしょ？
別に<?php echo 〜 ?>に限った事じゃなく、自作O/Rマッパーとか。
また、 ｆｕｎｃｔｉｏｎ o(){・・・} やら ｆｕｎｃｔｉｏｎ d(){・・・} やら、自分で使う分には
全く問題ないと思うよ。俺も自分で使う分にはよく使うよ。すっげー便利。
ただ、自分以外もメンテするものに使うのはどうかな？と思ってる。
そもそもそんな関数名、命名規則違反じゃないの？そのプロジェクトで。
で、そんなものをいっぱい量産するのはどうなの？って事。
と、思ったけど、場面々々で有効、無効あるから、この言い争いは無意味だったね。
すまん。

なんにでも完璧はないし、ケースバイケースだと思うがな
何はどうあれ、ちゃんとコードを書いて晒した >>242 に賛辞を送りたい
へこむなよ ＞ 242

>>253
>>248にも激しく同意だから
>>251は素直にそのままの意味で解釈した。

実際、>>245で突っ込みが入っているし

別に>>242がコードを書いて晒さなくてはいけない場面でもないのに、
勝手に晒して「それすらできないやつが」などどほざいた挙句、
すぐにつっこまれている奴に賛辞は送れないな

テンプレートエンジン厨は去れ

>>258
自作厨(笑)

フレームワークの話題スタート↓

フレームワークの話題フィニッシュ

>>260-261
ちゃんと/**/付けろよｗ

Smarty叩きとHTML_QuickForm叩きはこのスレの永遠のテーマだな

そんなこと言ったら今度はQF厨がくるかららめぇ

>>245
> つっこむのもなんだけど、 #{} の中に } が入るとエラーになるよ。
それは仕様。Perlじゃないから式の中に { } が出てくるのはまれ。実用上問題ない。<?= ?> とか <%=h %> よりはこっちのほうがいいと思うがの。
どうしても使いたいなら
<?php $var = ' } を使った式'; ?>
<span>#{$var}</span>
とすりゃあいい。もしくは改造するか。
でも file_put_contents() で LOCK_EX の指定ってできるんだ。知らなかった。サンクス。

>>248
問題はそこじゃない。この程度の関数で済むものを、わざわざ大げさでかつ大して便利でもないテンプレートエンジン使ってることを問題にしてるんじゃがの。
Smartyと同じ規模のものを自作関数で作ったというなら248のいうことももっともだが、たかが数十行に対してこの見解は的外れ。

数十行ごときのプログラムをバグ無しで書けないような奴は、どの道･･･。

( ^ω^)おっおっおっ

一連の流れが自作自演に見えてしまうｗｗｗ

>>249
書き換えだけでも十分役に立つ。<?php echo htmlspecialchars() ;?> は頻繁に使う機能だから、それが簡潔になるのは大きい。
そもそも元のPHPが十分な機能をもっているんだから、あまり付け加える機能はない。
といいつつ、自分が使っているのはレイアウトテンプレートをサポートしているがの。

>>251
バグってどのこと？まさか>>245のことをいってるんじゃないよね・・・
もし
> #{} の中に } が入るとエラー
が問題なら、Smartyでも同じ問題おこるから、そっちのほうが大問題だがの。
Smarty派はそれについてはスルーかの。

>>252
数十行のコードすら自分でバグ直せないのか。。。そいつはすまんかった。話の前提が間違ってた。そういうことならSmartyでもなんでも人任せにできるものを使ってくれ。

わしにしたら、バグがあったとしても、小さい自作関数ならその場ですぐに直せるけど、Smarty規模になると自分ではなかなか直せんから、自作関数の方を選ぶがの。メンテナンスのことを考えた上で。
まさかSmartyにはバグがないとかいうやつはおらんと思うけど。

とりあえず、作ってみた姿勢は評価するんだけどね。
preg_replace()だけだからわざわざ作る必要も無い気がする。
（初心者には便利だわな。）

しかし、ここはフレームワークのスレなんだと何度言ったら（ｒｙ

・・・まぁ、ここにはフレームワークとテンプレートエンジンの区別も付かない奴しか居ないんだからしょうがないか。

>>269
＞わしにしたら、バグがあったとしても、小さい自作関数ならその場ですぐに直せるけど
>>248の言っていることを一蹴している割に、ぜんぜん理解してないことがバレバレｗ

>>270
ふ〜ん、ごりっぱですね

最後の一行で煽ってるあたり、まだまだ論争を続けて欲しいように見受けられる。
270は嫌々言いながらも攻められるのが好きなドMなんだ。そうだろ？

>>265
最近のFWは<?php echo htmlspecialchars() ;?>なんてしないよ
アサイン時に一括エスケープするから
symfony,ci,モダンなFWはだいたいそう
smarty派も非smarty派もテンプレートエンジンに拘ってる時点で旧式
もしかして過去から書き込んでるのか？

>>273
未来からは書けないと思う。

なんだQuickFormも使いこなせない奴が多いんだな
馬鹿ばっかりか

フレームワーク採用する何て言ったら気絶しそうな勢いだな。

ツールを作る人間もいるというのに、使えただけで俺はすごいとか妄想できるって幸せだな

フレームワークに使われてる奴多いなププ

∩ｱｲ

ソース読め的なレベルの質問で本当に申し訳ないのですが、DIコンテナを使用したフレームワークってどんな感じの作りになっているのでしょうか。
色々ググって見たのですが、スキルが低いため、説明を読んで見てもいまいちイメージ出来ません。（依存性の注入？とか。。）
シングルトンで各オブジェクトを引っ張って来てるみたいですが、このあたりが肝だったりするのでしょうか。
くだらない質問かと思いますがよろしくお願い致します。

>>280
Javaスレにいったほうがいいんじゃない？
そっちのほうが活発だから。

あとシングルトン自体はあまり肝じゃない。
ぶっちゃけ規約で制限してもできることだから。

>>277
> ツールを作る人間もいるというのに、使えただけで俺はすごいとか妄想できるって幸せだな

すでに存在するツールを作っても車輪の再発明と言われるように、
どんなアプリにも共通する土台（フレームワーク）を再発明したら馬鹿だろ・・・

使えるものは使わないとね。

テンプレートエンジンでもフレームワークでもこの際どっちでもいいんだけど、
それらを自作してるやつって一人で作ってるか、プロジェクトで自分の
作ったフレームワークが採用されたってことか？
なんかここの流れ見てると、プロジェクトの各メンバーが
「今回のプロジェクトでは俺の自作フレームワークを使おうぜ！」
となりそうな気がする。
プロジェクトで使うためのフレームワークを社内開発したというならまだわかるんだけど。

>>275
> なんだQuickFormも使いこなせない奴が多いんだな

QuickFormってたしか、コードでFormの項目にあたる部分を定義したら
それに相当するHTMLとチェックコードを生成してくれるライブラリだっけ？

コードでデザイン作るようなものでMVCになっていない。
これ使ってもデータベースと連携するところまでは楽にならない。
ということでフレームワークを使い始めてからは
こんなライブラリは使えないと思うようになったよ。

フレームワークはいいんじゃね？Smartyがダメなだけで。

Smartyはただのテンプレートだから・・・
フレームワークのビューの部分でしかない。

ああQuickFormとかは有り得ないと思ったな。
毎日毎日同じようなもの作るんだったら良いかもしれないけど、忘れた頃に作るとなるとマニュアル見て、('A`)ﾒﾝﾄﾞｸｾ

Quickformは一時期はまった
あの発想自体はいいと思う

最新のフレームワークを使ってないと過去の人らしい。
>>273
>アサイン時に一括エスケープするから
エスケープしたいのとしたくないのが混じってるときはどうするの？

>>289
rawコンテナみたいのも提供してるからそこから取り出すように出来てる
FWを使っていてエスケープせずに表示したかったことは
まったくといっていいほどなかった、というのは藤本神のお言葉

昔作ったSmarty+QuickFormな遺産があって今でもメンテしてる。
当時の俺にコンポーネント指向ってのが頭にあったらもう少し
うまく使いこなせてたんじゃないかなと思ってる。　>　QF

>>283
>なんかここの流れ見てると、プロジェクトの各メンバーが
>「今回のプロジェクトでは俺の自作フレームワークを使おうぜ！」
>となりそうな気がする。
なるわけがないー
全員ひきこもりでコミュニケーション能力がないとその可能性はあるけど、
普通は互いに考えをぶつけ合ってひとつのものを作るわな。
たいがいは一人スキルの高い人がいて、その人が中心になるけどな。
283こそ創造的なプロジェクトの経験がなさそう（あったらごめんね、でも経験があればそんなこと書かないよ）

>>290
>rawコンテナみたいのも提供してるからそこから取り出すように出来てる
これ、blogやwikiみたいなの作るときは無駄過ぎね？
$html = parse_wiki($wiki);
みたいなのがあって、これをビューに渡して表示させたいとき、当然HTMLエスケープはせずに表示するよね。
でもアサイン時に一喝してHTMLエスケープしたら、$html も問答無用でエスケープされるんでしょ？
wikiやblogだと $html の中身は長くなるから、必要のないエスケープが毎回強制的に実行されるのはすごく無駄だ。エスケープ処理はけっこう重いよ？測ってみたらわかると思うけど。

>FWを使っていてエスケープせずに表示したかったことは
>まったくといっていいほどなかった、というのは藤本神のお言葉
それほんとか？
$html = nl2br(htmlspecialchars($text));
みたいなのしょっちゅう出てくるけど。
あとは<pre<で表示するコードを色付けして表示したいとき
<pre<<?php echo htmlspecialchars($code); ?></pre<
ではなくて
<pre<<?php echo parse_proram($code, 'javascript'); ?></pre<
にするし。
レイアウトテンプレートを使ったら当然エスケープしないし。

>>290
そりゃ作るシステムによりすぎだろう
WikiとかCMSみたいのとか作ってると
エスケープしたくない場合なんていくらでもあると思うよ

symfonyのESC_RAW引数とかは使い勝手がよく出来てるなーと思った
遅そうだけどｷﾆｼﾅｲ

激しくカブったがｷﾆｼﾅｲ

</pre<

なんか魚っぽいなｗ

>>292
いや、だから互いに考えをぶつけあって
社内開発用フレームワークみたいのを
作ってるんならわかるんだって。
もしくは個人でやってるなら別に好きにやればいいと思うし。
実際このスレの住人てどんなプロジェクトでやってるのかふと疑問に思ったんだよ。

>>289
やっぱり一括エスケープするのはよくないよ。
単にエスケープし忘れを防ぎたいとか、

サニタイズ言うなって人にエスケープは直前にやれって怒られるぜ

どこでもデフォでエスケープがデフォだな

>>294
システムによりけりってアンタ、掲示板ひとつ作るにしても nl2br(htmlspecialchars($text)) は出てくるだろ。
SNSでのプロフィール表示とか。
>エスケープせずに表示したかったことはまったくといっていいほどなかった
と言い切れるって今までどんなシステム作ってきたんだよ。

>>295
すまんかった

ところでsymfonyもCIも、一括エスケープされるのは強制的なの？
こんな余計な機能はいらないからオフにして、かわりに好きなテンプレートエンジンが使えるようにしてほしい。
もしオフにできないなら、CI使おうとおもってたけどやめようかな。

もはや自動エスケープは常識だと思ってた
そういう意見があったことのほうが非常に意外で興味深い

>>300
オンラインショップのバックエンドとか旅券発行システムとかで
エスケープ必要なかったシステムはいくつも見てきているけど
だからって「全くといっていいほど」とはとても思えない程度にはあったなぁ

CI知らないけどSymfonyではエスケープの方式をいくつかから選択できるよ
何もしない、闇雲に全部やる、
普通の表示は全部やるけど必要なものは別オブジェクトからrawで取り出す、など。

失敗してたので再投稿。

>>290
やっぱり一括エスケープするのはよくないよ。
単にエスケープし忘れを防ぎたいとか、htmlspecialchars() が面倒というだけなら、ビューがデフォルトでエスケープするようになってればいいだけ。
素のPHPはそうなってないけど、そうなっているようなテンプレートエンジンを選べばいいだけの話。
一括エスケープは、目的のための手段のひとつに過ぎない。手段はほかにもあるし、一括エスケープが最適な方法とは思えない。

なんか最新のフレームワークでそうなっているからとか、えらい人がそう言ったからとか、そんなことで決めてないか？
>>290からはそんな匂いがプンプンする。
もし最新のフレームワークがSmarty使ってたら、または○○神がSmarty使ってたら、Smarty使うことが最高の方法ということになるのか？

でもSymfonyもCIも一括エスケープが基本なのか。CI使おうと思ってたけど萎えた。
こんな機能いらんから、テンプレートエンジンが自由に選べられるようにしてほしい。
オフにできるならCI使ってみる。

チームでやるには必須
どんなに注意してもかならず誰かやらかすよ
XSSの歴史がそれを証明してる

>>302
>CI知らないけどSymfonyではエスケープの方式をいくつかから選択できるよ
これいいね。Symfonyにしようかな。

FW自身の評判にかかわるから強制するって側面があるだろう。
トータルで見たらエラーの量を低減するのは明らかだからね。

一括エスケープするよりしない方が簡単なんだから
したくないならそりゃしないでもいいだろう
ってか>>303の決めつけにワロタ
思いこみの深さからいうと昨日のアニヲタ君かな？
君の方が権威に弱そうだったから権威っぽい名前を出しただけのことだよｗ

ビューでエスケープは勘弁してほしい
ベッキーがなんと言おうとこれだけは譲れない

アウトプット前提でデータ割り当ててるんだから同じだろ？
何が問題なのかさっぱり分からん。

>>293
詳しい処理見た訳じゃないが、
フレームワーク作者的に言えば
アサイン時にエスケープの有無は選べるように普通するだろ
そんなの考えたらすぐ分かるじゃん
少なくともテンプレートの層でエスケープするより
入り口でエスケープするアプローチの方がスマートだと俺は思うね。

エスケープの有無を選択するのにVを操作するよりは依存性が低いということかな？
データの加工をV前に済ます（Vは極力弄らない）という点からみるとそのほうが妥当かも。

（Vは極力弄らない）で思ったんだけど、
ビューのなかで繰り返しのコード（for等）をなくすアイデアない？

Amritaみたいのを自分で作る、とか。

煽り的に藤本氏の言葉を出したのは適切じゃなかったな
変に叩かせてしまった
面識はないけどすみません
要は、藤本氏の言葉は、ホワイトリスト方式の方がいいよという文脈だった
俺もそう思う

EthnaもSmartyも使ってないけど、
Ethna的にはnl2br()はSmartyのnl2br修飾子を使うんだと思う。

QFやらSmartyやらといえば、

ttp://blog.enjoitech.jp/detail.php?aid=128

ここで普通にQF2使ってるんだけど、
QF2の状況ってどんな感じなのかしら。
ちょっと前にみたらバージョンがえらく低かったんで、
まだまだ実用外だと思っていたんだが。

QFはアイディアは面白いと思うのよ。
色々と問題はあるけど。

>308
MVC的にはエスケープはViewがやるのが正しいんでないの？
ViewがHTMLとは限らないんだから、
どんなエスケープ処理が必要か知ってるのはViewだけであるべきでしょ。

php da rox!

>>242
$file = $tpl_dir. 'template.tpl';
if (!file_exists($file)) {
$contents = preg_replace(
array(
'/^<\?xml/',
'/#\{(.*?)\}/',
'/%\{(.*?)\}/'
),
array(
'<<?php ?>?xml',
'<?php echo $1; ?>',
'<?php echo htmlspecialchars($1); ?>'
),
file_get_contents($file)
);
file_put_contents($file, $contents);
}
include $file;
こんな感じか。変数がかぶるとかなら関数作って渡せばいいだけやね。
うちだと、symfonyのviewの部分に、こんな感じのを作って入れてる。
（といってもそのままじゃなくて、<input />等のタグを、ヘルパに変換して代入する処理も入れてる訳だけど。

インデント無くなってるのｽﾏｿ（汗）

だから一括してエスケープするのは問題があるってかいてるじゃん。
エスケープ漏れをなくしたいなら、view側がデフォルトでエスケープする仕様になってればいいだけ。
それで十分だし>>293のような問題も起きない。
それでも一括エスケープの方がいいという根拠は何？

>>317
そういうロジックをViewでやるからSmartyはうんこなんだよ

セキュリティや出力方法の変更は、VでやろうがCでやろうが同じでFA

>>322
別にViewでやったっていいだろ？
テンプレートコーディングがうんこだと言うのは認めるが。

アサイン時のオートエスケープがどうか？という提起なのであって、
それをやるオブジェクトがViewだろうとControllerだろうとWebアプリじゃ違いはないじゃん。

あと文句言ってる奴はちゃんとオートエスケープの実装と意図を見てから言えよ。
かなり的外れになっちゃってるぞ。

お前ら年中言い争ってるのな

>>325
だって、ばかばっかだし

知識に関しては知らんが、いちいち言い争ってるのは確かに馬鹿っぽい。

馬鹿ばっかじゃないよ。分かってる奴は書き込まないだけ

結局何がお勧めなの？

cake。

>>329
俺はCakePHP。
本もでたし。

Cakeは型に嵌ると強いね

CとVをパツパツに切れると思ってる奴は幻影を見ている

なあ、今CodeIgniter試してみたんだけど、一括してエスケープする機能ってあるか？
$_POSTと$_COOKIEのデータを自動的にエスケープする設定はあるみたいだが、まさかこれのことではないよな？
テンプレートを出力するときに勝手に一括エスケープされるのかと思ったけど、そうでもないみたいだし。
$data = array('var'=>'<b>FOO</b>');
$this->load->view('blogview');
とかしてみたんだけど、テンプレートでは $var はエスケープされてなかった。

モダンなフレームワークであるCodeIgniterでは一括してエスケープしてくれるから htmlspecialchars() は使う必要ないと>>273が語ってくれてるんだけど、見つからん。
もちろん>>273は知ってるはずだから、すまんがさくっと教えてくれ>>273

>>324
>あと文句言ってる奴はちゃんとオートエスケープの実装と意図を見てから言えよ。
>かなり的外れになっちゃってるぞ。
なにがどう的外れか書かないと、おまえこそ的外れだといわれるぞ。
オートエスケープ？の問題点が指摘されてるんだが、解決策は示されてない。
問題点が問題点でないというなら、解説希望。

>>334
記憶は定かではないが、今見てないならないのかもな
自分で拡張したciに実装しただけかもしれん
ciって筋はいいけど、ちょっと機能的には弱いだろ
まあいずれにしろテンプレートレベルでエスケープするのは
いい方策ではないと思うがな

>>335
いいから実物見てみろって。説明で判った気になったってしょうがないだろ

>>329
Zendでいいじゃん
ダイヤブロックみたいで組み立てるの楽しいよ

ダイヤブロックワロタｗ
レゴじゃないんだよな
なんかパーツがでかいっていうか

今作ってる俺俺FWでもZend方式でいきたいんだよね
コンポーネント間で依存性をほとんどなくしたい
ただ設定クラスとかContextを作ると、そこに依存性が生まれてしまう
何にも依存してないコンポーネント群を、
それらに依存するコアコンポーネントが動かす形にしようかとか考えてる

ダイヤブロック（笑）とかお前おっさんだろ

依存性ってそんな問題かな
どのくらいからDI系コンテナのメリット出てくるんですかね

疎結合の方が副作用も少なくなるし
ユニットテストも書きやすくなる
依存が多いとモックとか用意するの面倒だ
DIコンテナとかは要らないと思うけど

独立したコンポーネントにしておけば
フレームワークのフレームワークにすることが出来るから
フルスタックFWの「この機能だけ欲しい」ってなっても
それだけを切り離すことは難しいから
ごっそり捨てるはめになる

php4でも動くようにプロパティーをvarにしてたら
php5でstrictエラー出まくってうぜえええ

4で動かすならstrict切れよ……
4用の箇所を洗い出すための機能みたいなもんなんだからさー

あーそういうためのものだったのか・・・知らなかった
ありが�d

つーかさー、いろんなフレームワークに手を出してるﾔｼって何なの？？天才なの？俺には無理orz

ダイアブロックｗｗ

ZendってContextにいれるようなものをどうやっていれたり出したりするわけ？

MyZend in Zend Japanの認証まわりの手抜き感は異常
エラーメッセージはしょぼいし
パスワード忘れた時のナビゲーションもない

>>336
>まあいずれにしろテンプレートレベルでエスケープするのは
>いい方策ではないと思うがな
だから、それはなんで？理由が述べられてないじゃん。俺、エスパー力が少ないから336の考えが読み取れない。
モダンなフレームワークがそうしてるから？ナントカの神様がそうしてるから？

>>337
実物ってどれのこといってるの？
指摘された問題点に対する回答は？

>>352
あほすぎワロタ
君以外そんなレベルにいないよ
もっと勉強してから来いよ

その問題のブツを持って来いよ

変更や新規コードが多いのってUI周りじゃん。
その辺で楽できないZFは正直どんなもんかと思いますね。

まあ確かに現状ZFはあんまりだと思うけど、
フルスタックを志向しなかったコンセプトは好き

>>355
GoogleBaseとかサポートしてるよ？

UI周りの楽ってどういう機能？
いまいち想像できない

Google Baseとか3年ぶりに聞いたわ

>>353
おれ、あほだからわからん。
テンプレートでエスケープする方法と比べてなにが利点なの？
SymfonyもCIも、テンプレートが素のPHPだからデフォルトではエスケープされないのがそもそもの問題であって、
デフォルトでエスケープされれば、別に一括してやる必要なんかまったくないと思うけど。
賢い>>353、答えよろしく。

で結局、アサイン時に一括エスケープしてくれるモダンなフレームワークってどれ？
CIはそうではなく>>273のねつ造であることがわかったけど、ほかに何があるの？
>>273
>モダンなFWはだいたいそう
と書いてるから、ほかにもいろいろあるんだよね？
まさかsymfonyだけとかいうオチじゃないと思いたい。

もしかして>>273は未来人？将来的にはCIも一括エスケープするようになるのを知ってて書いてるとか。
そりゃ過去から書いてるように見えるわな。

ZFとかCIとかCakeとかSymfonyとかクソみたいなFWについての議論しても意味無いと思います。
まさかこいつらを実用してる人とか居るの……？

>>362のオススメは？

>>361
私はCI使うときも生PHPでビューを書いてるからよく知らないけど、CIにもテンプレートエンジン？みたいなのが
あったと思う。
あれを使うと自動でエスケープされるのかもしれない。

いい加減知ったかで煽ってるだけで回答もらえると思ってるアホは邪魔だよ
氏ね

知ったかというか、妄想で盛り上がってるだけじゃん
レス見ればFWなんかどーでもいいと思ってるのがよくわかるｗ

まともな議論はスルー、WebアプリにおけるMVCの役割分担は思考から排除、
自分が出した疑問点なのに実装は確認せず「お前がもってこいや」発言、
テンプレートロジック推奨、極度の煽り文体・・・。

もう荒らしたいだけちゃうんかと。

PHPerって流行るとみんなそれ作るよね？
しょっぱいフレームワーク量産してるのが滑稽で仕方ないよｗｗｗ

>>366
ちんこ弄ってないで何が妄想か言ってみたまえよ糞ﾆｰﾄ君

このスレのスキル予想

パンチカード式プログラミング
↓
マシン語
↓
アセンブラ
↓
構造化プログラミング　←今ココ
↓
オブジェクト指向プログラミング

フレームワークを使いこなしている人は少数と見た！

>>367
>まともな議論はスルー、
スルーしてるのは一括エスケープ推進派だよね。ちゃんと>>360の質問に答えてよ。

>WebアプリにおけるMVCの役割分担は思考から排除、
VですべきことをCでしてるのはそっちでしょ。
権威に弱いみたいだから紹介しとくね。
http://www.ipa.go.jp/security/awareness/vendor/programming/a01_02_main.html
>サニタイジングは(2)HTML生成時のタイミングで行うべきである。

>自分が出した疑問点なのに実装は確認せず「お前がもってこいや」発言、
確認したよ？CI使ってみたら、そんなのなかった。つまりそっちのデマカセであることを確認しました。
だから「一括エスケープしてくれるモダンなFWってどれ？」と聞いているんだけど。>>273みるとなんかたくさんあるみたいじゃん？
うそっぱち紹介しといてこれはないよな。

>テンプレートロジック推奨、
テンプレートロジックってどのことを言ってる？HTMLエスケープすること？まさかそれをロジックといってるのかな。
symfonyでもCIでも、テンプレート中にifやforeachをバリバリ埋め込んでるけど、それは見ないふり？

>極度の煽り文体・・・。
>>353のことかぁぁ！

>もう荒らしたいだけちゃうんかと。
答えられないなら黙っとけば？負け惜しみミットモネー

まだあほがいるのか・・・
単なる面倒くさい奴になってることに気づけよ
ヒントはいっぱい転がってるのにも関わらず理解できない奴に
これ以上丁寧に説明してやる義理はねーんだよ
というより説明しなくても分かるだろ、フツー
既に説明することすらアホらしいレベルの話なんだよ
一言で言うとお前にはプログラマとしてのセンスが決定的に欠けているんだよ

メモリ(変数)上に持つデータは、本来のデータ(未エスケープなもの)で、
出力するときに、出力する媒体(HTMLとかSQLとか)によって適切な
エスケープするのが基本だろ。
これに異論言う奴はいないだろ？

で、実際問題、CからVに渡すとき、出力媒体はHTMLなわけだから
一括エスケープでもいいじゃん。って発想でもいいわけだし、
Vレベルでデフォルトが、エスケープ有りでもいいわけだろ？

俺にとっては微妙な差異なんだが、そこにそんなにこだわる
必要があるのか疑問だな。

アニヲタってのはあれだな。
現実をかたくなに拒絶し、
甘く非現実的な幻想のみを受け入れ、
自分が考えたいように考え、
自分が信じたいことだけを信じる、
という思考パターンを強化学習しているようなものだから、
その嗜好がプログラマとしての資質を破壊していくようにできてるんだな。

VとCが同時に動くWebアプリじゃ差異がないって話はずいぶん前に既出のようだが

いちいち読んでられるかバカタレ。

>>373
だからそういってるんだけど。
テンプレート側がデフォルトでエスケープするようになっていれば、べつに何の問題もない。
しかし未来人は一括エスケープするほうがいい方法だと思っているらしい。
引用：
>>310
>少なくともテンプレートの層でエスケープするより
>入り口でエスケープするアプローチの方がスマートだと俺は思うね。
>>336
>まあいずれにしろテンプレートレベルでエスケープするのは
>いい方策ではないと思うがな

その根拠を聞いているのに答えられていなくて、わめいてばっか。

>>372
>ヒントはいっぱい転がってるのにも関わらず理解できない奴に
>これ以上丁寧に説明してやる義理はねーんだよ
どこにヒントが？説明できないだけなのを認めることができないだけだろ？
おまえがちゃんと説明すればいいだけの話。本当にわかってるんなら、そんなに説明が難しいことでもないだろ？

で、件の実装がなされてるFWはまだですか？

常識的な事項だし、お前も本気で説明できないと踏んでるわけではあるまい
回りくどいことをせずに言いたいことを言えばいい

>>377
だからホワイトリスト。以上。

どのフレームワークのどの実装が気に入らないのかしら？
実現できないことがあるからアドバイスが欲しいの？
代替手段が欲しいと作者にメールしたいの？

たぶん、自分の頭が悪いのが気にいらないんだろう。
でもそんなのどうしろっていうんだ。
「知らんがな」としか言いようがない。

>>370
記録メディアとしてのパンチカードはかろうじて見たことあるけどなあ
その世代で現役の人いるんだろうか
人ってか仙人だな

>>377
は、PHPフレームワークを超えて
未来人との戦いに必死ってことがわかった。

>>361
今どうなってるか知らないがいずれciもそうなると思う
symfonyもescaping outputは後から付いたんだよ

ﾃﾝﾌﾟﾚｰﾄやFWを使うと人格が攻撃的になるんですね
非ﾃﾝﾌﾟﾚ非FWこそ賢者ということが良く分かりました

もともとテンプレートなPHPでテンプレートエンジンてｗｗｗｗ

数ある言語の中でただ一つテンプレートエンジンを作る必要がない言語があるとしたら
それがPHPだろ
Smartyとかエスケープするだけの自作テンプレートエンジン（爆笑）とか
はやくゴミ箱に捨てろよｗｗｗ

>>388
なぜお前は強制するの？
ひとりで捨てとけよｗｗｗ

PHPでテンプレートエンジンてｗｗｗ
パンを挽いて粉に戻して・・・またパン作ってますけどｗｗｗ
しかもどえらく不味いし
お前ら元々まずいパンをもっとまずくする天才だなｗ

>>388-389
これ思い出した

J-CASTニュース : 「オレも裸、オマエも裸になれ」 セクハラ調教師HP大炎上

ttp://www.j-cast.com/2007/10/22012451.html

>>389
捨てるも何も最初から持ってねーよ
そんなの拾わねーよｗ

>>391
むしろ「え？なに一人で裸になってんの？」
あるいは「ちょｗｗ王様が裸ｗｗｗ」
ま、王様というより乞食だけどなm9（＾Д＾）ﾌﾟｷﾞｬｰ

>>374
アニヲタの質問に答えられない374はアニヲタ以下ー
ゴキブリ呼ばわりした相手に負けた亀とおなじー

>>392
もってねえのなら、最初からだまってろw

>>380
答えになってねーよ！
それが理由になるって、間違いなく勘違いー！

コントローラで一括エスケープした場合:

<?php echo $foo; ?> // エスケープされる
<?php echo $sf_data->getRow($bar); ?> // されない

デフォルトでエスケープするテンプレートの場合:

{% $foo %} // エスケープされる
{%% $bar %%} // されない

どこが違うのー？なんで一括エスケープのほうが優れているかの理由になってないー！
これで答えたつもりになってる>>380はアニヲタ以下ーｗｗｗｗ
うまく答えられないから、詳しい説明は必死で避けてるーｗｗｗｗ

肝心なレスはスルーで煽りだけ
まあﾆｰﾄの趣味グラマってレベルだな

まだ弄るのかよｗ

>>385
>今どうなってるか知らないがいずれciもそうなると思う
未来人の大予言ｷﾀｰ!
さすがえらそうにみんなを過去の人扱いしただけのことはあるー!
しかも今どうなってるかしらないくせにCIを「一括エスケープするモダンなフレームワーク」とねつ造してたー ｗｗｗｗ
でも>>385がいる未来ではきっと違うーｗｗｗ それは何年後の未来なのー？

で結局、一括エスケープしてくれるモダンなFWはsymfonyと他になにがあるのー？
>>273
>モダンなFWはだいたいそう
と言い切ってるからほかにもあるんでしょ、はやく教えて>>385ｗｗｗ
なんならPHP以外でもいいよー　モダンならねーｗｗｗ

ホワイトリストが優れている理由ﾏﾀﾞｰ?>>380
デフォルトでエスケープするテンプレートとの違いﾏﾀﾞｰ?>>380

いきなり煽りの質が低下したｗ

一括エスケープは、動作だけをみると
デフォルトでエスケープするテンプレートエンジンとほとんど同じだよ、もちろん。
っていうか、
エスケープするテンプレートエンジンのオルタナティブとして、
モダンなFWは一括エスケープをしているぞって言ったんじゃん。
だから同じなのは当然なんだよ。ナイスアシストｗ

そういう話者の人格を固定した会話がしたければ
捨てトリつけるとかしてくれよ

最初から質は変わってないと見るがね
自分のｼｭﾁｮｰとレスで指摘されてることが噛み合ってないことも分かってないんだろ
その阿呆っぷりを利用していつまでもギャップを保って弄り続けてる奴もどうかと思うが

>>396
どうでもいいけどgetRawな
Rowだと行取っちゃうから

>>404
なんか邪気眼くさいｗｗｗ
どっち派にも届かない声乙

どっち派ねえ
現実には論点の読めてない阿呆が一人いるというだけのことだが

どう見てもどっちも複数だろ・・・
その思いこみの激しさ・・・
お前アニヲタか？

池沼のふりしてログ流しとか自意識過剰なんだよな。
他人の醜態なんか興味ないって。

バカの煽りはさておき、早く答を言ってよ。
俺にはどうぜ最初から全然分からない議論なんだから、考えるだけ時間の無駄。

アニヲタはひたすらLive Searchで初音ミクを検索しとけよｗ

dbの文字コードと内部文字コードが違う場合に
対応できるフレームワークってありますか？
格納時には、内部→dbコードに変換
取り出し時には、db→内部コードに変換
こういう感じの動作するような…

>>409
ログ流しワロタｗ
アニヲタワードのひとつだな

itojunが亡くなったのに
追悼コメントのひとつもないペチパーなんて・・・

PHPなんてつかってるやつはばかです

そのばかしか使わない言語のスレに来て独り言書き込んでる奴は何なの？

>>414
なんの関係があるの？

javascriptのロジックってV?C?

>>412
以前Symfony使ってた時に、どこかでFilterで対応してたのを
参考にしたよ。
PostgreSQLだとSET client_encoding = で、MySQLだとSET NAMESだっけ？
でも大垣さんがSET NAMES使ってんじゃねーよバーローって言ってたけど、
あの人いつも答え言わないからなんでか理由がわかんない。

>>273
>最近のFWは<?php echo htmlspecialchars() ;?>なんてしないよ
>アサイン時に一括エスケープするから
>symfony,ci,モダンなFWはだいたいそう
>smarty派も非smarty派もテンプレートエンジンに拘ってる時点で旧式
>もしかして過去から書き込んでるのか？
未来からやってきた>>273 テンプレートエンジンなんて過去のもの、モダンなFWは一括エスケープはだぜーとかっこつけー
ねつ造バレても釈明なしー

>>310
>少なくともテンプレートの層でエスケープするより
>入り口でエスケープするアプローチの方がスマートだと俺は思うね。
テンプレートでのエスケープを否定ー　スマートである説明いっさい無しー

>>336
>まあいずれにしろテンプレートレベルでエスケープするのは
>いい方策ではないと思うがな
またまたテンプレートでのエスケープを真っ向から否定ー　やっぱり理由の説明なしー

>>372
>ヒントはいっぱい転がってるのにも関わらず理解できない奴に
>これ以上丁寧に説明してやる義理はねーんだよ
自分で説明できないのを必死にごまかすー　義理がないんじゃなくて頭がたりないんだろーｗｗｗｗ

>>380
>だからホワイトリスト。以上。
必死で考えた言い訳がこれー　でもマッタク理由になってないー　

>>402
>一括エスケープは、動作だけをみると
>デフォルトでエスケープするテンプレートエンジンとほとんど同じだよ、もちろん。
態度を180度変換ｷﾀｺﾚ!　もう言い訳を考える頭もなくなったーｗｗ

>っていうか、
>エスケープするテンプレートエンジンのオルタナティブとして、
>モダンなFWは一括エスケープをしているぞって言ったんじゃん。
そんなことひとこともいってないー　テンプレートでエスケープするのはバカ扱いしてたのはなかったことになってるー
今までの自分の発言をわすれてしまったー　老ボケか？老ボケなのか？
いや自分に都合の悪いことだけ忘れてる自己都合ボケーｗｗｗｗ

>だから同じなのは当然なんだよ。ナイスアシストｗ
なにが当然なのー　一括エスケープするのがモダンですごいやり方なんでしょー
今までの主張とチガウヨー　立場まずくなったからって変わり身するなー
いままでの『一括エスケープがサイコー、テンプレートつかってるヤツなんてまだいたの』発言はどうするつもりーｗｗｗｗ
おまえが意見かえることなんて誰ものぞんじゃいねーよｗｗｗｗ
はやくホワイトリストの利点説明しろー!
モダンなFWの名前をだせー!

>>419
ttp://blog.ohgaki.net/index.php/yohgaki/2007/08/22/set_namesa_mcb_asc
コメントにも書かれてるけど
「そうは言うけどそんな非現実的な」って話だよなぁ

あほっぽいレスでｇｄｇｄにしとけば自分の敗北も認めずに済むと思っているのだろう
自分の主張が通らないと現実を捻じ曲げて荒らしに転じるのはよく見る光景だが

最初から甘ったるいレスが多かったがあまりに「幼稚」だな
学生ニートのようだが対人関係に大いに問題あり
人生勘違いしてるようだから、ここらで考え直すことを勧めるね

とさらに惨めなレスを引き出してみるてすとｗ

あれはMysql4を投げ捨てろって話じゃないのか
新しいほうは指定した文字コードにあわせてMysqlのライブラリがてけとーに汚染変数洗ってくれるんだよね？

なんで調べればすぐ分かる事をここで聞くのか

誰が誰を煽ってるのか分からんから、アンカーつけろよｗ

昼前にSymfonyでシステム一つあがったよー(^ｏ^)/~~
初めてのPHPフロントエンドだったけど意外に時間かからなかった！
スケールできるように弄るのに手間取ったものの、ほぼそのまんま東に稼動。
しかしサポ用のドキュメントが死ぬほど肥大しているのは何故・・・？

限定された状況での脆弱性を一般化して語るのはよろしくないな。

>>424
されないよ

>>426
「誰が」は分かるだろ？ゆとりちゃん＾＾

>>429　なるほど　把握した

>>419
http://cakephp.seesaa.net/article/52562968.html

WEB系の雑誌とかブログで安易にハックとかハッカーとか書いてあるの見ると違和感を感じる。いとじゅんはリアルハッカーだったな。

アニヲタって本当に幸せな人種ですね^^

ところで、なんで「アニヲタ」というキーワードがわいて出てきたんだ？

きもいからじゃね？

ああ、このスレでフレームワークとかテンプレートエンジンが
いるだの、いらないだの論争しているやつらがキモいってことかー

db問題は「何がダメ」って言われるだけで
「何故ダメ」なのかがいまいち分かりにくいな
エライ人たちの間ですら説が錯綜してるのがにんともかんとも
ケーススタディー的に解説してくれたらいいのに

sqlインジェクションの件でブログ書いてる人も
「〜らしい」って言い回しがやたら多いし。伝説なのかと。
メカニズム自体はシンプルなんじゃないの？
なぜ誰もちゃんと説明してないの？

どこのblog？

晒すのはちょっと・・・

itojunのスレ見てもどうすごいのかサッパリわからねえ・・・
IPv6で功績のあった人だということは分かったが

>>427
symfonyでスケールってdbまわりとかどうやったん？

>>434
>アニヲタって本当に幸せな人種ですね^^
そのアニヲタにすらけちょんけちょんにされてるんだけどね
まともな反論できないからこんなことでしか言い返せない
最後につけた「^^」にどうにかプライドを守ろうという必死さが見える

アニヲタアニヲタ繰り返す前にやることあるだろ
ホワイトリストの利点ﾏﾀﾞｰ?
モダンFWの名前ﾏﾀﾞｰ?

>>444
このスレを見ている人はこんなスレも見ています。(ver 0.20)
フケ・痒みがとまらないPart9 [身体・健康]

これはあなた？

http://blog.ohgaki.net/index.php/yohgaki/2007/08/22/set_namesa_mcb_asc

> 脆弱性の説明は面倒ですが注意事項は簡単です。「DBMSをアプリケーションから
> 利用する場合、文字エンコーディング設定は必ずAPIを利用する」つまり
> 「SET NAMES（SET CLIENT_ENCODING等も)は禁止」です。

”注意事項は簡単です。”
これなぁ。なんていうか、むかつくというか、あきれるというか
この人、まだまだだなぁというか、

俺の「（コーディング）規約を書くときの規約」に反しているんだよな。

・禁止するときは必ず理由を書く

という規約に。

>>446
俺俺規約ｯｽｶｗｗｗ
でも基本的には同意
ていうか、ちゃんと教えてよーって感じ

Mysqlのエスケープ実装までまだ見てないんじゃないの？
というかコレ未だに放置されてるってけっこうショックだわ

大垣たんは著書を読む限り
ソリッドな技術者って感じで嫌いではない

SJISみたいなクソコード使わなきゃいいだけの話じゃないのか。

>>449
たいした脆弱性じゃないのに大慌てして告知して
あとから修正するというドジっ子属性ももってるしな

>>450
これからの案件にはそれでいいね

>>445
おれがみてるのはそっちじゃなくてこっち。
ホワイトリストの利点教えてくださいPart3 [WebProg]
【ｱﾆｦﾀにすら】今日あった悔しいことPart123【負けた】[ネタ・雑談]

ﾜﾛﾀ

糞コードはSJISしかないの？

日本語以外ならある
UTF-8、EUC-JP はOK

フレームワークの使い方を勉強したい。

最初から否定されると勉強する気が失せる。

ここからフレームワーク最高路線でお願いします！！！

↓↓↓

( ´−｀).｡oO（php4ってメソッドチェーンできないのが糞だな・・・)

symfonyは未来からやってきたモダンでホワイトリストなフレームワークです
一括エスケープってマジ最高

( ´−｀).｡oO（こりゃ誰からもウザがられるわ・・・)

http://ja.wikipedia.org/wiki/%E3%83%9B%E3%83%AF%E3%82%A4%E3%83%88%E3%83%AA%E3%82%B9%E3%83%88
ホワイトリストとは、警戒する必要のない対象の一覧表のこと。対義語はブラックリスト。

青少年にインターネットを扱わせる場合、青少年に見せても安全なページだけを登録しておき、それ以外のページにはアクセスできないようにすると安全である。

このとき、青少年に見せても安全なページのリストアップが「ホワイトリスト」にあたり、青少年に見せても安全なページ(ホワイトリスト)にしかアクセスできないようにする方法は「ホワイトリスト方式」と呼ばれる。

勉強になります

phpフレームワークと
どんなjavascriptフレームワークを連携させてますか？

SymfonyとExt合わせたけど、Ext使うんだったらフレームワークは
何選んでもあんま関係ないかも・・・。
確かに見た目はかなりいいけどね。でもちょっと重い。カレンダー一つ表示するにも。
Javascriptの記述量が半端無く増えるし、
見通しがすっごく悪くなるように感じたので、あんまりお勧めしないかな。

>>463
symfony + prototype

PHPじゃないけどpylons + prototype

設計、ソースが綺麗なフレームワークってありますか？

> 458 名前：nobodyさん[sage] 投稿日：2007/11/02(金) 22:20:25 ID:???
> ( ´−｀).｡oO（php4ってメソッドチェーンできないのが糞だな・・・)

また新しい用語を覚えたのかい？ｗ
恥書く前に消えたほうがいいよ。

まぁあれだ。Ruby on Rails 使えってことだ。

>>466
CodeIgniter
機能は若干不足気味だが、設計センスがいいのでなんとでもなる

>>467

おい下スレ荒らされてるぞ
こっちでちゃんと面倒見といてくれよ

>>471
お前もばかｗ

狂犬になったアニヲタが野に放たれた…
思いこみパワーで誰にでも噛みつく！

このスレには、すぐにアニヲタとか言い出すアフォがいるよな
同一人物なんだろうな

なんか可哀相になってくる。

>>474
【同一人物】と思っちゃうところがまさに【アニヲタ】なんですけどね（ ´,_ゝ｀）ﾌﾟｯ

>>476
アフォが食いついてきましたｗｗｗ

〜アニヲタの思いこみパワーでできること〜

・工作員が存在すると思いこむ（なぜか交代制）
・だいたい電通のせい
・最近じゃGoogleも悪の組織
・スレ流しをしていると思いこむ
・意味不明の勝利宣言
・しつこさだけが本当の武器

頑張れ、思いこみ戦士！
吠えろ、思いこみ戦士！
思いこみパワーで、お前の心の平安を守るのだ！

PHPフレームワークを語るはずのスレで
なぜか出てくるアニヲタ叩きw

よっぽど嫌な過去でもあるのかね？

>>479
ｱﾆｦﾀはどこでも叩かれるのがﾃﾞﾌｫだぜ？

>>480
いい加減うざいから、ニュー速行けって感じだけどな

ちーたんの作者が若干アニ○タくさい件

しょうがないよ、見下してたはずのアニヲタに完敗したんだから。
ゴキブリと見下してた相手に完敗した亀とおんなじ。あまりのショックで人前にでられなくなった。
>>445で必死にやり返したつもりが>>453だもんな。意固地にもなるさ。
そっとしておいてあげてください。弱ったものへ労りの言葉を。

>>444=483=叩かれてるアニヲタ

こんなバレバレの自演して馬鹿じゃないの？

>>483
・意味不明の勝利宣言

>>484
ホワイト君かな？アニヲタを必死に叩いてもなんも変わらんよ。
きみがすべきことは・・・分かるだろ？話をそらさずに議論で戦えよ。
まずはホワイトリストの利点を説明しろ、話はそれからだ。

>>486
それは罠よ
議論でアニヲタを説得することなんてキケロも釈迦も出来ないわ
常に歪んだフィルターを通るからどんな言葉も必ず歪むの
気を付けて！
アニヲタと議論しようとしたら、あなたはその時点で泥沼に足を踏み入れているの
ただ観察するだけにしておきなさい
彼らの愚かさは底なしなのよ・・・

もうセックスの話しようぜ！
セックス！

俺は手コキされながら乳首なめられるのが大好き

お前らPHPプログラマー（女）とセックスしたことある？
PHPプログラマーって何か萌えないよな・・・
一番萌えるのは・・・JavaScriptプログラマーかな？

一番萌えるのはやっぱデザイナーでしょ！決まり！
しかも<td>{$hoge}</td>なんて書いて頂けたらもうｻｲｺｰ!

デザはなんかベタだな…
女なのにプログラマーなのが萌える

スクリプタキュラスって発音がきめぇ

このスレを見ている人はこんなスレも見ています。(ver 0.20)
フケ・痒みがとまらないPart9 [身体・健康]
【トイプードル】プードル Part26【ﾐﾆﾌﾟｰｽﾀﾝﾌﾟｰ】 [犬猫大好き]

…増えた

やっぱり特定の何かに長けてる女がいいな〜
運動得意とかピアノ弾けるとか・・もちろんプログラマでもおｋ

http://lovecall.14.dtiblog.com/
なんかこんなのあった
ギークなお姉さんは好きですかだと
こんな狙いすぎなビッチは萌えない

99％のてけとうさと1％のまじめさでできた100％B型のおにゃのこです。だぁ？

こんな女は毎回顔射でOK

俺俺FW作ってる人
基幹はクラス、関数はヘルパにするのがセオリーだと思うけど
ヘルパ以外の関数も書く？

美少女プログラマーって居るの？
http://pc11.2ch.net/test/read.cgi/prog/1162409953/

>>499
>みんなの周りにはいないんだな。
>どこを探してもいないと。

不老不死の薬かよｗ

agavi 0.11がでたぞー

あが・・び・・？

　　　　　　　　　__,,／　　_, ----｀ヽ　　：.
　　　　　：. 　／　_　　　　　___　　　､＼
　　　　　　 / ／　　　i　　　 　 ＼ 　 ＼＼　：.
　　 　 ：.　,'./ 　 　 　 i　　ヽ:.　 　ヽ:.:..　ヽ.ヽ
　　　　　 ,'/　　　 / .ハ ヽ　ヽ:.:.:.:.　ヽ::..　ヽヽ　：.
　 　 　：. |i .i　i　 .i /　 ヽ ﾄ ､ ＼､:.:.:. ',:.',:.:.lヽ}
　 　 　 　|i .i　l 　:Ｎ＿, -弋　＼弌弋ナ:}:.:}
　　　　：. |i∧ ',　:{　,ｨjモﾄ　＼　 ｲjミﾄｲｲＶ　：.　　あ…
　　 　 　 .|　 :ﾒヽ.', `ozＺ} 　 　　 izN｡ﾊ::{　　　　　あがびってなんなんですか？
　 　 　 ：. |　 :ヾ_! ゝ　"ﾞﾞ　　　 ' 　｀ﾞ ハ.:',　：.　　　
　　　　　　|　 :.:_ｲ .:.ヽ. 　　(二ﾌ　, ｲ :.:.:!:.ヽ　　　　　なんであたし
　　　：.　 / rｨｲ |　:.:.ヽ: ＞r／｀＜ノ .:.::.}ヽ､＼：.　　　貼られたんですか？
　　　 　 / ∧l;l　!　:.:.:.:/／{二￣ .} ..:..::ﾘ//ハ.:＼
　：.　 ／　.{. ',ヾ､ヽi .:.:.{ ／(^｀　　|.:.:.:./／: : :.}: . ヽ.：.
　　 /　/　 ） ヽ ヾ､ヽ:.ﾊ　ﾔ{　　 ∧／.-‐'": : |:.:.　i ',
　 ./ .,ｲ　.:..}　: :＼ヾレ'ﾊ　∧__ノﾉﾊヾ､　 : : : l:.:.: .ﾊ ',
　 { /｜ .:.:ﾊ　: : :i Ｙ {ヾ｀Ｙヽﾆン'ノ}: : } : : : :/:.:.:/　}:.}
　 Ｖ　| .:.:/:.:|_,ｨ'￣　 ヽ三{　｀ー-ノ : ｲ : : :/:.:i.:{　　リ
　　　 ヽ:.:{､.:.Ｖ　　　　 : : ﾍ　　　　 : : {: : :/:.::∧|
　　　　 ヽ! ）人　　　　: : :人　 　 　 : : : / ＼!　：.
　　　　　　"　 ヽ　: : : : :/イ{　　　　　:.ノ: : : :.＼　：.
　　　　　　　：.　 ＼__／//: :＼______／: : : : : : : ヽ
　　　　　　　　　　　/　//: : :|;|: : : : : : i: : : __: : : : ',
　　　　 　 ：. 　 　 / ､ {;{　　 |;|　　　. : i／. : : : : : :|
　　　　　　　 　 ／　｀Ｙ;{. . . .|;|. : : : ／i: : : : : : : : :l

>>503
不覚にもｗ

み…みくるﾀﾝ　(´Д｀；)ﾊｱﾊｱ

http://www.agavi.org/
Agavi 0.11.0 is now available
http://agavi.jp/
agavi.jp die...

struts → mojavi → agavi → symfony → …（未来へ）

伝統を今日に伝えるフレームワークの系譜ですね＾＾

http://d.hatena.ne.jp/keyword/Agavi
Mojaviから分岐して開発が開始されたPHPのMVCフレームワーク

2005年当時、Mojavi3の開発が滞っていたことから分岐し開発が開始された。
しかし、開発開始直後に分岐元であるMojaviとの再統合が決定し、早期に0.10.0をリリースし開発を終了すると発表された。

ところが、開発チームやコミュニティ内で「取り組むべき問題が残されている」との声が上がり、アーキテクチャの見直しが行われ、Mojaviとは異なるフレームワークとして開発が進められている。

特徴としてSymfonyやRuby on Railsに見られるようなORM層への依存の断ち切りや、テンプレートエンジンによらないHTMLフォーム処理ヘルパの提供を謳っている他、i18n機能も搭載している。

正式バージョンである1.0は完全なドキュメントと共にリリースされる予定である。

＜質問＞
・DIコンテナの仕組みになっているフレームワークって、設計が古くさいんですか？
・DIコンテナは、Maple以外にも何かありますか？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060628/241982/
DIコンテナは，「DI（Dependency Injection：依存性の注入）」と呼ぶデザインパターンに基づいて作られたコンポーネント群を集中管理するためのソフトウエアです。

S2Container.PHP5を用いたDIベースの開発
http://codezine.jp/a/article.aspx?aid=495
S2Container.PHP5は元々Javaで開発されていたS2ContainerをPHP5に移植したもので、DIとAOPをサポートする軽量コンテナです。

OOPもよく使いこなせていないのに、この上AOPを勉強するのか？
…道のりは遠い？＞＜

軽量Java DIコンテナ「google-guice 1.0」リリース
http://gihyo.jp/dev/clip/01/orangenews/vol38/0002
Google CodeにてJava 5ベースのDIコンテナ「Guice」バージョン1.0が，2007年3月8日に公開されました。
今までDIコンテナにはSpring FrameworkやSeasar2などがありましたが，開発者がGoogle社員であることや，アノテーションベースで設定ファイルがいらないこと，Spring Frameworkの100倍速いことなどが注目され，ブログを中心に盛り上がっています。

でもム板のguiceスレは閑古鳥が鳴いてるんだなぁ。

http://www.geocities.jp/toyprog/
ここのagavi情報ってもう更新されないの？

設定ファイルが要らないってとこに興味があるんだけど、どうやってんのかな。

全部アノテーションってことはないだろうから、多分リフレクションAPI使って生成するんだろう

PHP4でも使えるORマッパてありますか？
PEAR以外で

ここはアニヲタスレですか？

>>515
CakePHP、CodeIgniterなどのフレームワークに入ってる

>>517
o/rマッパだけ欲しいんですよねー

>>515
PHP4でつかえるActiveRecordライクなO/Rマッバー
http://kunit.jp/maple/wiki/index.php?%B3%C8%C4%A5%2FDb%2FActiveGateway
使ったことないからよく知らん

>>515
ADOdb Active Record
http://www.souken.co.jp/tech/php/adodb/docs-active-record_ja.htm

phpersistence - object persistence for php
http://www.phpersistence.org/


「PHP4 ActiveRecord」とか「PHP4 O/R」とかで検索すればいろいろ出てくると思う。

>>519-520
よさげですね
ありがとうございます！

>>520
フィールド名をキャメル・スタイル (camel-caps style) に変換することはありません。Zend 社の実装はフィールド名を 'first_name' から 'firstName' に変換します。

Zendそんな余計なことすんのか

>>521
せっかくだから、この機会にPHP5への移行を検討してみてはどうか。
PHP4のサボートが終了するのも遠くないし、PHP5の移行自体もそんなに難しくない。
しかもPHP5にすればO/Rマッバーの選択肢はだいぶ広がる。
http://31tools.com/cbl_activerecord/README.ja.utf8.html
とか。
O/Rマッバーを使ったコードに書き換えるなら、ついでにPHP5対応に書き換えるのも悪くないと思う。
余計なお世話だったらすまん。

>>522
初期のバージョンはそうだった
今のバージョンは変換することはない

>>524
なぜ濁点？
サボート
マッバー

かな入力か

orz
>>523宛でした

　 ＼(^o^)／　　　　　　　　　　　　 ＼(^o^)／ symfonyオワテル
　　　 )　 )　　　　　　　　　　　　　　 ノ　ノ
((((　 >￣ > ))))　＼(^o^)／　(((　<￣<　))))
　　　　　　　　　 　 　 )　　)
　　　　　　　　　(((　　>￣ > )))) 　　　code igniterハジマテル

PHPってJavaScript以下ですよね^^

javascriptもロクに書けないのになｗ

JSと比べる時点で間違ってる。馬鹿丸出しｗｗ
しかも批判してる奴に限ってそれ以上の言語を作る知識も技量もない。
マジで哀れだな。

PHPer自己弁護ｗｗｗｗ
ﾃﾗｱﾜﾚｗｗｗｗ

はいはい、じゃあ君が素晴らしいと思う言語を挙げてみてくれない？＾＾
理由も付けてね。むつかしい言葉での説明が出来なければ、君なりの言葉で構わないよ＾＾

え…PHPerって他できないから仕方なくPHPやってるんじゃないんですかｗｗｗ
PHPerがPHPに惚れ込んでる理由って何なのｗｗｗｗ
逆に問いたいｗｗｗ
問い詰めたいｗｗｗｗ

ヒント

ほとんどのオープンソースのウェブシステムは
なぜPHPで作られているか。

>>534
普通に便利で手軽だから。
534は何の言語をどういう理由で使ってるのか教えてｗ

>>534はjavascripterなんじゃね？ｗ

javascriptはすばらしいOO言語ですよ
PHPみたいに後から無理矢理OOを貼り付けたゾンビ言語とは違います

プロトタイプベースのオブジェクト指向言語ってそのままだと可読性に問題があると思うんだけど、好みや慣れの問題なのかねぇ。

メジャーな言語だとjsぐらいしかないけど、
js(の実行環境)が普及したせいでプロトタイプベースの考え方も覚える必要があって面倒。

言語の話はスレ違いですよ。

>>538
いくらすばらしくても、サーバーで動かない以上、
（あーなんかマイナーなソフトで動かせるやつあったっけ？）
実質サーバーで動かない以上、JavaScriptは使えない。

>>539
安心しろ。prototype.jsなどメジャーなJavaScriptライブラリでは、
プロトタイプベースなJavaScriptをクラスベースであるかのような
記法が採用されている。

>>541
prototype.jsも一種のフレームワークだとすれば、
一応スレ違いにはならないか。
フレームワークと言えるほど縛るわけではないけど。

サーバサイドjsはIISで使えた気がする。

ただね、prototype.jsの存在自体が、
プロトタイプベースを採用したjsの欠点を表してるんじゃないかと。あとは言語的に面白い仕組みは色々あるけど、企業での開発言語として見るとどうにも。

サーバサイドjsがapacheで手軽に動くようになっても、盛り上がらないだろうねぇ。LISP CGIの次の次ぐらいに。

> プロトタイプベースを採用したjsの欠点を表してるんじゃないかと。

俺も同じことが言いたかったんだがｗ

今のO/Rマッパってサブクエリにも対応してるの？
結合くらいまで？

> API(アプリケーションプログラミングインタフェース)のFileMaker API for PHPが、
> Server 9製品にビルトインされたことで、PHPのプログラミングを知らなくとも、
> ステップごとに質問に答えることで、誰でも手軽にPHPベースのWebページを
> 作成していただけるようになったわけです。

http://journal.mycom.co.jp/articles/2007/11/08/file01/index.html

質問に答えりゃ生成できる程度のページをわざわざPHPで動かしたがる業務要求なんて
実際ほとんど存在しないって事、いつになったら常識になるんだろう

よくある「〜〜フレームワークでブログサイトを15分で」とかでも同じ事がいえるけどさ

PHPウザってscaffoldingを目の敵にするよね

そんなことないけど

え…PHPerって他できないから仕方なくPHPやってるんじゃないんですかｗｗｗ
PHPerがPHPに惚れ込んでる理由って何なのｗｗｗｗ
逆に問いたいｗｗｗ
問い詰めたいｗｗｗｗ

もっといじめてー


















とかいえば満足？

YOU、フレームワークって何時も喧嘩の種になるからワクワクしちゃうYO!

PHPはさっさと安定したバージョンを決めて欲しいわ
５が出たと思ったらもう６とか

PHPなんてゲロ以下だってdankogaiが言ってました

dankogaiがゲロ並だからまぁもっともな意見だな

えっ、それは
PHPはゲロ並みなのに、それなりのシステムが作れるって
ところがPHPのすごいところ
って意味だよ？

>>546
> 質問に答えりゃ生成できる程度のページをわざわざPHPで動かしたがる業務要求なんて
> 実際ほとんど存在しないって事、いつになったら常識になるんだろう

そもそも、質問に答えりゃ生成できる程度のページという
業務要求自体が、実際ほとんど存在しないわけだが。

>>549
ほかに書くこと無いの？

534 名前：nobodyさん[sage] 投稿日：2007/11/07(水) 20:37:13 ID:???
え…PHPerって他できないから仕方なくPHPやってるんじゃないんですかｗｗｗ
PHPerがPHPに惚れ込んでる理由って何なのｗｗｗｗ
逆に問いたいｗｗｗ
問い詰めたいｗｗｗｗ


535 名前：nobodyさん[sage] 投稿日：2007/11/07(水) 20:41:20 ID:???
ヒント

ほとんどのオープンソースのウェブシステムは
なぜPHPで作られているか。

ほらよ
http://anond.hatelabo.jp/20071108232701
レイアウトテンプレート対応だってさ

どうでもいいよ。

ユダヤ人は頭がイイ。イスラエル産のPHPが普及率NO.1
日本人は与えられたものをただ使わせていただくだけという実態。
PHP＞＞＞Perl＞Ruby、Python
使えれば何でもいい。

PHPが糞言語なのは言を俟たないが
Perlだって似たようなもんじゃないの？
danはPerl使ってるだけなのになんでｷﾞｰｸとか自称してんの？

cakePHPのソースは汚いらしいけど
ZendFWのソースのきれいさを100としたら
cakePHPのソースはどのくらいですか？

2

まあ2だろうな

綺麗さ…たったの2…
ゴミだな…

cake見たことないけど2てｗ
どんだけ汚いんだよ。

ヒント：「らしい」

子飼弾はやっぱ実装能力は高いな。日本人のPerlプログラマーの中では明らかに抜けてると思う。

抜けているのは間か？
それとも髪か？

>>566
2かどうかはともかく、汚いというのは確かにそうだ。
そこそこシンプルなのは良い。志を高く持たなければ使える。

志が低い人向けフレームワーク…

子飼弾
と
獅子咆哮弾

なんか似てね？

>>570
オープンソースアプリに共通する「あれ」言ってほしい？

ソース公開されてるんだから
文句があるのなら自分で直せ！

>>570は単に汚いと言ってるだけで、綺麗にしろとも汚いソースを出すなとも言ってないと思うんだが。
>>573はもう少し落ち着いた方がいいんじゃないかな

コメントがしっかりついていれば、ソースが汚くても読める。
コメントの書き方で、作者のツンデレ度が分かる。

外人って、コメントあまり書かないよな。あと、インデントも揃えない。
日本の企業だと、一緒にチーム組むの嫌がられそうだけど、海の向こうだと
そういうのが常識なのか？

コメントは、何をしている処理かというだけでなく、
その目的も添えてくれるといいな。
他人が見た時、そのコードが何のためにあるのか、わかるように。

CodeIgniter今から使ってみようとしてるんだけど、コメントに関しては相当丁寧だね。
他はまだ分からん。

コメントを書くときは、処理の内容についてではなく、仕様について書いておこう。

＝何の処理をやっているのかは、見れば分かるので基本的には不要。
＝仕様を知らない場合は、あちこち調べまわらなければならなくなるので不便。

「あれ〜？おかしいな。こんな動作でいいんかな？」
「（コメントで）それは仕様です。」

仕様なら仕様でもいいんだけど、悩んで調べなければならない時間を減らしたい。

symfonyっていろんなソリューションの組み合わせで
その組み合わせにおいてオリジナルなのな。
だからsymfonyなんだな。
マッシュアップフレームワークとも言える。

はいはい、また出ますよ
http://www.cbook24.com/bm_detail.asp?sku=9784797343052

>>70
> Smartyは糞だってことくらい
> 今じゃ小学生でも知ってます

どういう理由で言っている?
遅いという理由以外で何かあるなら教えて欲しい

Smartyはスレ違いだからよそでやってくれ。

フレームワークと言うのはウェブアプリを作る際の開発手法だったり、設計、あるいはライブラリそのものだったりだから。
Smartyはフレームワークの一部と言える。
PHPからHTML部分をできるだけ分離させるのはウェブフレームワークの機能でもっとも重要な機能。

釣りするな

燃えかすの灰に必死に点火しようとしてる人がいるスレはここか

Smartyはもう不必要な存在だね。

確かに役割を果たした後の感があるが、
さんざん消費してもう不要だとか・・・。
オープンソースに対する敬意をもっと持とうではないか。

もうお前の身体には飽きたんだよ！
ｷﾓﾌﾞﾀにでも抱かれてろや( ﾟдﾟ)､ﾍﾟｯ

viewロジックとテンプレートの分離より
テンプレートとデータの分離の方が重要じゃないかと思えてきた
データを引きはがしたテンプレートの役割とは何なのか？
見せるためのものというより構造を定義するものに近くなる

もしかしてテンプレートにリテラルを記述するのって違うんじゃね
テンプレートからも一切のリテラルを排除すべきなんじゃないか

フレームワーク厨のスレはここですか

>>582
Smartyが糞とまでは思わんが、include()と比べて特に利点があるとは思えない。
また学習コストも無視できない。

覚えてもしばらく使っていないとまた忘れるしね。いちいち面倒だよ。

>>593
何でここでincludeが出てくるのよ。

あのさ、phpをいじって <?php echo $hoge ?>を {$hoge} とかで書けるようにできないもの?

飽きてきた･･･馬鹿は同じネタで飽きなくていいね。

>>596
peclでなかった？

そういやテンプレートエンジンのスレいつの間にか消えてるな。

>>595
Smarty使う代わりに、普通のPHPファイルをテンプレートとして使うため。
function include_template($filename, $vars) {
　extract($vars);
　include($filename);
}
とかね。
とりあえずこれでSmartyいらない。>>242 をみよ。

>>596
>>242

ideとかエディタの設定いじったらいいじゃん
<?php= ?>ってすぐ出せるように

MSIMEに「ぴーえっちぴー」で登録しておけばおk

>>600
{$hoge}みたいなのは自作してるけどforeachは
普通に<?php 〜 ?>なのな。

>>601
そんな書き方できたっけ？
<?= ?> か <?php echo ; ?> のどっちかだと思ってた。
それよりも htmlspecialchars() の名前はどうにかしてほしい。長すぎ。
まあ
function h($val) { echo htmlspecialchars($val); }
としてるけどな！

「すぺきゃら」で登録でおk

>>604
returnで返してエイリアスっぽくしたほうがいいんじゃないの？
個人の自由だけど。

でもキーパンチの時間なんて
コーディング作業全体の中では5％以下くらいだよな多分

>>606
<?php h($val); ?>
として使うんだよ
もちろん <?= ?> は使わない。

https://www.phppro.jp/seminar/
こういうセミナーってどんなものでしょう
本を読むことにはないセミナーの強みって何ですか？

俺も行ってみたいんだが、
ろくにプログラムも書けない俺が行っても…って感じだな…ﾊｧ

>>610
んなこたーない
みんな君のことを待ってるよ

<?= これってどうやったら有効になるの？ ?>

>>612
php.iniのshort_open_tag

short_open_tagって
もうデフォで有効じゃないの？

PHP6じゃ消える運命

嘘っ
完全に消えるの？

もう廃止リストに上がってんだっけ
まあだいぶ前から非推奨になってたしなあshort open tag

まじで？これなくなったら困るよ。

6が普及するのなんて3年後くらいだからおk

いやいやかなり困る。
使わないようにする時に、修正が大変な予感。

どこでも動かせるように昔から使ってないから困らない

既存ソースの修正は困るよ。
修正箇所を探そうと正規表現で検索しても探しにくい。

ソースはこれだけ？
http://www.php.net/~derick/meeting-notes.html#remove-support-for-and-script-language-php-and-add-php-var
だとすれば <? はkeepされそうなんだが。<% はkillすると書いてるな。

<? が無効の時に <? を使っていてもエラーログを残せないからね。（だよね？）

>>622
>修正箇所を探そうと正規表現で検索しても探しにくい。

grep '<¥?=' *.php
で見つかると思うけどなあ。
修正は
$filenames = $argv;
foreach ($filenames as $filename) {
　$s = file_get_contents($filename);
　$s = preg_replace('/<¥?=(.*?)¥?>/', '<?php echo $1; ?>', $s);
　file_put_contents($filename, $s);
}
でよくね？
もしくは
function f($matches) { return '<?php echo ' . trim($matches[1]) . '; ?>' }
$filenames = $argv;
foreach ($filenames as $filename) {
　$s = file_get_contents($filename);
　$s = preg_replace_callback('/<¥?=(.*?)¥?>/', 'f', $s);
　file_put_contents($filename, $s);
}

PHP6の普及なんて遥かかなた先のこと考えてもしょうがない。

>>624
<?= じゃなくて、<? だけのものもある・・。

つか、割と早くから<?=は使うな、みたいなこと言われてた気がするんだけど、やっぱ使う奴いるのな。

<?=は短くていいよ。
Rubyはよく使うものは短くって哲学があるけど、
PHPはわかりやすさが優先されてるからなぁ。
array()とかも面倒くさい。

>>627
たいていの入門書には使うべきではないみたいなことは書かれていたな

PHP6で<??>が消えるというのは・・・
ガセ

ピースフレームワークって
このスレ的には話題になってないけど実際はどうなの？
セミナーとか積極的にしてるみたいだけど。
有限状態マシン？とか用語が難しそうでとっかかりにくいんだよね

PHP 5用ウェブアプリフレームワーク「Solar 1.0.0 alpha1」リリース
http://japan.zdnet.com/news/devsys/story/0,2000056182,20361023,00.htm
どんなもんかな？

アシアルのセミナーは大阪でもやって欲しいな
さすがにセミナーだけのために東京まではいけないわ

>>633
人が集まればどこでもやると思う
集まらなければ東京でも無理
大阪でやってほしければ、おまえが20人くらい集客して直談判すればいい

単に東京で好評だったらやるんじゃね。
前何かのセミナー関西でも開いてたような。

9月だったと思うけど俺行ったよ。
Piceの中の人が講師？だったな。

>>469
遅ればせながらレスありがとう。CI使ってみることにします。

>>633-634
セミナーだけの為に(交通費会社負担で)行った漏れもいる。
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
まぁ実際はセミナーだけでなく・・・・・ｗ(以下略

アシアルのセミナーうけるやつって初心者？あれを受けるレベルのやつが業務でPHPまともに使えるのか。煽りじゃなく純粋に思う

セミナーったって色々やってるじゃん
今回の高負荷サイト対策は興味あるな

>>637
>CI使ってみることにします。
あとでいいんで、感想かいてくれ

>>641
でも高負荷で問題になるのはPHPじゃなくてDBだよなあ。。。
PHPのセミナーじゃなくてDBのセミナーになりそう

PHPのセミナーというか
PHPが分かってる人向けセミナーだな

https://www.asial.co.jp/business/php5migration/index.php
この外人女の顔の意味が分からん
全然PHP5っぽくないしコンサルっぽくもない

PHP5っぽい外人女がみたいです

女「ほっとけ」

どうせ適当に選んだに決まってる

受付けの姉ちゃんだろ

ヒント：無料素材集

>>598
名前が出てこないってことはpeclにないってことかな?
>>600
Smartyとかそういう意味じゃないよ
<?= ?> とか書くのが面倒だから{ とか % に自由に変えられるPHPに組み込めるものはないの?という意味

確かにエディタで簡単に入力できるようにするのも手だけど
tplの時だけ{$hoge} は、<?= $hoge ?> と同じ動きをするという拡張があったら便利じゃね?ということ

>>650
simplateとか、調べるといくつか出てくる。

pythonてどんなに長い整数もメモリが許す限り扱えるのな
suge-
PHP脂肪ｗｗｗ

その理由だけでPHP脂肪ｗｗｗとか、脳が脂肪で出来てるとしか思えん

つかそんな使い方しちゃいかんだろ。

>>651
おおー
simplate良さそうだね
フレームワークと絡めて使っている人いる?

ttp://simplate.aimy.jp/
smarty重いって書いてあるけど、どんだけ重いのかな。

以下のアシアルのドキュメントへのリンクがあったろ?
そこにベンチマークの結果があるよ simplateはすごい早いみたい(当たり前か)

http://www.asial.co.jp/company/files/Smarty2006.pdf

Smarty重いって言うけど、それなりの規模ではじめて重くなるわけで・・・

天文学的計算すらできないPHPが許されるのは小学生までｷｬﾊﾊ

誰かこいつにPHPのbcmathモジュールについて解説してやってくれ
あと「天文学的」は絶対桁数がむやみに多いだけで実効精度は実は大したことないって点もｗ

>>650
だから>>242のリンク先みろ。#{$var}が<?php echo $var; ?>, %{$var}が<?php echo htmlspecialchars($var); ?>に展開されるようになってる。

>>658
そんなことない。Smartyはinclude()の倍以上遅い。

>>657
漏れのacrobat readerだと落ちまくるが何とか最後の方のページにある
ベンチマーク見られたよ。
うーんsmartyは却下だな。simplateつかおっと。

ほんとテンプレートエンジンの話題は別スレ立ててやってくれよ
FWと関係がないとは言わないが内容が無さ過ぎる

>>661
変数をassignしたりしないなら、そもそもSmarty使わないだろ。
include()と比較してどうするんだよ。その後で自前で文字列置換とか
実装してもそんなに速度の差が出ると思ってるのか？

こんなに機能要らないからSmarty以外を選ぶというなら分かるけど、
重いからSmartyは却下というのは、ただ性能の悪いテンプレート
エンジンと認識されているようで気持ち悪い。

アシアルみたいなチンカスが、意味のないベンチマークなんて公開
するもんだから、ますます勘違いする人が増えるんだよ。（中の人は
simplateはえーとか普通に思ってるんだろうけどな）


デザイナーと分業する必要がないけど、テンプレートは分離したいというなら
CodeIgniterとかで開発すれば？基本はPHPベタ書きだけど、最低限の
機能だけのParserがついていて超速い。別に高機能とか要らないんだろ。

>>664
>変数をassignしたりしないなら、そもそもSmarty使わないだろ。
>include()と比較してどうするんだよ。
なんでassignしないとか言い出すの？ちゃんと>>242読んだ？
extract()とinclude()をつかえば生のPHPファイルでも十分テンプレートエンジンとして使えるというだけよ？

>その後で自前で文字列置換とか
>実装してもそんなに速度の差が出ると思ってるのか？
？？？話がまったく見えない。

>こんなに機能要らないからSmarty以外を選ぶというなら分かるけど、
>重いからSmartyは却下というのは、ただ性能の悪いテンプレート
>エンジンと認識されているようで気持ち悪い。
だって性能悪いじゃん。
余計な機能が多い、性能が悪い、デザイナーと連携できない、学習コストがかかる。
Smartyはいいとこのないテンプレートエンジン。

>>660
Windows 版の PHP にはこの拡張モジュールのサポートが組み込まれています。
だって
こんなの組み込んであったのか
なんでwindows版だけ？

JavaScriptでさえ整数は64ビットなのに
いまどき32ビットしか扱えないPHPって(;ﾟ;ж;ﾟ; )ﾌﾞﾌｯ

>>667
ビルゲイツぐらいになると個人資産を勘定するのに32bit intでは足りないときいたことがあるが
>>667の財布をみると16bitで十分みたいだ。

ところで32bit intじゃ足りない場面ってどんなのがある？
file systemは64bitじゃないと困るけど、そのくらいしか思いつかん。

>>667は何かに当たらないとやっていけない可哀想な子

JavaScriptの整数が64bitになったところで使い道はないだろ。
余計にメモり食うだけだし、うれしいやつっているのかな。

>>668
> ビルゲイツぐらいになると個人資産を勘定するのに32bit intでは足りないときいたことがあるが

2006年の長者番付で個人資産$50 Billion = $50,000,000,000
= 0x000B A43B 7400

本当だw　unsignedでも足りないw

多いって聞いてたけど、そんなにあんのかｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ビルゲイツの個人資産すら扱えないPHPって一体…

pythonがIndustrial Light & Magicで使われている理由…
PHPでCG描いたら計算間違えて勝手にエロ画像になるから
pythonがNASAで使われている理由…
PHPでロケット飛ばしたら入射角間違えて大気圏で炎上するから
pythonがgoogleで使われている理由…
PHPでgoogle作ったらインデックスがぶっ壊れて検索速度がはやぶさ以下になるから

ってかロケット操作してる言語ってマジで何だろう？
あと原発で使ってる言語も気になるな。

>>675
つ　http://en.wikipedia.org/wiki/HAL/S

PHPっていまだに2038年問題に対応できてないのか。

ごめん、素人考えで言うけど、その辺はC依存じゃないの？

>>661
Smartyのページキャッシュ使ってればずっと軽いよ

>>665
だから変数置換程度の用途だったら、別にSmartyである必要ないから
軽いテンプレートでも使ってろよ。

お前の言う余計な機能は、お前が使っていないだけで利用価値はあるんだよ。
フィルタやプラグインで拡張するようなことを、直接ごりごり書いたほうが早いのは
当り前で、Plaggableな仕組みに対してそれを言うのは全くの見当違い。

性能が悪いのは機能とのトレードオフだし、デザイナーと連携できないとか、
学習コストがかかるのは別にSmartyに限ったことじゃない。だいたいincluide()
とか言ってるやつが、デザイナーと連携とか湧いてんのか。このうちの一つでも
満たしてるテンプレートエンジン挙げてみろよ。残りの不満点が気ならないほど
素晴らしいのか、それは？何と比較してSmartyを下に見てんの？


というか、なんで俺はSmarty擁護してんの？

以下、Smarty関係禁止！！

そういや、Zendが有料のテンプレートエンジン作ってなかったけ？

業界のフレームワークの話なんだけど、
デザイン屋とシステム屋って上限関係とかあるの？

>>680
>だから変数置換程度の用途だったら、別にSmartyである必要ないから
>軽いテンプレートでも使ってろよ。
だれがそう限定したの？for文やif文だって必要なのはあたりまえ。生PHPならどれも使える。
なんで変数置換だけだと思ったの？

>お前の言う余計な機能は、お前が使っていないだけで利用価値はあるんだよ。
ぜひ説明してくれ。

>フィルタやプラグインで拡張するようなことを、直接ごりごり書いたほうが早いのは
>当り前で、Plaggableな仕組みに対してそれを言うのは全くの見当違い。
おまえこそ見当違い。Smartyが遅いのは内部で生成するPHPコードの効率が悪いから。Plaggableな仕組みは関係ない。
プラグインなし、フィルタなしのテンプレート書いてベンチマークとれば分かる。

>性能が悪いのは機能とのトレードオフだし、
生PHPなら両立できる。

>デザイナーと連携できないとか、
Smartyの{section}{/section}や{if}{/if}はHTMLと相性が悪いし、デザインを崩す。
PHPの<?php ?>はXMLの仕様に含まれるからHTMLと相性がいいし、デザインを崩さない。
もちろん完全に崩さないわけじゃないが、少なくともSmartyよりずっとまし。

>学習コストがかかるのは別にSmartyに限ったことじゃない。
生PHPなら別にかからない。Smartyは学習コストに見合う価値がない。

>だいたいincluide()とか言ってるやつが、デザイナーと連携とか湧いてんのか。
何が言いたいのかわからんが、include()使ったらデザイナーとの連携がとれないとおまえが勘違いしていることはよくわかった。

>このうちの一つでも
>満たしてるテンプレートエンジン挙げてみろよ。残りの不満点が気ならないほど
>素晴らしいのか、それは？
生PHPは速い、高機能、学習コストがかからないという点を満たしてる。Smartyはどれを満たしてる？

>何と比較してSmartyを下に見てんの？
extract()+include()と比較して。

>というか、なんで俺はSmarty擁護してんの？
頭がたりないからじゃね？

javaやrubyは言語がhtmlと親和性ないテンプレートエンジンが重要になってくるわけで。
もともとphp自体がhtmlとの親和性高いんだから不要と言えば不要。

1行目：親和性ない→親和性無いから

同意。

PHPerはいつも仲悪いなｗ
pythonerは常にピースフルだぜえｗｗｗ

PHPを使う→糞言語を使うことによる小さなストレスが蓄積→共食い開始ｗ

糞言語を使ってないハズの他言語利用者が、わざわざ糞言語スレに出張して煽りを入れる理由って・・

勧誘してるんだよ
こっちの水はあーまいぞ
ってことさ

しっ。仕事が無いんだよ。

仕事はあるが全部くそみたいな仕事なんだよ！

pythonの仕事って？

テンプレートエンジンの話をひっぱるやつもウザイし、
ライブラリとベタ書きを比べて話し噛み合ってないやつもキモイ。
あと、どっちも口が悪すぎでPHP界隈の程度の低さが窺い知れる。

みんな、Pythonやるといいよ。

PHPは5から間違った方向に進化したと思うね。PHP5はJavaの出来そこないみたいになっちゃった。
<?=$var?>をもっと高機能にするとか、$_SESSIONや$_REQUESTをクラスにして再定義可能にするとか。
よりウェブ専用に特化すべきだった。

下手にまともな言語になりたがった感はあるが、4ですでにオブジェクト指向の概念を取り込んでいたから開発者もその機能を批判が少なくなるようにしたかったんじゃないか

だったらnamespaceとっととつけろや！

>>699
もうちょい待っとれ

変数に$使う言語(Perl,PHP)は
素性の悪いシェルスクリプトの血を引いているサノバビッチ。
上品なPythonと付き合うと
もうPHP界隈がスラム街にしか見えません（＞＜）

なんか最近蛇蛇うるさいやつがいるね

Smarty擁護派じゃないけど
>>684-685はなんかｷﾓｲ
顔真っ赤にしてﾚｽするってこういう事よね
初めて見たわ

Pythonを使ったことはないがPythonは消えて欲しい
Rubyで十分

>>702
アンチPython厨の工作にしか見えないから普通にスルー推奨

680乙

お前がスルーだよw
Phthonスレに帰れっつーの空気読め。

P言語総合スレまだーﾁﾝﾁﾝ

http://glossary.tank.jp/t0D13.html
【プログラミング】
・本格的な汎用プログラミング言語には馴染めない連中が好んで使うPerl、Python、PHPあたりのあたまに「P」がつくスクリプト言語のこと。

なにこのHP
馬鹿にしてんのか

いつも愛読させていただいてる読者です。
そろそろ、各フレームワークの特徴や
様々なアプリケーションに、どのフレームワークが相性がよい
などといった話題は、いつになったら連載開始なんでしょうか？

それとも、私はタイトルにだまされ続けているのでしょうか？

Round1

CakePHP vs symfony

ファイッ

>>710
そんなもの検索すれば出てくるだろ

>>712
じゃ、ここの存在意義ってないの？

>710
PHPユーザはフレームワークを使えても
内部構造の違いを議論できるほど芸達者じゃありません

>>714
それはお前だけｗ

いいかげんフケ・痒み止まりませんスレ見てるやつは出て行けよ。不潔

パソコンの周りは乾燥してるからな
冬だし

つ PDTのsymfony用プラグイン

Symfoclipse
http://noy.cc/symfoclipse/index.html

>>709
『悪魔の辞典』 (笑)

生粋のオブジェクト指向言語として生まれ
簡単に見せる為にそれを隠蔽しようとすらするPython
非オブジェクト指向言語として卑しく生まれ
後付けで中途半端にオブジェクト指向を取り込んだPHP
P言語とひとくくりにするにはその素性があまりにも違う
PHPの血族はPerlまで

>PHPの血族はPerlまで

正気ですか？

てかPHPって、ホント単にHTMLの中に手軽にスクリプト書けるようにしただけだもんな。
関数群はCのライブラリ関数を、ほとんどそのままラッピングしただけ。
それゆえ、パフォーマンスもいいから実用的になっちゃったわけで。
rubyが速くなったらPHPは駆逐されると思うな。

>>720
>生粋のオブジェクト指向言語として生まれ

ダウト

>720
>生粋のオブジェクト指向言語として生まれ

ﾎﾞｯｼｭｰﾄ

Pythonは何もかもpublicなゆるまんOO

>>722
>rubyが速くなったらPHPは駆逐されると思うな。

ダウト
Webアプリ用としてはRubyは速くならないし、仮に速くなったとしてもPHPを駆逐できるわけない

rubyが世界中の共有レンタルサーバーに
インストールされ動作保障されることが最低条件だな。

その上で、すでに数多く作られている
PHP製のウェブアプリ（ブログやCMSや掲示板やショッピングカート）が
rubyで作られるようになれば、PHPは駆逐されるかもしれんが、
さて何年かかることやら。

Rubyは作者も信者も必死過ぎる。

言語の学習から先に進もうとすると、道が見え辛いんだよな。
一例としてデータベースを使おうとすると、
・リファレンスを読む -> 載ってない
・DB名+Rubyでゲイツる -> パラパラと見つかる程度。王道がﾜｶﾝﾈ
・MLで使用したいDB名を検索 -> 同上
・モジュール一覧にあったものを使ってみる -> 動いたが今でもそれでいいかどうかｼﾞｼﾝﾈｴ
そもそもCGIとして動かしたけど、それでいいのか？とか。

ちょ、ここRubyスレじゃないじゃん！
紛らわしい会話してんじゃねえええええええ(泪)

つか、{}で囲わない言語はゆとりの俺には見ただけで無理と思ってしまう。

そんなことで食わず嫌いせず他の言語にも手つけてみればいい

>>729
おまえはrailsしらんのか。railsつかわずrubyでウェブアプリは考えられない。
なんにせよrailsがPHPのフレームワークに与えた影響も大きい。

JSP + Servlerの事も思い出してあげてください。
JSPタグがいっぱいありますよって。

実は俺Java厨www
JavaでRailsライクなフレームワーク自作してｳﾏｰ！

でっていう

>>735
〜と、Railsという単語を最近知ったJavaの出来損ないがホザいております

え？そこでそういう風に煽るの？

ってかJavaでRailsライクなの作っても全然うまそうじゃないな

生サーブレットで1ページごとに1クラス作るよりは楽だよ（´・ω・｀）
PHP版もだいたいできてきた。フレームワーク作るのも楽しい。

正直もうこのスレいらんよね

PHP脂肪ｗｗｗｗ

もうCakeかRailsでいいよね。

ぶっちゃけ4ベースのFWは全部粗大ゴミ、さっさと捨てな

自作軽量テンプレートシステム＋indexでアクション振り分けてモジュールインクルード。これだけで俺は十分食っていけるｗ

>>745
くやしいがはげどうだな
あとはvalidationとORMか。
validationどうしてる？

その二つつけたらそもそも軽量フレームワークだろが

だったらそうでもいいんじゃない？
別にフレームワークであることをかたくなに否定する必要なんかないじゃん。
必要な機能を揃えていったら、なんかフレームワークみたいになったなー、でいいんでない？

フレームワークつかおうとなかろうと、validationは必要だろ。
だからフレームワーク使ってないやつがどんな方法でvalidationしているのか興味があるから聞いてるのに
なんでこんな的外れな返事がくるかな。

本当にフレームワークを使っていないのなら
Validationは行き当たりばったりだろ？

もしそうではなくてやり方が確立されているとしたら、
それはフレームワークを作っていることと同じことなわけで、
結局、自作フレームワークか、有名なフレームワークかの違い。

俺ならフレームワークを自分で作らず、誰かに作らせるね。

「作らず」じゃなくて「作れず」だろ？ｗ

フレームワークのヴァリデーションだって結局正規表現とか書く。これはフレームワーク使わなくても同じ。
あとは数値、メールのチェックとか。これも一度作れば他で使い回せるし。

フレームワークじゃなきゃ駄目な理由はないな。
ヴァリデーション以外の部分を考えなければ。

ヴァリデーションって、そんなに使いまわせないから。メールアドレスチェックとか全角半角とかだけ、関数にくくり出しとけばそれでいい。
ビジネスロジック部分を上手く抽出して、それをヴァリデーションでも使えるように設計する方がよほど大事。

validationの仕組みがFWに埋まってて暗黙の内に呼ばれるのって使いづらいよね。
Railsのmodelに定義するのもね・・・
画面によって違うvalidation適応したいってなることもあるし。
なんで>>751-752案に賛成。
アクションの中で明示的に自分でvalidation呼びだすで良いと思う。

>>745
俺も俺も。ちなみにO/Rマッパーはどうしてる？
PHP用ActiveRecord(Shrupだっけ？)もあるけど重そうなのでやめ。
O/Rマッパー自動生成スクリプトを作成した。
rubyでActiveRecord使ってDBの情報吸い出して、モデルクラス出力。
find()、count()、delete()とか基本メソッドも全部自動出力でｳﾏｰ

軽量テンプレートにフロントコントローラーで十分と言って、フレームワークじゃないかのように言った後にバリデーションとオーアールマッパもとか言えば当然のツッコミな気がするが。
自分の意見以外は受け付けなくて否定されるとすぐ熱くなるタイプだな。たまにいる。

十分って言ってるのは既存のフレームワークを使わなくても十分って話では。
要は人の作った物だと拡張するときめんどうだったりするから、自作のがいいって話。
既存ので手のつけようのないくらい良い物なら文句はないんだけどさ。

そりゃ自作がいいにきまってるじゃん。

>>755
＞軽量テンプレートにフロントコントローラーで十分と言って、フレームワークじゃないかのように言った後に
フロントコントローラーから受ける仕事を、表示部分に軽量テンプレート使ってるだけだろ？
ＭＣＶ的手法な構造なだけで、このスレで議論されてるフレームワークとは別物だろ？

＞バリデーションとオーアールマッパもとか言えば当然のツッコミな気がするが。
だから、バリデーションとオーアールマッパのことが気になって突っ込み入ったんだろ？

＞自分の意見以外は受け付けなくて否定されるとすぐ熱くなるタイプだな。たまにいる。
頭大丈夫？

↑すまんＭＶＣｗｗｗ

<?php

$view="index.tpl";

// 処理
$entryList=Entry:getList(10);

lnclude($view);

?>

これはひどい

http://slashdot.jp/articles/07/11/25/2248216.shtml
Rubyの世界的人気度9位に上昇でPHP脂肪ｗｗｗ

>>762のように言語依存してる奴は相当頭が悪いのだと思う。
適材適所で使い分ければ良いだけなのにｗｗｗｗ

>>762
んじゃまた来月会おう。

>>762
言語設計としては素晴らしい。けど、あのパフォーマンスの悪さは何とかならないんですか(笑)

速度がなければマシンを買い換えればいいじゃない

もう釣りにスルーすらできないような奴しかいなくなったのかこのスレ

あんたｶｺｲｲよｗ

スルーしてる奴の存在をどうやって確かめるんだよ
スタンド使い乙

継承使いまくりなFWのデバッグのしにくさは異常

>>770
あ、それ同意。
みんなどうやってデバッグしてんの？

まずおもむろに全裸になります

そもそもC++あたりの頃の規約的に継承されたクラスを継承しちゃだめじゃないか？

ウェブアプリでクラスを使わないと表せないようなデータはごく限られた場面だけなんだよ。たいていの場合、連想配列で十分。

クラスの役割によるけど、3階層より深くなるのは設計ミスの可能性がある。

基底クラスにデバッグメソッドがあるんじゃないの？

>>762
志村〜

>>774
バカの一つ覚えみたいに、何でもかんでもクラスにすりゃイイってわけじゃないんですね。
簡単にできることを複雑にやる必要はない＝配列で十分なデータかどうかよく考えるようにしたいと思います。＾＾

>>771
Seleniumとかテストツールがあるじゃないですか？
http://www.thinkit.co.jp/free/article/0705/2/1/

みんな、フレームワークを使ったWebアプリを構築するとき、どんなテストツールを、どんなふうに使ってますか？
→What,Howを教えて！

ファイル一つ読み書きするのにopen(),read(),write(),close()なんてメソッド作ってますが何か

意味あんの？

ぺちぺよんのはなし？

>>779
普通にPHPUnit。
HTTP関係ないテストは説明するまでもないはず。
アクション（リクエスト処理）のテストは、$_GETとか$_POSTの中に値設定して、
アクション呼び出し。そんでデータベースにちゃんと入ってるかとかテスト。
こっちはテスト用のユーティリティーを作らないといかんので準備がめんどいね。
でもやる価値はある。
PHPにもspycってYamlパーサーがあったのには助かった。

>>783
テストデータはYAMLで書くのが楽だよな。
PHPのヒアドキュメントがもう少し洗練されていれば。

http://www.rubyist.net/~matz/20071027.html
ruby公式ロゴ決定でPHP嫉妬ｗｗｗ

http://japan.zdnet.com/news/itm/story/0,2000056188,20361834,00.htm
三木谷とまつもとが結託でPHPのシェア大幅下落ｗｗｗ

アンチRubyの工作員の仕業にしか見えません

周知でしょ

>>779
Seleniumは、PHPというよりHTML(Javascript)側のテストツールだぞ。
XSSとかのテストに便利
（でも、ルール作るのが面倒やな。）

一つ一つのモジュールの出力をテストするにはPHPUnitとかかな。

simpleTest使ってる奴はいねーの？

>>786
Rubyの未来が心配になってきた…

>>786
Googleは技術と戦略を軸に規模を拡大してきた。ただ、それが強みでも弱みでもある。楽天はオペレーションを加えた3つをしっかりとやってきた

何様だ？
楽天とgoogleなんて比べることすらおこがましいだろ
ruby魂売りすぎワロタ

楽天って何のためにRuby採用したん？　Rubyって速いん？

お互いに相手を利用してやろうって魂胆な気がする

>>794
まさにそんな感じだ
おたがい腹の底では相手を全く尊敬してなさそう

>>794
こけても
「まぁ、楽天(Ruby)だしな。」
と思われるので安心です。

>>794
Railsがもてはやされてる頃に、楽天が採用するって言い出したんだよな。
まぁ、どっちもどっちだ。

RailsもどきPHP自作FWの完成度が高まるにつれRailsどうでもよくなってきた。
でも一つの答えをくれたRailsに感謝。
楽天くらい開発スタッフかかえてるんなら自分たちでFW作って社内標準にすればいいのにな。

自作君まだいたんだ

ごむぇん、にぃちゃん・・・

作ってしまえば自作もいいぞ。全部自分好みにできる。

オープンソースのフレームワークだって
全部自分好みにできるがな。

自作っていっても実質railsのパクリンだしね。

自作とかみると、また嘘言ってるよと思う。　
単に俺がしょぼいんだろうなあ…。

世間一般に対するPRだな。世間と言っても、ウェブ開発の動向に興味を持ってる人の世間だけど。
楽天は安くて品揃え良くすれば、Ruby使おうがJava使おうがどうでもいいよ。と普通の世間の人は思ってる。

楽天はショップの管理画面をなんとかしたほうがいい

google＝Java yahoo＝php　　　　　　　　　　　　　　　　　　　　　楽天＝Ruby

Rubyは良い言語だよね？

楽天はrubyと組んでも損することはないが
rubyは楽天と組むとイメージダウンが著しいな

つかGoogle=Javaってｗ

google = pythonってイメージのがつよい。

あれ、Googleって、java利用し始めたんじゃなかったっけ？

前から使ってるとこには使ってるでしょ。
楽天だってjavaもphpも使ってるって言ってるし。

GoogleはサーバサイドではJavaとC++が主流で、Pythonは管理ツールとか。

大きな会社が一つの言語しか使わないなんて面白いことはしないと思いますよ

ほんとこのスレってすれ違いな話しで埋まるよね
PHPでフレームワーク使ってる奴はレアな存在ってことを象徴してるよな
http://www.phppro.jp/phpconference2007/qa/2

>>815
それぞれ個別のFWスレがあるんで
実際に使ってる人達は基本的にそっちでやっている
このスレも前スレくらいまではもう少しまともだった
今はもう煽る奴と煽られる奴しかいない

だから個別スレに分けるなって言ったのに・・・

そろそろJavaを始めようと思います
PHPの難しさを100としたら
Javaの難しさはどのくらいですか？
ちなみにPHPは5でオブジェクト指向で書いてます

単に言語として覚えるだけならそんな苦労はないと思う。
習得時間を要するフレームワーク覚えたり、Tomcatの設定とか
Javaでウェブアプリを作る上で付随することを覚えるのが辛いかもね。

>>818
オブジェクト指向でかけるならそんな難しくないでしょ。　
JAVAでもC++でも…。

俺、未だにオブジェクト指向を理解できてない…orz

やってみればいいじゃない。

>>820
やってみりゃいいよ。
俺はCからJavaに移る時に、3ヶ月目に これがクラスの力か！って閃いた。
初めて自転車に乗る時みたいなもんだ。

俺はオブジェクト指向は難しくないけど、フレームワークがダメ。

>>818
今まで変数の「型」について意識していなかったら結構ひっかかるかも？
それ以外はそんなに苦労しないんじゃないかな、と思う。

JAVAからはじめた俺はSETTERやGETTERがないと気持ち悪くて・・・

仕事や勉強は別として、JavaやC/C++で作りたいものがある人は尊敬するわｗ

test

>>825
俺もだ。ナンセンスと言われようとも、そこはゆずれない。

Pythonはsetter,getterなんて自動で作成しますけどｗ
昭和のかおりのする言語乙

eclipseでやってりゃ自動生成あるからいいんだけどね＞Java
PHPは・・・Zend Studioおねがいしまつ。

作りゃいいじゃん。
つか、作り方どっかに転がってなかったか？

作れば・・とか言ってたらキリねーじゃんｗｗ

>>829
ダウト

・・・いやほんとだったら教えて

いや、だから、対応されるまでここでグチるより、作り方乗ってるサイトあるんだから見て作れるだろって話。
それこそキリないだろ。

PDTでつけてくれればいいんだけどな。SETTERとGETTERの生成。

http://codezine.jp/a/article/aid/1104.aspx

ちょいすれ違いかも知れませんが
皆さんphpでDIコンテナって使う機会ありますか？
便利そうだなーと思うものの実際使ったことがないので効果のほどがわかりません
どうでしょうか

>>837
あれはJavaのような融通の利かない言語のためにあるもの。
スクリプト言語にはまず必要ない。

config.php:
<?php $class = 'Foo'; ?>

main.php:
<?php $obj = new $class(); ?>

でたいてい間に合う。
ああAOPがあったか。AOPがやりたいなら悪くないかもしれんが、
スクリプト言語ならAOPも簡単にできそうだしなあ。やっぱいらんと思う。

Mapleとかまったく無意味と言うか、センスのないフレームワークだったよな。

とりあえず、復帰されたそうだから、俺は応援する。

>>838
ってか、それMockとか作るたびにソース書き直してそれやってるの？
DIコンテナはやっぱりテストする際に、実装しているクラスとMockを簡単に切り替える点にあるといえる

インスタンスの管理だけがDIの利点ではないだろう。
もし、それだけなら単なるFactoryつくればおk

AOPについても同様で、既に作成済みのクラスや機能について
処理を追加したいと考えた際にAOPが無くちゃ何も出来ない。
誰かがソースを直して待つしかないなら、AOPで書き換えるようにする。

もしかして、ソース管理は自分一人でやってないよな？

>>841
>ってか、それMockとか作るたびにソース書き直してそれやってるの？
そうだよ。変更箇所だけを集めたファイル(config.php)を作って、必要があれば都度書き換えてる。
DIコンテナも設定ファイルを書き換えるよね。そのXMLファイルがPHPファイルになっただけ。本質的な違いはない。

>DIコンテナはやっぱりテストする際に、実装しているクラスとMockを簡単に切り替える点にあるといえる
>
>インスタンスの管理だけがDIの利点ではないだろう。
>もし、それだけなら単なるFactoryつくればおk
「実装しているクラスとMockを簡単に切り替える」のは「インスタンスの管理」だと思うんだが違うのかね。
ついでにいうと>>838のコードは「実装しているクラスとMockを簡単に切り替え」ている例だと思うけど。何が不満なのかしら。

>AOPについても同様で、既に作成済みのクラスや機能について
>処理を追加したいと考えた際にAOPが無くちゃ何も出来ない。
>誰かがソースを直して待つしかないなら、AOPで書き換えるようにする。
それはJavaにそういう機能がないだけだよね。クラスの定義自体を動的に行うスクリプト言語にそんなこといわれてもなあ。

>もしかして、ソース管理は自分一人でやってないよな？
人数は関係ないんじゃない？Javaではソース管理が一人だとDIコンテナやAOP使う利点がなくなるの？

あーMaple復活したんだ

や、Mapleというより、今のところはkunitさんが復帰しただけかな。
個人的にはHawkさんこそ復帰して欲しい・・・。

Mapleひきついで「あれ…俺たいしてプログラミング好きじゃないじゃん」
って気づいちゃった人だったけ？

>>842
横レスすまんけど
DIつう仕組みがすでにあるのに俺俺ファクトリーみたいなのを使う理由って何だ？
煽りじゃなくて単純な疑問。答えてくれるとうれしい

>>846
必要ないから。大げさだから。学習コストがかかるから。
俺俺ファクトリーで済むのにわざわざDIを使う理由は何だ？
Javaは融通がきかないからDIコンテナを使うのはわかる。
でも何でも実行時に行うスクリプト言語でわざわざ手間掛けてDIコンテナを使う理由はあるのか？

設定ファイル(config.php)：
<?php $klass = 'Foo'; ?>

main.php:
<?php require_once('config.php'); $obj = new $klass(); ?>

これですむような言語にDIなんて必要ないだろ。

>>845
お前Hawkさんとこに糞なコメント残したtestと同じタイプか？
何かしらプライベートであったからあーいう結末になったんだろ？
俺はあの人のサイトには随分世話になったんだ。
そういう言い方すんな、日本のPHP界にとっても有益な人だっんだ。

本人乙



これでいいかな？

高度に発達したFW信者はネットストーカーと区別がつかない

>>848
糞なコメントって何だ？
事情は知らんが印象に残ってただけで中傷する意図はない
プライベートどうこうじゃなくて個人の資質の問題だろう
気づいたこと自体は気づかないままよりいいんじゃね

>>841はDI厨。
>>846は訓練されたDI厨。

何故にseasaaは叩かれないのだ。

>>847
俺俺ファクトリーもそうだけど、ソースの修正量が増えたときに
インスタンス管理なんかを誰が管理しなくちゃ行けない場面が沢山あるんだよ。

少人数でソースの管理を行っているなら、コミットログとかコミュニケーションの範疇で
なんとかなるけど、規模が大きくなってくるとそれが大変になってくるんだ。
確かに俺俺ファクトリーでも十分使えるけど
>>847 の書いたようなコードが、実際に動く部分に混入するとそれこそ苦労倍増なんだよ。

だから、みんなでコンテナに登録してテストとかの際に切り替えは
コンテナからやっちゃいましょうね。っていう仕組みがDIで簡単にできる。

また、AOPについては前にも書いたけど、誰かがソースを修正しているときに
そのソースの修正を待たずに、処理を追加できる利点があるんだ。
ソースの完了を待って、自分のコードを書くのじゃ遅いから、
あらかじめインタフェースとかを切っておいて決まり事をつける事で
誰かに待たされる事なくプログラムを進める事ができるんだ。


って、長文すまん

俺俺ファクトリーかDIかっていうのは結局のところ程度問題なわけか？
コンパクトで少人数なら俺俺、でかくて大人数ならDI、とかそういう感じ？

>>854
>少人数でソースの管理を行っているなら、コミットログとかコミュニケーションの範疇で
>なんとかなるけど、規模が大きくなってくるとそれが大変になってくるんだ。
>確かに俺俺ファクトリーでも十分使えるけど
>>>847 の書いたようなコードが、実際に動く部分に混入するとそれこそ苦労倍増なんだよ。
おまえが何を問題にしているのかを明確にしてほしいんだけど、「（インスタンス管理のための）コードが、実際に動く部分に混入するとそれこそ苦労倍増」になることが問題ということでOK？
この前提が正しいとしたら、解答は「混入させない」。混入してたらそれはバグだから修正する。それだけ。
でもこれってJavaでも一緒だよね。Javaだと混入させない魔法でもあるの？

>だから、みんなでコンテナに登録してテストとかの際に切り替えは
>コンテナからやっちゃいましょうね。っていう仕組みがDIで簡単にできる。
だからそんなことはDIじゃなくても十分できるの。特にスクリプト言語なら。

>また、AOPについては前にも書いたけど、誰かがソースを修正しているときに
>そのソースの修正を待たずに、処理を追加できる利点があるんだ。
違うだろ。AOPの利点は次の2つ。
* 既存のクラスに手を加えることなく処理を追加できること
* クラス階層を横断して機能を追加できること

>ソースの完了を待って、自分のコードを書くのじゃ遅いから、
>あらかじめインタフェースとかを切っておいて決まり事をつける事で
>誰かに待たされる事なくプログラムを進める事ができるんだ。
それはAOP関係なくて、mockとかdriverとかstubとかいうものでやること。AOPである必要はない。

白熱だなあ

AOPとかDIとかよくわかってない俺

AOPとかDIとか全くわかってない俺も来ましたよ

誰か忘れたけど、Perl on Railsを作ってるみたいだね。
って完全にスレ違いだな。ｽﾏｿ

>>860 どの言語でもパクれるんですね。　んならPHPでいいや。

【総合】PHPフレームワークを語るスレ8
http://pc11.2ch.net/test/read.cgi/php/1192604501/l50

http://slashdot.jp/security/article.pl?sid=07/12/02/1931233
MD5脂肪でPHP脂肪ｗｗｗｗ

>>862は釣りですか

MD5脂肪→PHPはセッションでMD5値を使っている→三段論法でPHP脂肪ｗｗｗ

>>864も釣りですか

Javaで有効だったからPHPでも有効だと思ってるやついるね。
きっとDIとAOPがはやってるからという理由で勉強したJavaプログラマー、社会人3年目くらいか。

個人的には人が書いた俺俺ファクトリーをいじるの(っていうかコード見るの)はやだなあ
使える場面では使ってもいいとおもうよ>DI
少なくとも毛嫌いするようなもんでもないと思う

そんなに駄目かな？ＤＩ。

静的型付け言語であるJavaと
PHPを比べてる時点でナンセンスだと思うけどね

>>867
人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。

>少なくとも毛嫌いするようなもんでもないと思う

嫌ってるんじゃなくて、DIコンテナを使ってうれしい場面がPHPではないってことだろ。好き嫌いの話じゃない。
そんなにいうなら、どう嬉しいのかをちゃんと語ればいいじゃん。ちゃんと説得力を持って。
説得力のある理由がでてきてないから必要ないといわれるわけで。

>>869
スクリプト言語にDIを勧めるほうがナンセンス

DIとMockとAOPの違いを簡潔に教えて頂戴＞えろい方

俺の低レベルな理解力では次のように理解
DI：クラスを置き換えできる。
AOP：メソッドを追加したり置き換えできる。
Mock：DIと同じ？（DIをテスト用途で使うことに特化した呼び名？）

あとmixinってのもあるよね。
mixin＝AOP？

>>872
AOPは既存処理の前後に共通化された処理を挿入する。（前後とは限らない？）
mix-inは、共通で使う処理を関数化しておいて、それを任意のクラスのメソッドとして使えるようにする。
とか俺も半端な知識で言っている。
てかスレ違い。この辺の議論やると終わらないし。

phpで使えるdiコンテナてあるのな
scarletとか手軽そうだね

>>870
>人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。
少なくとも同じじゃないだろ
俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ
>>870自身がどんな場合でもファクトリパターンで対応して
DIなんていらねーって言うんならもう何も言うことないけど

>>875
>俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ
コードって、どれを指してる？
例えば>>847の例だと設定ファイルとメインファイルの両方ともPHPのコードなんだけど、どっちのコードの見通しが悪くなると思ってる？

>DIなんていらねーって言うんならもう何も言うことないけど
DIの概念自体を否定してるんじゃなくて、何でも動的なスクリプト言語ならDIコンテナをわざわざ導入する必要がないといってるだけ。
DIでやろうとしていることは、スクリプト言語なら言語仕様の範囲で簡単に実現できる。
PHPでもDIコンテナが役に立つ例をだれも出せてないじゃん。それを示せばみんな納得できるのに、出しもしないでDIマンセーされてもな。

ほっとけよ。DI議論はもういい。
PHPでウェブプログラミングなんて、そもそも小規模なのばっかだし。

まとめようか。
・DIの概念はPHPにおいても有効である。
・ただし、PHPでは>>847のように比較的簡単に実現できる。
・大掛かりな仕組みは必要ないじゃん。

JavaではDI必須。っていうのが当たり前になりつつあるようだけど
スクリプト言語では>>847のように比較的簡単にできてしまうことが、
静的型付き言語であるJavaでは一筋縄では実現できないから、Springとか
Seasarとかそういう大掛かりな仕組みが必要ってだけじゃない？
あと、Java的にはDI使うとクラス関係が疎結合になり
コンパイルが早くなるらしいね。
PHPの場合、大掛かりなDIを導入するメリットがJavaほどには無いように思う。

>>877そういうなよ。
なぜ、ぶった切ろうとする？
新しい話題提供できるならして欲しい。
DIについて話題になったのは、このスレでは初めてじゃない？
smarty必要か？PHPにフレームワークは必要か？とか
毎度毎度の定期ループしてる話題よりよほど良いと思うがな。

自分が分からない話題が続くとイライラしちゃうんじゃないの？たぶん。
気にすることないよ。

>>878
AOPについではどうだろうか。
JavaでDIのメリットの一つとして、AOPが簡単にできることが挙げられる。
というか、AOPなしだとDIのメリットは半減する。

・PHPでもAOPは有効か？（どんなときに？）
・PHPではAOPも簡単に実現できるか？（YESなら大掛かりな仕組みはいらない）

いや俺はDIいらないでおk。スクリプト言語にはナンセンスで。
てかjavaでもいいや。xmlに書くとかもうウンザリ。
コード読んだ方がどこで何やってるかわかりやすいわ。
他人の俺俺ファクトリーでもスキルある奴が作ってればそれでいい。
だいたいソース読んで困るのは、ファクトリとかそんな知識すらないバカのだし。

DIについて俺の経験を書いてもいい？

以前開発していたちょっと中規模なプロジェクトがあったんだけど、
そのプロジェクトはDIコンテナのような仕組みが無くて、
>>847の書いたようなファクトリモドキを書いて、開発してたんだよ。

で、プロジェクトも終盤になってよし結合テストしよう！ってなったときに、
みんながcommon.phpみたいな必ず読み込まれるようなファイルに
$hoge = 'MyClass'
みたいな記述をして、どこからrequireされたか分からない、autoloadされたクラス内で
$obj = new $hoge($params)
と書かれてたんだわ。
それ自体は別に共通化されたファイル内に書かれていたから良かったんだけど、ときどきデバッグ用に
$hoge = 'OtherClass'
とかって書いちゃってるコードが混入して、結合テストがすごく大変だったトラウマがある。
あと、依存関係が全然整理されてなくて
public function __construct($str){
　　$this->hoge = new $str;
}
なんて記述があったときには、何をnewできるのか、何が newされる対象なのかがわからなくて、保守のときに大変だったトラ ウマがある。（ドキュメントがあまり書かれてなかったんだよね...)

それがあってから、俺が担当するプロジェクトはDIを使うようにしてる。
どこで生成されるべきか、どこで使うか、どうやって切り替えるかを明確にするためにDI使ってる。

設定ファイルの管理は面倒だけど、テストがその分、楽になったかな。
DIのメリットはこんな感じだった。

スクリプト言語でも十分使えると思う。管理という面においては。

http://japan.zdnet.com/security/story/0,3800079245,20362451,00.htm
Apache 2.0系、2.2系にクロスサイトスクリプティングの脆弱性

Apache脂肪でPHPまたもや脂肪ｗｗｗ

>>883
先生！これはPHPだけの問題なのですか？

>>884
そういうことにしといてやれ
もしくはスルーで

>>882
>ときどきデバッグ用に
>$hoge = 'OtherClass'
>とかって書いちゃってるコードが混入して、結合テストがすごく大変だったトラウマがある。

これはデバッグ用のコードが本番用コードに紛れ込んでいたという話だよね？DI関係なくね？
DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。

>あと、依存関係が全然整理されてなくて

依存関係って、例えばどんなの？イメージがわからん。具体例で詳しく。

>何をnewできるのか、何が newされる対象なのかがわからなくて、保守のときに大変だったトラ ウマがある。

これ、DIコンテナで解消できるの？
Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。
これは言語の仕様によるものであって、DIを導入したからといって変わることはないはずだけど。

>（ドキュメントがあまり書かれてなかったんだよね...)
逆にいえば、ドキュメントを書けば済む話？

>>886

>DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。

いや、そういう意味ではなく、デバッグコードが混在してしまったけど、それを探すのに非常に手間がかかるってことをいいたい。
スクリプト言語だから、どこかで変数を変更してもデバッグそるまで、どう動くのか分からない
だからコンテナをファクトリみたいに使って記述を統一した。
ここに、設定ファイル云々は関係ない

>これ、DIコンテナで解消できるの？
Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。

これこそがDI導入によるメリットだと思うが？必要とされるべきオブジェクトはコンテナによって注入される事で、依存関係を解決できるでしょ。
だからへたにnewするんじゃなくて、newするものをコンテナに置く。

>逆にいえば、ドキュメントを書けば済む話？

ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。
でも依存関係とかってドキュメントしにくい部品でもある

>>886
>スクリプト言語だから、どこかで変数を変更してもデバッグそるまで、どう動くのか分からない
>だからコンテナをファクトリみたいに使って記述を統一した。
>ここに、設定ファイル云々は関係ない
いやだからさ、JavaでApplication.javaとconfig.xmlがあって、同じことをPHPでApplication.phpとconfig.phpにするとしよう。
デバッグコードはApplication.{java,php}に書いたの？それで分からなくなったというなら、それはDIも何も関係ないじゃん？どう関係あるの？
デバッグコードをconfig.{java,php}に書いて分からなくなったとしたなら、いくらなんでもセンスなさすぎだろ。config.phpで分からなくなるやつがconfig.xmlにしたところで解決できるわけない。

>これこそがDI導入によるメリットだと思うが？必要とされるべきオブジェクトはコンテナによって注入される事で、依存関係を解決できるでしょ。
>だからへたにnewするんじゃなくて、newするものをコンテナに置く。
これも分からん。まず依存関係が何かを具体例で説明してくれ。
それと、newするものをXMLファイルに書くのと、同じことをPHPファイルに書くことと、どう違うのかちゃんと説明してくれ。

>ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。
>でも依存関係とかってドキュメントしにくい部品でもある
だから何をもって依存関係といってるの

ごめん、>>886じゃなくて>>887でした。

>>887
Application.javaとconfig.xmlはこんなのね。

--- Application.java ---
S2Container container = S2ContainerFactory.create("config.xml");
InterfaceX obj = (InterfaceX)container.getComponent(ClassX.class);

--- config.xml ---
<component class="ClassX">
  <initMethod name="initialize">
    <arg>"foo"</arg>
    <arg>123</arg>
  </initMethod>
</component>

Application.phpとconfig.phpならこんな感じ。

--- Application.php ---
require_once("congif.php");
$obj = create_ClassX();

--- config.php ---
function create_ClassX() {
  $obj = new ClassX();
  $obj->initialize("foo", 123);
  return $obj;
}

これらになんか違いがあるのか？
config.phpなら混乱するのがconfig.xmlでは混乱しないという理由を示してくれ。

なんかそのコード見せられると、configファイルはさすがにXMLに
してもらいたいと感じてしまう。
もっと規模が大きくなってから大々的な移行しなきゃならなくなって
設定ファイルを再利用する場合とか、XSLT等で簡単＆きれいに移行
できるし。
で、もしDIの設定にXML使うとすると、DIコンテナがその辺りのこと
を面倒見てくれるんだったら、それだけでも利用価値ありそう。

congif見てザンギエフ思い出した俺ガイル

やっぱりXMLは醜悪だな。設定ファイルはS式にするべきだ。

>>891
利点ってそれだけ？
Java使ってる他のやつに聞きたいんだけど、設定ファイルをXSLT使って移行するなんてこと本当にするの？そんなプロジェクト今まで見たことも聞いたこともない。
891はほんとにそれをしたことあるの？あるかもしれないという妄想を語っても仕方なくね？
それにおまえのconfig.xmlは手作業での移行ができないほど巨大なのか？おれはせいぜい50行いかない程度なんだけど。
数十行の移行をXSLTで自動化するためだけに、わざわざDIコンテナを勉強して導入するコストは払えん。しかもそんな場面が将来あるかどうかも分からないのに。

>設定ファイルをXSLT使って移行するなんてこと本当にするの
ないないw
ありもしないことを想定して無駄に作業増やすのがJava厨。
strutsのときも、フォワードのパスとかバリデータとか全部XML。
こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・
っていったらビルドのコストがとわけのわからないことを言う。
Java厨って変更の可能性のあるところは全部XMLに追い出した方が
保守性が高いという妄想に取り憑かれすぎ。
XMLに追い出すとソースと2重管理になってウザイって。
DBの設定とかローカライズのメッセージとか、そういうのだけでいいよ。
クラスの名前とかそんなもん追い出すとろくなことにならない。

まあCやらJavaやらコンパイル言語使うと、ソースファイルの中には
設定値を書きたくないという気持ちは理解できる。

>>896
クラス名は設定値じゃないからなー
言語に依存してる物はソースに書く方が俺は良いと思う。
DIとか使わなくてもまともに動いて保守性の高いプログラムは書ける。
だったら使わない方法で俺は行く。

ファクトリー厨の方々、必死すぎだろ
DI否定しないと気がすまんのな

DI否定する気は無いがPHPで使う気にはなれない

>>895
>strutsのときも、フォワードのパスとかバリデータとか全部XML。
>こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・
禿同
XMLに外だししなくてもいいものまで外だししないといけないのがアホらしい。
入力→確認→登録だけの簡単なページ遷移もXMLに書くのが面倒くさくて仕方なかった。
遷移先が変更になることなんかないんだって、簡単なアプリなら。
面倒を強制するな。

>>894-895
俺の場合はPHPとは全く関係ないが、すでに出来上がってるシステムの
スケーラビリティ向上＋UIの一新を目的に大部分を書き直したことある
けど、そのときに設定ファイルの変更点はかなり少なかったからXSLT
使ったよ。
別に設定ファイルがデカイからではなく、そのシステムをデプロイして
使っている人が多かったから一挙に対応するために移行用のXSLT用意し
たらずいぶんあっさり終わった。

>>898
891=887乙

PHP3年ぶりぐらいに使おうと思って色々調べて、最近はPHPもフレームワークかと思いつつ
どれ使おうかと探したが、まあ一応本家だしZend試してみようかとサイトいったんだが
どうにもつながんねえ。
Zendframeworkって今落とせるのか？
ttp://framework.zend.com/
ここ自体応答無しなんだけど。

>>903
昨日はつながってたんだが、
つながらんね

ttp://www.zend.com/en/
こっからZend Studioの評価版落としてインスコ
インスコ先のbin\ZendFramework\libraryにFrameworkが入ってるお

3年ぶりのたまたまが偶然鯖落ちかなんかと重なったのか・・・

>>905
たまたまっぽいんで復旧するまでまつことにするわ。
余計なのインスコしてレジストリ汚したくないし。
でも情報thx

DIContainerの利点は、クラス名を変えれる事ではなくて、
依存関係の注入やインスタンス管理をまとめてコンテナがやってくれる事じゃないの？
つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、
この場で作ったCのオブジェクトににセットして…
とかみたいなコードをいちいち書かなくて済むようになる事こそがメリットだと思う。

2文目、書いたり消したりしてたら色々変になっちまった。スルーしてくれ。

>>907
これもDIコンテナなしで十分実現できるんだろうけど、せっかくだしもうちょっと話を聞かせてもらおうか。

>つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、
>この場で作ったCのオブジェクトににセットして…

ここらへんを詳しく。DIコンテナのメリットが分かるような具体例つきで。

>>907じゃないけど、
DIコンテナなしでも実現できるから
DIコンテナいらないってのはなんかちょっと違うと思う

Javaは機能毎にコンポーネントを細かく切りまくって
ひとつひとつは小さい機能でたくさんのクラスを用意する傾向がある
（PHPをはじめとするスクリプト言語と比較してという意味で）

でそのたくさんのクラスをできるだけ疎結合にするために
ConstructorInjectionなりSetterInjectionなりで
外部からインスタンスを注入するようする、
それがDependency Injection（であってるよな、、）

そうした際に、ある機能（モジュール）を使いたいと思ったときにも
上に書いたようにクラスが細かく分かれているから
様々なインスタンスを注入しなければならなくなる、
AというモジュールはBの注入が必要でBはCとDが、DはEが・・・
とインスタンス間の依存性が複雑になっていった時に、
いちいちその注入のためのコードを毎回書き直して
コンパイルし直すような手間を減らすのが
DIコンテナの役割だと思うんだけど
>>907もおそらくこういうニュアンスだったと思うんだが

俺も別にスクリプト言語でDIコンテナとかいらないと思う
スクリプト言語だと比較的（Javaと比べて）多機能の大きなクラスを作るし
コンテナで管理しないと困るなあと思うほど
インスタンス間の依存関係が複雑になるケースがそんなにないから

そういう意味でPHPにDIコンテナは要らんってのは分かるけど
DIコンテナという仕組み自体が要らんとかだめだとか
それはまたちょっと違う問題じゃないのという気はする

結局好みの問題もあるしなー
でもなんにせよJavaのやり方って普及しないよね。

Javaの崇高なる理論を元にした設計方針
→バカは理解できないから徹底は難しい
優秀なエンジニアの集団
→そのプロジェクトで一番効率的なやり方を自分たちで編み出してやる

結局好み

JAVAの山に幾度か登ったけど、全てリタイヤ…　orz

>>910
だから具体例で説明しろって。
依存関係というのが複雑な例を出して、そのXMLを書いてみせろ。
そしてそれがPHPコードで書くと複雑になるのが、DIコンテナだとすっきり書けるというのを実際に書いて示せ。
具体例を示さずにDIマンセーするのウゼエ

>>910は別に
DIマンセー
と言ってるわけではないだろうが
なんでも噛み付くおまえもウゼエ

PHPER仲違いでPHP脂肪ｗｗｗ

何言っても具体例で説明しろとしか言えないんだろ

DIコンテナ自体理解できないから具体例出して欲しいんだろうよ

おまえらが具体例出せないことはよくわかった

バイトがゴキブリ揚げてケンタッキー脂肪ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
http://news.livedoor.com/article/detail/3417675/

DIの具体例って前から説明されてね？

っていうか具体例だしても、挙げ足なら誰も書けないと思うんだけど。

DIを理解できない頭の悪さを他人のせいにしてるだけだよ
一連の書き込み見てりゃわかるけど

>>921
>DIの具体例って前から説明されてね？
どこに？

>>923に、わかりやすく言えば、班長さんみたいなもんだ。

>>921の文章が難解だと思うのは俺だけでしょうか？

残り少ないレス可能数に、DI 話で盛り上がってるのでスルーされてそのまま
DAT落ちしそうですが、一昨日から試行錯誤しても駄目だったので冒険します。

PRADOのSqlMapについてなんですが

やりたいこと：
〜略〜->QueryForList( 'FooBar', array( '%aaaa%', '%bbb%') );
から、
SELECT * FROM table WHERE ( str Like '%aaaa%' OR str Like '%bbb%' )
に展開して結果を取得したい。（配列数は可変）

やった事：
SqlMap.xml に、
<statement id="FooBar" parameterClass="array">
SELECT * FROM site WHERE
<iterate open="(" close=")" conjunction=" OR ">
str Like #[]#
</iterate>
</statement>
を追記したのですが
Unable to find property '[]' in object 'false' for parameter map 'FooBar-InLineParameterMap'
と出てうまくいきません。

PRADOのSqlMap Manualには <iterate> について書かれていないし、参考にしたのが
ttp://trac.pradosoft.com/prado/browser/trunk/tests/unit/SQLMap/maps/sqlite/DynamicAccount.xml
だったりするのでまだ未実装なのか記述ミスなのかもわかりません。。。
どうやったらうまくいくのかヒントでも何でもいいので、お示しをお願いします。。。

そんなの使わなければ、つまづく事も無いのにね。

http://japan.zdnet.com/security/story/0,3800079245,20362715,00.htm
OSX脂肪でPHP脂肪ｗｗｗ

PHPやっててフォークやソケットやスレッドの知識が身に付きますか？
同じスクリプト言語でもPerlなら付きます
PHPしかしないのは技術者として自殺行為です
初心者こそ最初は他の言語をしましょうね

PHPのことを知らないのなら
黙ってれば恥かかなくてすむのにねｗ

PHP自体がフレームワーク

まあフレームワークは制限だからな

このスレを見ている人はこんなスレも見ています。(ver 0.20)
フケ・痒みがとまらないPart9 [身体・健康]

まだ止まらないのかよｗ

もともとフレームワークのPHP使ってフレムーワーク作る人って恥ずかしくないのかなｗ

そんな事言ったら、どの言語だってそうだろ。
ちなみにフレムーワークは作った事ないけど。

俺もそろそろフレームワークデビューしてみたい（っ´∀｀）っ

PHPはフレームワークとしては貧弱だからな
１枚ぐらい皮を被せたくなるぞ
俺は薄い皮希望だがな

より多くの案件をこなすのが目的なら

CakePHP
導入までの敷居が低い　＝　設置できるレンタルサーバーが多くなる
難易度が低い　＝　多くの技術者がすぐにプロジェクト参加できる
FWの程度が中規模 ＝　オリジナルなFWに変更しやすい

したがってCakePHPがダントツに流行ることは間違いない

俺様分析おつかれさん

RoRがどのレンタルサーバーでも標準装備されれば
RoRが爆発的に流行すると思うが
phpで出来ることをRoRを覚えてまでやる必要があるかどうか
phpの豊富なWEB用ライブラリを超えることはまず不可能だと思う
なぜならphpはWEBだけに特化した言語だから

symfonyはFWにしては大掛かりすぎるのが難点
それゆえに自由度が利かない
案件に合わせてFWを選択するのが一番いいと思うが
CakePHPならどの案件でも使える可能性が高い

PHPはフレームワークじゃなくて、ただのスクリプト言語だからｗ

俺はcakeがどうだとかethnaがどうだとか言ってる奴が根絶するまで
PHP4ベースで書かれてるFWは今すぐ捨てろとここに書き続けるつもりだよ

RoRを設計を参考にしたフレームワークが沢山出ている現状だと、
爆発的に流行することはないと思う。(CakePHPもそうだしね)
それにどう頑張ってもRubyは遅い。

Ruby のブロックをPHPに移植してケロ

せめてクロージャでもあればいいんだけどな

ブロック付いて、配列が[]で書けて、配列とハッシュが区別されて、
型が全部オブジェクトになって、組込クラスが整理されて、
オープンクラスになって組込クラスも自由に書き換えられるようになったら
PHPで本気出す

それPHPの意味なくね？

糞言語でもそこそこ何でもできるので
一度覚えるとそこに安住してしまいがちなのがPHPの最大の欠点だな

HTMLに埋め込めて、$_REQUESTと$_SESSIONがいつでも呼び出せる。これ以上望む物はないよ。

PHPのセッション実装なんてヘッポコじゃないですか

>>942
> PHPはフレームワークじゃなくて、ただのスクリプト言語だからｗ

Rubyははフレームワークじゃなくて、ただのスクリプト言語だからｗ

で？

で？

　　　　　/ﾆＹﾆヽ 
　　　　/（ ﾟ )( ﾟ ）ヽ 
　 　／::::⌒｀´⌒::::＼　　　でっていうｗｗｗｗｗｗｗｗ 
　　|　,-）＿＿＿（-、| 
　　| l　　 |-┬-|　　l | 
　　 ＼ 　 `ー'´ 　 ／

釣りばっかだな

>>943 同意
まあレンサバもPHPなんて動けばいいんだろって思ってるから
なかなかPHP5に全面移行できないってのはいいんだけど、
環境が選べる状況で開発している奴らでもPHP4を引きずったり
いつまでもEUC-JPで書いてみたりっていうのは正直吐き気がする。

携帯だからってソースもSJISで書くとか、もういい加減にしてくれ。
UTF-8通る携帯もたいがい増えてるっていうのをなんで敢えて
スルーかな。

なんか質の悪いやや古参PHPerが癌すぎる。

>>56
UTF-8通らないケータイではSJISで書く
UTF-8通るケータイではSJISも通る
世の中のケータイがすべてUTF-8通るならまだしも、そうでないならSJISで書くのは合理的だと思うけど。

SJISでソース書くやつはバカ

内部（ソースコード含む）はすべてUTF-8で統一し、
入力と出力時にSJISなりに変換すれば良いだけの話だろ。

>>958
いや、そうじゃない。
SJISでソースを書くにしてもoutputで、UTF->Shift-JISに正しく変換できない実装がバカ
そのあたりはやっとPHP6で改善される可能性もあるけど、iconvとかmb_*系の実装はどうなるんだとか
そもそもMS932系の実装はどうなるんだろうか、なんてのを正しく議論していないPHPの上の人らがバカ
あと、全然関係ないけど、javaに近づけとはいわないけど、言語実装を議論せずに矛盾ばかり生み出す言語実装を作ってる上のひとらがバカ

つまり携帯のフロントもあるバックエンドをEUCで書くやつは問題なく馬鹿、てことでおｋ？

>>960
それ（変換とか）よりもSJISの場合はダメ文字絡みがやっぱり一番大きいと思うんだ。
シングルバイト圏の作るライブラリとか。

大体文字コードの変換なんてかつては「必要悪」だったのが今やただのオーバヘッドや
不具合の温床だと思ってそれほど間違ってるかな。

要はWindowsさえ次のOSでごにょごにょやってSJIS(CP932？)捨ててくれれば、問題の
大部分はweb系に関してはほとんど片づきそうな気もする。

結局PHP使う奴はバカでFA

携帯サイトならSJISで統一した方が問題が少ない。当たり前のこと。

>>964
そりゃ携帯実機側の問題は少ないと期待できる（実装・運用されて長いから）かもしれないが、
サーバアプリ構築側でどうかっていう話だろ。

もしUTF-8で統一できればより問題は少なくなりそうだけどな。
絵文字に関しても、だいたいUNICODEにシフトしてるんじゃないの？少なくとも流れは。

そういうのを問答無用で「SJISで統一した方が・・・」「当たり前」って言うのが「癌」てことだろ

まとめた情報を軽く探してみて
ttp://miniturbo.org/memo/2006/12/29/034842/
↑ 一年前の記事くらいしか見つからないのが、なんだかなぁな気分だ。

脳内妄想するやつにかぎって
バカとか当たり前とかで終わるのな

もう携帯もUTF-8で書いて大丈夫だよ。
ソース俺

SJISってDBにぶちこむとDBがぶっ壊れるんでしょ？

そう、そのことを SQL injection という。

>>969
みえみえの釣りはよそに逝ってやってくれませんかね

>>970
みえみえの釣りはよそに逝ってやってくれませんかね

話の流れがよーわからんが、
http://jp.php.net/manual/ja/ref.mbstring.php
の「PHP で動作しないと思われる文字エンコーディングの例を以下に示します。」に、はっきりとSJISって挙げられているんだが。
マニュアル読んでる人って居ないの？

>>972
0x5Cとか分かってて使う分には問題ない

問題点について精通していない限り 内部エンコーディングとして使用するべきではありません。

マヌアル、もとからこんな糞デザインだっけ？
やたらに枠線で区分けされていて、読みにくくなっている気がする。

アンチPHPは去れ。使いたくないなら使うなよ無能。

そりゃPHPだけじゃないだろう？とか明らかに
ピントずれてる発言多いのが今の傾向だな
Java厨かもな