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

【総合】PHPフレーム� ..

862:nobodyさん
07/12/03 18:20:40
URLﾘﾝｸ(slashdot.jp)
MD5脂肪でPHP脂肪ｗｗｗｗ

863:nobodyさん
07/12/03 18:35:44
>>862は釣りですか

864:nobodyさん
07/12/03 21:09:02
MD5脂肪→PHPはセッションでMD5値を使っている→三段論法でPHP脂肪ｗｗｗ

865:nobodyさん
07/12/03 22:25:35
>>864も釣りですか

866:nobodyさん
07/12/04 00:23:04
Javaで有効だったからPHPでも有効だと思ってるやついるね。
きっとDIとAOPがはやってるからという理由で勉強したJavaプログラマー、社会人3年目くらいか。

867:nobodyさん
07/12/04 00:43:22
個人的には人が書いた俺俺ファクトリーをいじるの(っていうかコード見るの)はやだなあ
使える場面では使ってもいいとおもうよ>DI
少なくとも毛嫌いするようなもんでもないと思う

868:nobodyさん
07/12/04 00:47:26
そんなに駄目かな？ＤＩ。

869:nobodyさん
07/12/04 00:48:51
静的型付け言語であるJavaと
PHPを比べてる時点でナンセンスだと思うけどね

870:nobodyさん
07/12/04 01:08:03
>>867
人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。

>少なくとも毛嫌いするようなもんでもないと思う

嫌ってるんじゃなくて、DIコンテナを使ってうれしい場面がPHPではないってことだろ。好き嫌いの話じゃない。
そんなにいうなら、どう嬉しいのかをちゃんと語ればいいじゃん。ちゃんと説得力を持って。
説得力のある理由がでてきてないから必要ないといわれるわけで。

871:nobodyさん
07/12/04 01:23:40
>>869
スクリプト言語にDIを勧めるほうがナンセンス

872:nobodyさん
07/12/04 01:31:29
DIとMockとAOPの違いを簡潔に教えて頂戴＞えろい方

俺の低レベルな理解力では次のように理解
DI：クラスを置き換えできる。
AOP：メソッドを追加したり置き換えできる。
Mock：DIと同じ？（DIをテスト用途で使うことに特化した呼び名？）

あとmixinってのもあるよね。
mixin＝AOP？

873:nobodyさん
07/12/04 10:29:36
>>872
AOPは既存処理の前後に共通化された処理を挿入する。（前後とは限らない？）
mix-inは、共通で使う処理を関数化しておいて、それを任意のクラスのメソッドとして使えるようにする。
とか俺も半端な知識で言っている。
てかスレ違い。この辺の議論やると終わらないし。

874:nobodyさん
07/12/04 12:15:47
phpで使えるdiコンテナてあるのな
scarletとか手軽そうだね

875:nobodyさん
07/12/04 12:38:33
>>870
>人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。
少なくとも同じじゃないだろ
俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ
>>870自身がどんな場合でもファクトリパターンで対応して
DIなんていらねーって言うんならもう何も言うことないけど

876:nobodyさん
07/12/04 16:47:36
>>875
>俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ
コードって、どれを指してる？
例えば>>847の例だと設定ファイルとメインファイルの両方ともPHPのコードなんだけど、どっちのコードの見通しが悪くなると思ってる？

>DIなんていらねーって言うんならもう何も言うことないけど
DIの概念自体を否定してるんじゃなくて、何でも動的なスクリプト言語ならDIコンテナをわざわざ導入する必要がないといってるだけ。
DIでやろうとしていることは、スクリプト言語なら言語仕様の範囲で簡単に実現できる。
PHPでもDIコンテナが役に立つ例をだれも出せてないじゃん。それを示せばみんな納得できるのに、出しもしないでDIマンセーされてもな。

877:nobodyさん
07/12/04 18:03:00
ほっとけよ。DI議論はもういい。
PHPでウェブプログラミングなんて、そもそも小規模なのばっかだし。

878:nobodyさん
07/12/04 18:30:24
まとめようか。
・DIの概念はPHPにおいても有効である。
・ただし、PHPでは>>847のように比較的簡単に実現できる。
・大掛かりな仕組みは必要ないじゃん。

JavaではDI必須。っていうのが当たり前になりつつあるようだけど
スクリプト言語では>>847のように比較的簡単にできてしまうことが、
静的型付き言語であるJavaでは一筋縄では実現できないから、Springとか
Seasarとかそういう大掛かりな仕組みが必要ってだけじゃない？
あと、Java的にはDI使うとクラス関係が疎結合になり
コンパイルが早くなるらしいね。
PHPの場合、大掛かりなDIを導入するメリットがJavaほどには無いように思う。

>>877そういうなよ。
なぜ、ぶった切ろうとする？
新しい話題提供できるならして欲しい。
DIについて話題になったのは、このスレでは初めてじゃない？
smarty必要か？PHPにフレームワークは必要か？とか
毎度毎度の定期ループしてる話題よりよほど良いと思うがな。

879:nobodyさん
07/12/04 19:29:14
自分が分からない話題が続くとイライラしちゃうんじゃないの？たぶん。
気にすることないよ。

880:nobodyさん
07/12/04 19:47:46
>>878
AOPについではどうだろうか。
JavaでDIのメリットの一つとして、AOPが簡単にできることが挙げられる。
というか、AOPなしだとDIのメリットは半減する。

・PHPでもAOPは有効か？（どんなときに？）
・PHPではAOPも簡単に実現できるか？（YESなら大掛かりな仕組みはいらない）

881:877
07/12/04 20:39:47
いや俺はDIいらないでおk。スクリプト言語にはナンセンスで。
てかjavaでもいいや。xmlに書くとかもうウンザリ。
コード読んだ方がどこで何やってるかわかりやすいわ。
他人の俺俺ファクトリーでもスキルある奴が作ってればそれでいい。
だいたいソース読んで困るのは、ファクトリとかそんな知識すらないバカのだし。

882:nobodyさん
07/12/05 01:58:35
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のメリットはこんな感じだった。

スクリプト言語でも十分使えると思う。管理という面においては。

883:nobodyさん
07/12/05 02:04:50
URLﾘﾝｸ(japan.zdnet.com)
Apache 2.0系、2.2系にクロスサイトスクリプティングの脆弱性

Apache脂肪でPHPまたもや脂肪ｗｗｗ

884:nobodyさん
07/12/05 02:15:00
>>883
先生！これはPHPだけの問題なのですか？

885:nobodyさん
07/12/05 08:48:32
>>884
そういうことにしといてやれ
もしくはスルーで

886:nobodyさん
07/12/05 09:18:00
>>882
>ときどきデバッグ用に
>$hoge = 'OtherClass'
>とかって書いちゃってるコードが混入して、結合テストがすごく大変だったトラウマがある。

これはデバッグ用のコードが本番用コードに紛れ込んでいたという話だよね？DI関係なくね？
DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。

>あと、依存関係が全然整理されてなくて

依存関係って、例えばどんなの？イメージがわからん。具体例で詳しく。

>何をnewできるのか、何が newされる対象なのかがわからなくて、保守のときに大変だったトラウマがある。

これ、DIコンテナで解消できるの？
Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。
これは言語の仕様によるものであって、DIを導入したからといって変わることはないはずだけど。

>（ドキュメントがあまり書かれてなかったんだよね...)
逆にいえば、ドキュメントを書けば済む話？

887:nobodyさん
07/12/05 10:42:51
>>886

>DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。

いや、そういう意味ではなく、デバッグコードが混在してしまったけど、それを探すのに非常に手間がかかるってことをいいたい。
スクリプト言語だから、どこかで変数を変更してもデバッグそるまで、どう動くのか分からない
だからコンテナをファクトリみたいに使って記述を統一した。
ここに、設定ファイル云々は関係ない

>これ、DIコンテナで解消できるの？
Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。

これこそがDI導入によるメリットだと思うが？必要とされるべきオブジェクトはコンテナによって注入される事で、依存関係を解決できるでしょ。
だからへたにnewするんじゃなくて、newするものをコンテナに置く。

>逆にいえば、ドキュメントを書けば済む話？

ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。
でも依存関係とかってドキュメントしにくい部品でもある

888:nobodyさん
07/12/05 11:58:35
>>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ファイルに書くことと、どう違うのかちゃんと説明してくれ。

>ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。
>でも依存関係とかってドキュメントしにくい部品でもある
だから何をもって依存関係といってるの

889:nobodyさん
07/12/05 12:17:17
ごめん、>>886じゃなくて>>887でした。

890:nobodyさん
07/12/05 12:21:46
>>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では混乱しないという理由を示してくれ。

891:887じゃないけど
07/12/05 12:49:30
なんかそのコード見せられると、configファイルはさすがにXMLに
してもらいたいと感じてしまう。
もっと規模が大きくなってから大々的な移行しなきゃならなくなって
設定ファイルを再利用する場合とか、XSLT等で簡単＆きれいに移行
できるし。
で、もしDIの設定にXML使うとすると、DIコンテナがその辺りのこと
を面倒見てくれるんだったら、それだけでも利用価値ありそう。

892:nobodyさん
07/12/05 12:50:34
congif見てザンギエフ思い出した俺ガイル

893:nobodyさん
07/12/05 13:36:32
やっぱりXMLは醜悪だな。設定ファイルはS式にするべきだ。

894:nobodyさん
07/12/05 13:52:03
>>891
利点ってそれだけ？
Java使ってる他のやつに聞きたいんだけど、設定ファイルをXSLT使って移行するなんてこと本当にするの？そんなプロジェクト今まで見たことも聞いたこともない。
891はほんとにそれをしたことあるの？あるかもしれないという妄想を語っても仕方なくね？
それにおまえのconfig.xmlは手作業での移行ができないほど巨大なのか？おれはせいぜい50行いかない程度なんだけど。
数十行の移行をXSLTで自動化するためだけに、わざわざDIコンテナを勉強して導入するコストは払えん。しかもそんな場面が将来あるかどうかも分からないのに。

895:nobodyさん
07/12/05 14:03:29
>設定ファイルをXSLT使って移行するなんてこと本当にするの
ないないw
ありもしないことを想定して無駄に作業増やすのがJava厨。
strutsのときも、フォワードのパスとかバリデータとか全部XML。
こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・
っていったらビルドのコストがとわけのわからないことを言う。
Java厨って変更の可能性のあるところは全部XMLに追い出した方が
保守性が高いという妄想に取り憑かれすぎ。
XMLに追い出すとソースと2重管理になってウザイって。
DBの設定とかローカライズのメッセージとか、そういうのだけでいいよ。
クラスの名前とかそんなもん追い出すとろくなことにならない。

896:nobodyさん
07/12/05 14:32:00
まあCやらJavaやらコンパイル言語使うと、ソースファイルの中には
設定値を書きたくないという気持ちは理解できる。

897:895
07/12/05 14:35:03
>>896
クラス名は設定値じゃないからなー
言語に依存してる物はソースに書く方が俺は良いと思う。
DIとか使わなくてもまともに動いて保守性の高いプログラムは書ける。
だったら使わない方法で俺は行く。

898:nobodyさん
07/12/05 14:39:05
ファクトリー厨の方々、必死すぎだろ
DI否定しないと気がすまんのな

899:nobodyさん
07/12/05 15:13:55
DI否定する気は無いがPHPで使う気にはなれない

900:nobodyさん
07/12/05 15:33:26
>>895
>strutsのときも、フォワードのパスとかバリデータとか全部XML。
>こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・
禿同
XMLに外だししなくてもいいものまで外だししないといけないのがアホらしい。
入力→確認→登録だけの簡単なページ遷移もXMLに書くのが面倒くさくて仕方なかった。
遷移先が変更になることなんかないんだって、簡単なアプリなら。
面倒を強制するな。

901:nobodyさん
07/12/05 15:36:14
>>894-895
俺の場合はPHPとは全く関係ないが、すでに出来上がってるシステムの
スケーラビリティ向上＋UIの一新を目的に大部分を書き直したことある
けど、そのときに設定ファイルの変更点はかなり少なかったからXSLT
使ったよ。
別に設定ファイルがデカイからではなく、そのシステムをデプロイして
使っている人が多かったから一挙に対応するために移行用のXSLT用意し
たらずいぶんあっさり終わった。

902:nobodyさん
07/12/05 15:42:51
>>898
891=887乙

903:nobodyさん
07/12/05 16:40:47
PHP3年ぶりぐらいに使おうと思って色々調べて、最近はPHPもフレームワークかと思いつつ
どれ使おうかと探したが、まあ一応本家だしZend試してみようかとサイトいったんだが
どうにもつながんねえ。
Zendframeworkって今落とせるのか？
URLﾘﾝｸ(framework.zend.com)
ここ自体応答無しなんだけど。

904:nobodyさん
07/12/05 17:01:28
>>903
昨日はつながってたんだが、
つながらんね

905:nobodyさん
07/12/05 17:09:29
URLﾘﾝｸ(www.zend.com)
こっからZend Studioの評価版落としてインスコ
インスコ先のbin\ZendFramework\libraryにFrameworkが入ってるお

906:nobodyさん
07/12/05 17:30:30
3年ぶりのたまたまが偶然鯖落ちかなんかと重なったのか・・・

>>905
たまたまっぽいんで復旧するまでまつことにするわ。
余計なのインスコしてレジストリ汚したくないし。
でも情報thx

907:nobodyさん
07/12/05 18:44:23
DIContainerの利点は、クラス名を変えれる事ではなくて、
依存関係の注入やインスタンス管理をまとめてコンテナがやってくれる事じゃないの？
つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、
この場で作ったCのオブジェクトににセットして…
とかみたいなコードをいちいち書かなくて済むようになる事こそがメリットだと思う。

908:907
07/12/05 18:49:05
2文目、書いたり消したりしてたら色々変になっちまった。スルーしてくれ。

909:nobodyさん
07/12/05 18:50:44
>>907
これもDIコンテナなしで十分実現できるんだろうけど、せっかくだしもうちょっと話を聞かせてもらおうか。

>つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、
>この場で作ったCのオブジェクトににセットして…

ここらへんを詳しく。DIコンテナのメリットが分かるような具体例つきで。

910:nobodyさん
07/12/05 20:13:07
>>907じゃないけど、
DIコンテナなしでも実現できるから
DIコンテナいらないってのはなんかちょっと違うと思う

Javaは機能毎にコンポーネントを細かく切りまくって
ひとつひとつは小さい機能でたくさんのクラスを用意する傾向がある
（PHPをはじめとするスクリプト言語と比較してという意味で）

でそのたくさんのクラスをできるだけ疎結合にするために
ConstructorInjectionなりSetterInjectionなりで
外部からインスタンスを注入するようする、
それがDependency Injection（であってるよな、、）

そうした際に、ある機能（モジュール）を使いたいと思ったときにも
上に書いたようにクラスが細かく分かれているから
様々なインスタンスを注入しなければならなくなる、
AというモジュールはBの注入が必要でBはCとDが、DはEが・・・
とインスタンス間の依存性が複雑になっていった時に、
いちいちその注入のためのコードを毎回書き直して
コンパイルし直すような手間を減らすのが
DIコンテナの役割だと思うんだけど
>>907もおそらくこういうニュアンスだったと思うんだが

俺も別にスクリプト言語でDIコンテナとかいらないと思う
スクリプト言語だと比較的（Javaと比べて）多機能の大きなクラスを作るし
コンテナで管理しないと困るなあと思うほど
インスタンス間の依存関係が複雑になるケースがそんなにないから

そういう意味でPHPにDIコンテナは要らんってのは分かるけど
DIコンテナという仕組み自体が要らんとかだめだとか
それはまたちょっと違う問題じゃないのという気はする

911:nobodyさん
07/12/05 20:51:19
結局好みの問題もあるしなー
でもなんにせよJavaのやり方って普及しないよね。

Javaの崇高なる理論を元にした設計方針
→バカは理解できないから徹底は難しい
優秀なエンジニアの集団
→そのプロジェクトで一番効率的なやり方を自分たちで編み出してやる

912:nobodyさん
07/12/05 22:00:20
結局好み

913:nobodyさん
07/12/05 22:10:55
JAVAの山に幾度か登ったけど、全てリタイヤ…　orz

914:nobodyさん
07/12/06 00:19:55
>>910
だから具体例で説明しろって。
依存関係というのが複雑な例を出して、そのXMLを書いてみせろ。
そしてそれがPHPコードで書くと複雑になるのが、DIコンテナだとすっきり書けるというのを実際に書いて示せ。
具体例を示さずにDIマンセーするのウゼエ

915:nobodyさん
07/12/06 00:31:56
>>910は別に
DIマンセー
と言ってるわけではないだろうが
なんでも噛み付くおまえもウゼエ

916:nobodyさん
07/12/06 00:38:46
PHPER仲違いでPHP脂肪ｗｗｗ

917:nobodyさん
07/12/06 00:41:48
何言っても具体例で説明しろとしか言えないんだろ

918:nobodyさん
07/12/06 01:18:29
DIコンテナ自体理解できないから具体例出して欲しいんだろうよ

919:nobodyさん
07/12/06 02:05:44
おまえらが具体例出せないことはよくわかった

920:nobodyさん
07/12/06 10:46:27
バイトがゴキブリ揚げてケンタッキー脂肪ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
URLﾘﾝｸ(news.livedoor.com)

921:nobodyさん
07/12/06 11:19:50
DIの具体例って前から説明されてね？

っていうか具体例だしても、挙げ足なら誰も書けないと思うんだけど。

922:nobodyさん
07/12/06 11:23:59
DIを理解できない頭の悪さを他人のせいにしてるだけだよ
一連の書き込み見てりゃわかるけど

923:nobodyさん
07/12/06 13:32:45
>>921
>DIの具体例って前から説明されてね？
どこに？

924:nobodyさん
07/12/06 13:35:42
>>923に、わかりやすく言えば、班長さんみたいなもんだ。

925:nobodyさん
07/12/06 13:42:24
>>921の文章が難解だと思うのは俺だけでしょうか？

926:nobodyさん
07/12/06 17:06:31
残り少ないレス可能数に、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> について書かれていないし、参考にしたのが
URLﾘﾝｸ(trac.pradosoft.com)
だったりするのでまだ未実装なのか記述ミスなのかもわかりません。。。
どうやったらうまくいくのかヒントでも何でもいいので、お示しをお願いします。。。

927:nobodyさん
07/12/06 17:13:51
そんなの使わなければ、つまづく事も無いのにね。

928:nobodyさん
07/12/08 05:30:02
URLﾘﾝｸ(japan.zdnet.com)
OSX脂肪でPHP脂肪ｗｗｗ

929:nobodyさん
07/12/08 17:30:22
PHPやっててフォークやソケットやスレッドの知識が身に付きますか？
同じスクリプト言語でもPerlなら付きます
PHPしかしないのは技術者として自殺行為です
初心者こそ最初は他の言語をしましょうね

930:nobodyさん
07/12/09 01:24:32
PHPのことを知らないのなら
黙ってれば恥かかなくてすむのにねｗ

931:nobodyさん
07/12/09 05:26:30
PHP自体がフレームワーク

932:nobodyさん
07/12/09 05:32:16
まあフレームワークは制限だからな

933:nobodyさん
07/12/09 05:33:35
このスレを見ている人はこんなスレも見ています。(ver 0.20)
フケ・痒みがとまらないPart9 [身体・健康]

まだ止まらないのかよｗ

934:nobodyさん
07/12/09 07:36:41
もともとフレームワークのPHP使ってフレムーワーク作る人って恥ずかしくないのかなｗ

935:nobodyさん
07/12/09 07:44:51
そんな事言ったら、どの言語だってそうだろ。
ちなみにフレムーワークは作った事ないけど。

936:nobodyさん
07/12/09 12:05:37 v5bnJUO2
俺もそろそろフレームワークデビューしてみたい（っ´∀｀）っ

937:nobodyさん
07/12/09 12:20:44
PHPはフレームワークとしては貧弱だからな
１枚ぐらい皮を被せたくなるぞ
俺は薄い皮希望だがな

938:nobodyさん
07/12/09 13:22:15
より多くの案件をこなすのが目的なら

CakePHP
導入までの敷居が低い　＝　設置できるレンタルサーバーが多くなる
難易度が低い　＝　多くの技術者がすぐにプロジェクト参加できる
FWの程度が中規模＝　オリジナルなFWに変更しやすい

したがってCakePHPがダントツに流行ることは間違いない

939:nobodyさん
07/12/09 13:30:49
俺様分析おつかれさん

940:nobodyさん
07/12/09 13:36:11
RoRがどのレンタルサーバーでも標準装備されれば
RoRが爆発的に流行すると思うが
phpで出来ることをRoRを覚えてまでやる必要があるかどうか
phpの豊富なWEB用ライブラリを超えることはまず不可能だと思う
なぜならphpはWEBだけに特化した言語だから

941:nobodyさん
07/12/09 13:40:00
symfonyはFWにしては大掛かりすぎるのが難点
それゆえに自由度が利かない
案件に合わせてFWを選択するのが一番いいと思うが
CakePHPならどの案件でも使える可能性が高い

942:nobodyさん
07/12/09 13:42:29
PHPはフレームワークじゃなくて、ただのスクリプト言語だからｗ

943:nobodyさん
07/12/09 13:58:55
俺はcakeがどうだとかethnaがどうだとか言ってる奴が根絶するまで
PHP4ベースで書かれてるFWは今すぐ捨てろとここに書き続けるつもりだよ

944:nobodyさん
07/12/09 15:01:24
RoRを設計を参考にしたフレームワークが沢山出ている現状だと、
爆発的に流行することはないと思う。(CakePHPもそうだしね)
それにどう頑張ってもRubyは遅い。

945:nobodyさん
07/12/09 15:26:21
Ruby のブロックをPHPに移植してケロ

946:nobodyさん
07/12/09 15:47:26
せめてクロージャでもあればいいんだけどな

947:nobodyさん
07/12/09 16:40:22
ブロック付いて、配列が[]で書けて、配列とハッシュが区別されて、
型が全部オブジェクトになって、組込クラスが整理されて、
オープンクラスになって組込クラスも自由に書き換えられるようになったら
PHPで本気出す

948:nobodyさん
07/12/09 16:57:14
それPHPの意味なくね？

949:nobodyさん
07/12/09 18:14:30
糞言語でもそこそこ何でもできるので
一度覚えるとそこに安住してしまいがちなのがPHPの最大の欠点だな

950:nobodyさん
07/12/09 18:52:11
HTMLに埋め込めて、$_REQUESTと$_SESSIONがいつでも呼び出せる。これ以上望む物はないよ。

951:nobodyさん
07/12/09 19:05:19
PHPのセッション実装なんてヘッポコじゃないですか

952:nobodyさん
07/12/09 19:37:21
>>942
> PHPはフレームワークじゃなくて、ただのスクリプト言語だからｗ

Rubyははフレームワークじゃなくて、ただのスクリプト言語だからｗ

で？

953:nobodyさん
07/12/09 20:10:57
で？

954:nobodyさん
07/12/09 20:53:42
　　　　　/ﾆＹﾆヽ　
　　　　/（　ﾟ　)(　ﾟ　）ヽ　
　　　／::::⌒｀´⌒::::＼　　　でっていうｗｗｗｗｗｗｗｗ　
　　|　,-）＿＿＿（-、|　
　　|　l　　　|-┬-|　　l　|　
　　　＼　　　`ー'´　　　／

955:nobodyさん
07/12/09 21:04:50
釣りばっかだな

956:nobodyさん
07/12/09 21:26:06
>>943 同意
まあレンサバもPHPなんて動けばいいんだろって思ってるから
なかなかPHP5に全面移行できないってのはいいんだけど、
環境が選べる状況で開発している奴らでもPHP4を引きずったり
いつまでもEUC-JPで書いてみたりっていうのは正直吐き気がする。

携帯だからってソースもSJISで書くとか、もういい加減にしてくれ。
UTF-8通る携帯もたいがい増えてるっていうのをなんで敢えて
スルーかな。

なんか質の悪いやや古参PHPerが癌すぎる。

957:nobodyさん
07/12/09 21:33:46
>>56
UTF-8通らないケータイではSJISで書く
UTF-8通るケータイではSJISも通る
世の中のケータイがすべてUTF-8通るならまだしも、そうでないならSJISで書くのは合理的だと思うけど。

958:nobodyさん
07/12/09 21:40:40
SJISでソース書くやつはバカ

959:nobodyさん
07/12/09 22:03:27
内部（ソースコード含む）はすべてUTF-8で統一し、
入力と出力時にSJISなりに変換すれば良いだけの話だろ。

960:nobodyさん
07/12/09 22:09:00
>>958
いや、そうじゃない。
SJISでソースを書くにしてもoutputで、UTF->Shift-JISに正しく変換できない実装がバカ
そのあたりはやっとPHP6で改善される可能性もあるけど、iconvとかmb_*系の実装はどうなるんだとか
そもそもMS932系の実装はどうなるんだろうか、なんてのを正しく議論していないPHPの上の人らがバカ
あと、全然関係ないけど、javaに近づけとはいわないけど、言語実装を議論せずに矛盾ばかり生み出す言語実装を作ってる上のひとらがバカ

961:nobodyさん
07/12/09 22:17:02
つまり携帯のフロントもあるバックエンドをEUCで書くやつは問題なく馬鹿、てことでおｋ？

962:nobodyさん
07/12/09 22:40:08
>>960
それ（変換とか）よりもSJISの場合はダメ文字絡みがやっぱり一番大きいと思うんだ。
シングルバイト圏の作るライブラリとか。

大体文字コードの変換なんてかつては「必要悪」だったのが今やただのオーバヘッドや
不具合の温床だと思ってそれほど間違ってるかな。

要はWindowsさえ次のOSでごにょごにょやってSJIS(CP932？)捨ててくれれば、問題の
大部分はweb系に関してはほとんど片づきそうな気もする。

963:nobodyさん
07/12/09 23:28:47
結局PHP使う奴はバカでFA