【PHP】フレームワークについて語るスレ7【総合】
1 ：nobodyさん：
前スレ
【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/
【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/
|
|
|
>>1
乙
乙
↓以下Rubyを崇めるレス↓
>>1
乙
乙
そろそろまともなフレームワーク整ってくれ。
php6まで無理かな？
php6まで無理かな？
乙！
おつ
agaviのこと、おまえら忘れてない？
agaviのこと、おまえら忘れてない？
agaviのこと、おまえら忘れてない？
phpspotとかで今頃「Mojavi復活！」って書いてるけど
ずっと前からあんな状態だっつの
ずっと前からあんな状態だっつの
PHPってPapparapa Hentai Pugyaの略って本当ですか？
m9
ﾉ
ﾌﾟｷﾞｬｰ! (^Д^)
( ( 9m
< ＼
m9
ﾉ
ﾌﾟｷﾞｬｰ! (^Д^)
( ( 9m
< ＼
“犯罪者のための言語”Rubyの作者が
作りの悪いウェブアプリの心配をするのが解せません
犯罪者がウェブアプリ作る方が危険じゃないでしょうか？
常識で考えて
作りの悪いウェブアプリの心配をするのが解せません
犯罪者がウェブアプリ作る方が危険じゃないでしょうか？
常識で考えて
PHP on Rails
DHHをもう一度PHPに振り向かせるにはどうしたらいいですか？
若い娘に乗り換えられて悔しいっ ﾋﾞｸﾋﾞｸ
若い娘に乗り換えられて悔しいっ ﾋﾞｸﾋﾞｸ
14 ：nobodyさん：2007/06/10(日) 11:20:45 ID:g9vmzoll
>>9
だよな。何を今さら・・って思った。
だよな。何を今さら・・って思った。
てかさぁ、テンプレでフレームワーク一覧くらい書けよ。
16 ：nobodyさん：2007/06/10(日) 12:04:21 ID:g9vmzoll
>>15
どこまで入れるの？
どこまで入れるの？
フレームワークの使い方がわかんないんだけど＞＜
Railsはオンラインで読めるドキュメントが少ないのが
ちょっとね。紙の本だとどうしても翻訳が遅くなってしまうし、
APIのリファレンスも見づらい。
とりあえず今すぐ何かフレームワーク使いたいなら
やっぱりPHPかなって気もする。
ちょっとね。紙の本だとどうしても翻訳が遅くなってしまうし、
APIのリファレンスも見づらい。
とりあえず今すぐ何かフレームワーク使いたいなら
やっぱりPHPかなって気もする。
若い娘っていうか、PHPの方が若いけどな。年齢的には。
PHPは誰にでも股開くイメージ
童貞を捨てるには丁度いいじゃないか。
つまりは、入門者には最適。
つまりは、入門者には最適。
22 ：nobodyさん：2007/06/10(日) 23:48:11 ID:g9vmzoll
おまけに中田氏自由
ＺＦのドキュメントは判りやすいと思うよ
やっぱ日本男児なら日本で開発されたRubyを一度はやっておくべきだろう
awkが最強
Matzがアメリカナイズされているから日本男児ではない。よってRubyも所詮は異国のものだ
日本男児を標榜するなら
なでしことか言う奴使えや
なでしことか言う奴使えや
やっぱ日本男児なら日本で開発されたなでしこを一度はやっておくべきだろう
やっぱ日本女児なら日本で開発されたなでしこを一度はやっておくべきだろう
日本男児ならますらおをやるべき
PHP on Rails
php4かつ小規模ならいいのでは
PHP嫌いのヒゲはブログで紹介してる本本当に全部読んでんのか？
どんな速読法マスターだよ
どんな速読法マスターだよ
>>36
それはもともと10分で理解できる程度の内容の本だっただけでは・・・
それはもともと10分で理解できる程度の内容の本だっただけでは・・・
10分で読めって言われれば、実用情報程度の新書なら
本読みなら読めるでしょ。速読法とか関係ない。
本読みなら読めるでしょ。速読法とか関係ない。
ダニー?
・・・ダニ?
・・・・・・ｷﾓｽ
・・・ダニ?
・・・・・・ｷﾓｽ
髭とかどうでもいいよ。
オブジェクト脳のないやつはほっとけ。
オブジェクト脳のないやつはほっとけ。
,, -──- ､._
．-"´ ＼．
：/ _ノ ヽ､_ ヽ.： PHPerがオブジェクト脳て・・・
：/ oﾟ(（●）) (（●）)ﾟoヽ：
：| （__人__） |：
：l ) ( l：
：` ､ `ー' /：
：, -‐ (_). ／
：ｌ_ｊ_ｊ_ｊ と)丶─‐┬．''´
：ヽ ：i |：
：/ ：⊂ノ|：
．-"´ ＼．
：/ _ノ ヽ､_ ヽ.： PHPerがオブジェクト脳て・・・
：/ oﾟ(（●）) (（●）)ﾟoヽ：
：| （__人__） |：
：l ) ( l：
：` ､ `ー' /：
：, -‐ (_). ／
：ｌ_ｊ_ｊ_ｊ と)丶─‐┬．''´
：ヽ ：i |：
：/ ：⊂ノ|：
子飼はIQが高いらしいし、速読とかも出来るのかモナ。
しかし、>>40-4１の流れがツボに入った。
しかし、>>40-4１の流れがツボに入った。
ここで本人が一言
↓↓↓ドゾー
↓↓↓ドゾー
Perl>>>>>>>>>>>>>c>>Ruby>>Python>>PHP
m9(^Д^)ﾌﾟｷﾞｬｰｰｰｯ
m9(^Д^)ﾌﾟｷﾞｬｰｰｰｯ
>>44
お前程度の認識の奴はPHPのHTML埋め込み部分以外は全部挫折。
Cはかじっただけ。Javaすら知らず、すでに30過ぎ。
何も出来ないからRubyやPython先取りしようと
手をだすけれど全部中途半端。
出来るのはPerlで掲示板レベルで止まってる。
向いてないから転職先探せよm9(^Д^)
お前程度の認識の奴はPHPのHTML埋め込み部分以外は全部挫折。
Cはかじっただけ。Javaすら知らず、すでに30過ぎ。
何も出来ないからRubyやPython先取りしようと
手をだすけれど全部中途半端。
出来るのはPerlで掲示板レベルで止まってる。
向いてないから転職先探せよm9(^Д^)
選択肢多すぎて、知識が陳腐かするのが早すぎる
Cはこの先１０年くらい最低安泰だろ。
>>47 Cは今後も安泰だと思うが、Cの使い道をおしえてくれ
他言語を学ぶ上で確実な土台になる。
これからどんな新しい技術が出てきても、Cで得た知識や経験は無駄にならないだろ。
PerlもPHPもCから来てる品。
これからどんな新しい技術が出てきても、Cで得た知識や経験は無駄にならないだろ。
PerlもPHPもCから来てる品。
>>48
画像処理とかハードに近い部分とかではまだまだ一般的だと思うが。
画像処理とかハードに近い部分とかではまだまだ一般的だと思うが。
組み込み系もほぼC言語だな。Javaもあるけど
素朴な疑問なんだが
なんでc++で作らないの？
遅くなるの？
なんでc++で作らないの？
遅くなるの？
ソフトウェア作るときはC++じゃないのか？
組み込みはそこまで複雑ではないからCでいけるのでは？
組み込みはそこまで複雑ではないからCでいけるのでは？
C++はウンコ
PHP５で書かれた軽量のフレームワークって何があるかな？
ちいたんくらいがベストなんだが、PHP４だしな。
ZENDはちょっと重過ぎる。
ちいたんくらいがベストなんだが、PHP４だしな。
ZENDはちょっと重過ぎる。
zendが重いとなると、他のフレームワークは難しいんじゃないかな。
だいぶ前に触ったときは「必要になった時に必要なものを使う」という感じだったから、コード量は少し多くても随分速かった。
他のPHPフレームワークと比べてね。
といっても最近のzendはいじってないから分かんないけど。
だいぶ前に触ったときは「必要になった時に必要なものを使う」という感じだったから、コード量は少し多くても随分速かった。
他のPHPフレームワークと比べてね。
といっても最近のzendはいじってないから分かんないけど。
CIはPHP4/5でわりと軽いけど
PHP5専用ってのはないね
PHP5専用ってのはないね
>>54
どのへんが？
どのへんが？
ちいたんは、PHP4/5 割と高速ですよ。
単なる疑問なんだけど，4 で動くように書かれてても，
5 でも動くなら 5 で使えばいい気がするんだけど，ちいたんを 5 で使うと何かデメリットがあるの？
フレームワークは 4 用で，自分で書くコードは 5 で書けばいい，ってわけにはいかないのかな？
フレームワークレベルで例外とかの仕組みがサポートされていない，とかはデメリットになるかもな……
5 でも動くなら 5 で使えばいい気がするんだけど，ちいたんを 5 で使うと何かデメリットがあるの？
フレームワークは 4 用で，自分で書くコードは 5 で書けばいい，ってわけにはいかないのかな？
フレームワークレベルで例外とかの仕組みがサポートされていない，とかはデメリットになるかもな……
>>61 まずは試すことだよ
おまいら、
for ($i = 0; $i<count($my_array); $i++)
instead, we try to always do:
for ($i = 0, $count = count($my_array); $i<$count; $i++)
この違いがわかるか！
http://www.symfony-project.com/weblog/2007/06/11/is-symfony-too-slow-for-real-world-usage.html
for ($i = 0; $i<count($my_array); $i++)
instead, we try to always do:
for ($i = 0, $count = count($my_array); $i<$count; $i++)
この違いがわかるか！
http://www.symfony-project.com/weblog/2007/06/11/is-symfony-too-slow-for-real-world-usage.html
効率化の方法か？
CodeIgniter使い方が分りやすくていいね。
名前って大事だよね
名前って大事だよね
>>64
http://www.symfony-project.com/weblog/2007/06/11/is-symfony-too-slow-for-real-world-usage.html
「symfonyは遅い遅いとかいってるやつ、よーく聞けや、
実際最適化されていないかっていうとそういうわけでもない、
っていうかおまえらHello worldのベンチが遅いって言うけどさ、
FWの速さをHello worldのベンチ結果ひとつで比べんなっつーのｗｗｗ
あのな、FWにおいて速さは一番大事な話じゃねーんだよ、
Hello worldベンチが遅いからsymfonyはダメってやつはバカ」
by フランチョス
http://www.symfony-project.com/weblog/2007/06/11/is-symfony-too-slow-for-real-world-usage.html
「symfonyは遅い遅いとかいってるやつ、よーく聞けや、
実際最適化されていないかっていうとそういうわけでもない、
っていうかおまえらHello worldのベンチが遅いって言うけどさ、
FWの速さをHello worldのベンチ結果ひとつで比べんなっつーのｗｗｗ
あのな、FWにおいて速さは一番大事な話じゃねーんだよ、
Hello worldベンチが遅いからsymfonyはダメってやつはバカ」
by フランチョス
Symfonyは速度以外の面で
特にどういうところにメリットが大きいとお考えで？
特にどういうところにメリットが大きいとお考えで？
たかがHalloWorld程度の処理で遅さを露呈するSymfonyがダメダメなのは当たり前じゃないか。
フランチョスは馬鹿だな。
フランチョスは馬鹿だな。
HelloWorld最速のC最強!!
PHPなんてゴミカス
PHPなんてゴミカス
http://userguide.cilab.info/toc.html
CodeIgniter ユーザガイド 日本語版 Version 1.5.3
和訳してくれた方どうもありがとうです。
CIの説明を読んだら俺でも理解できました。
これでやっとフレームワークデビューできそうですｗ＼(^o^)／
CodeIgniter ユーザガイド 日本語版 Version 1.5.3
和訳してくれた方どうもありがとうです。
CIの説明を読んだら俺でも理解できました。
これでやっとフレームワークデビューできそうですｗ＼(^o^)／
cakeかCIかZendか・・・
翻訳されないと読めないって、英語できないと大変だな。
一応義務教育で英語習ってなかったのか？
C++で作られたOSってまだ無いしな。
一応義務教育で英語習ってなかったのか？
C++で作られたOSってまだ無いしな。
>>74
WindowsやClassic Mac OSは無視ですかそうですか。
WindowsやClassic Mac OSは無視ですかそうですか。
どっちもソース読んだことないし
77 ：nobodyさん：2007/06/16(土) 20:56:55 ID:Zcz+cnSv
>>75
Linuxも無視だなｗ
Linuxも無視だなｗ
処理の最適化が必要なOSの下層レイヤーは普通Cでかくわな
>>74
MonaOSは？
MonaOSは？
PHPもCで書かれてるの？
なんでC++で書かないの？
なんでC++で書かないの？
symfony言うほど遅い気はしないけどな。
前は確かに言うほど遅かった気がするが。
フレームワークとしてしっかり出来ているとは思う。
別に擁護するわけではないです。
前は確かに言うほど遅かった気がするが。
フレームワークとしてしっかり出来ているとは思う。
別に擁護するわけではないです。
C と C++ って，単純に「新しいしオブジェクト指向だから後者の方が良い言語」って話ではないからな……
Objective C だったらそう言えたんだろうか。知らんけど。
Objective C だったらそう言えたんだろうか。知らんけど。
>>83
Objective Cは動的型付け言語
Objective Cは動的型付け言語
agavi 0.11RC5リリース
>>86
うほ！！まだ更新してたんだｗ
うほ！！まだ更新してたんだｗ
frontend_devってそんなに遅いか！？
90 ：nobodyさん：2007/06/19(火) 23:12:36 ID:vt1ydhWm
xdebug有効にしてるとか
フランチョスが「symfony遅いって言う奴は馬鹿」ってわざわざ言うくらいだから
遅いって批判は結構あるんだろう
遅いって批判は結構あるんだろう
92 ：nobodyさん：2007/06/22(金) 10:24:23 ID:58srRoch
こんな本書いてる暇があったらDBレイヤ周りもっと完成度上げろや
94 ：nobodyさん：2007/06/22(金) 13:02:35 ID:58srRoch
>>93
PDO使えばいいじゃん
PDO使えばいいじゃん
俺Ethna+Syrupだけど
結構いいかんじ
結構いいかんじ
普通にcakeが出て欲しい
本なんて無くても使ってれば分かるだろｗ
98 ：nobodyさん：2007/06/23(土) 00:10:00 ID:nbx08fep
ZF希望
いや本にまとまると安心すんだよ、情報の漏れがないかとか。
あとやっぱ本が手に持てて見やすい。
あとやっぱ本が手に持てて見やすい。
うん、本があるほうがはかどることもあるよね。
wikiにまとまってた方がいいな。
本じゃキーワード検索できん
本じゃキーワード検索できん
そもそも、Ethna本、宣伝してる奴って、誰なんだ？
著者 出版関係者 狂信者
作者 書籍小売店 アフィリエイター
105 ：nobodyさん：2007/06/24(日) 17:30:26 ID:SHnW2+KS
>>102
俺だよ俺
俺だよ俺
>>105
胸がスッとしたぜ
胸がスッとしたぜ
やるじゃねえか
108 ：105：2007/06/24(日) 18:17:04 ID:SHnW2+KS
あぁ、、宣伝と取られたか。
俺自身、Ethnaってまだ使った事ないんだよね。
でも、本が発売されるって事で、ちょっとテンション上がって
ついつい貼っちゃったんだ。今後とも、自重するよ。
ちなみに俺はZendFrameworkに期待してる。
みんなごめんよ。本当にごめんにょ。
俺自身、Ethnaってまだ使った事ないんだよね。
でも、本が発売されるって事で、ちょっとテンション上がって
ついつい貼っちゃったんだ。今後とも、自重するよ。
ちなみに俺はZendFrameworkに期待してる。
みんなごめんよ。本当にごめんにょ。
109 ：105：2007/06/24(日) 18:18:51 ID:SHnW2+KS
うわ・・・ひどい日本語
Ethnaとか終わってます。
その本のvol.1がTurboGears X Pythonで、
vol.2がEthna x PHPという理由も良く分からん。
なんかのムックを単行本したのか？
ちなみになぜか俺vol.1買った。
内容は、まあページ数とサイズを考えれば
しゃーねーべ、、という感じ
Ethnaのほうは知らないが、そのページ数でPEAR , Smarty
PHPのインスコからMVCとは何か、認証まで言及してると
駆け足になりそうな予感。
でも本屋にあったら見てみるわ
vol.2がEthna x PHPという理由も良く分からん。
なんかのムックを単行本したのか？
ちなみになぜか俺vol.1買った。
内容は、まあページ数とサイズを考えれば
しゃーねーべ、、という感じ
Ethnaのほうは知らないが、そのページ数でPEAR , Smarty
PHPのインスコからMVCとは何か、認証まで言及してると
駆け足になりそうな予感。
でも本屋にあったら見てみるわ
>>92
いいなー、買おうかな。
いいなー、買おうかな。
113 ：nobodyさん：2007/06/25(月) 12:08:35 ID:2mWhEXtz
vol.2って何の事だと思ったら、vol.1はPythonだったのね。
需要あんのかな？
需要あんのかな？
「需要なさそうな所を突く解説書シリーズ Vol.2」なんじゃね
115 ：nobodyさん：2007/06/25(月) 18:41:08 ID:2mWhEXtz
CatalystならまだしもEthnaはないよな。
まぁ日本発で一番使われてるFWだからかな。
まぁ日本発で一番使われてるFWだからかな。
出版社同じだし、
http://7andy.yahoo.co.jp/books/detail?accd=31738344
のムックの売上見て単行本化決めたのではと思われ
なのでCatalystはありうる。そして次はMaple で最後にRoRだ。
わけわからん
http://7andy.yahoo.co.jp/books/detail?accd=31738344
のムックの売上見て単行本化決めたのではと思われ
なのでCatalystはありうる。そして次はMaple で最後にRoRだ。
わけわからん
Mapleとか。。
DjangoとPieceも...
120 ：nobodyさん：2007/06/25(月) 22:52:32 ID:2mWhEXtz
Mapleって開発譲渡したんじゃないの？
Mapleは開発放棄じゃないの？
てか開発者が行方不明とか？
違う人間がMapleのコードで違うプロジェクト始めたんじゃ？
どっちにしろ、終わってるな。
てか開発者が行方不明とか？
違う人間がMapleのコードで違うプロジェクト始めたんじゃ？
どっちにしろ、終わってるな。
作者に放棄→それを引き継ごうとした開発者も放棄
って流れだったと思う
二度捨てられた不憫な子＝Mapleたん
って流れだったと思う
二度捨てられた不憫な子＝Mapleたん
123 ：nobodyさん：2007/06/26(火) 12:41:14 ID:+m1wrnTY
・・・かわうそう
124 ：nobodyさん：2007/06/26(火) 13:03:43 ID:PKXMvhY5
フレームワーク使ったことない俺が言うのもなんだげど
PEARってフレームワークだよな？
PEARってフレームワークだよな？
zendは1.0なのにRC1,2,3とか
このままRC99まで行くつもりなのか！？
このままRC99まで行くつもりなのか！？
126 ：nobodyさん：2007/06/26(火) 14:34:55 ID:+m1wrnTY
>>124
lib
lib
>>124
PEAR は PHP のクラスライブラリを統合して統一的に扱うためのフレームワークだけど，
ここのスレでいうフレームワークって
「Web アプリケーション フレームワーク」に狭義に絞ってる気がするので
そういう意味では違うかもしれん．
PEAR は PHP のクラスライブラリを統合して統一的に扱うためのフレームワークだけど，
ここのスレでいうフレームワークって
「Web アプリケーション フレームワーク」に狭義に絞ってる気がするので
そういう意味では違うかもしれん．
129 ：nobodyさん：2007/06/27(水) 14:51:55 ID:54iUTIH0
Ethnaの本買ってきたぞ。
まだ、中身読んでないけど、今後のフレームワーク本の出版予定が書いてあったので、
一応知らせておく。gihyoから「Symfony×PHP」「Django×Python」が出る予定だそうだ。
Symfonyはいいにしても・・・Djangoって。
まだ、中身読んでないけど、今後のフレームワーク本の出版予定が書いてあったので、
一応知らせておく。gihyoから「Symfony×PHP」「Django×Python」が出る予定だそうだ。
Symfonyはいいにしても・・・Djangoって。
RailsやったことあるやつはCakeがおすすめ。
>ドジでのろまな亀
歳がばれるぞw
歳がばれるぞw
>>132
実の息子かもしれんぞ
実の息子かもしれんぞ
Cake使うならRails使ったほうがよいと思われ
>>134
その通りかもしれないがスレ違いによるループが確実
その通りかもしれないがスレ違いによるループが確実
Ethna本読んだが、結論から言うと買う必要なし。
ネットであれ以上の情報がすぐに手に入る。
本で読みたい人にはいいかも。
500円くらいの価値はある。
ネットであれ以上の情報がすぐに手に入る。
本で読みたい人にはいいかも。
500円くらいの価値はある。
137 ：nobodyさん：2007/06/28(木) 16:57:01 ID:b86P8EwS
漏れもいろいろ理由付けてRails使わないでいたけど、
1回使ったら陥落しますた。
今はお客さんの希望に合わせてRails > Symfony > Cake
という感じで、やってます。
1回使ったら陥落しますた。
今はお客さんの希望に合わせてRails > Symfony > Cake
という感じで、やってます。
140 ：nobodyさん：2007/06/28(木) 18:10:36 ID:b86P8EwS
たいしてめんどくさくもねえし。
Railsってrsyncでデプロイする機能があったような。
>>141
初級〜中級者には敷居高いと思うよ
初級〜中級者には敷居高いと思うよ
まぁたしかにPHP環境ほど簡単というわけじゃないですね。
サーバが全てDebianってわけじゃないですから。
サーバが全てDebianってわけじゃないですから。
＞初級〜中級者
の範囲がわからんけど、そういうのはFWを使うのがそもそも間違いでしょ
の範囲がわからんけど、そういうのはFWを使うのがそもそも間違いでしょ
上級者にしか使えないならほとんど使われてねぇよ
そんなこたーない
んなこたーないなんて言ってしまうと、世の中上級者ばかりになってしまう。
フレームワークは中級程度が一番使うべき。
初級者は使えないと思うが。
初級者は使えないと思うが。
フレームワークこそ初心者のもんだろ。
何やってるんだかわからないアホでも、それなりに組めてしまうんだから。
何やってるんだかわからないアホでも、それなりに組めてしまうんだから。
組めるレベルは中級っていうんじゃないのか。
個人の感覚の違いだから、それ以上はつっこまないが、言葉の表面じゃなく意味するとこを読み取ってほしいな。
個人の感覚の違いだから、それ以上はつっこまないが、言葉の表面じゃなく意味するとこを読み取ってほしいな。
初級とか中級とか絶対指標がないから掲示板の議論には向かない表現だなと思った
本心では「中級こそ使うべき」と思ってても
その中級を初級呼ばわりすることで
「そういう自分＝上級」感を味わいたい奴とかもいると思うんだ
本心では「中級こそ使うべき」と思ってても
その中級を初級呼ばわりすることで
「そういう自分＝上級」感を味わいたい奴とかもいると思うんだ
>>151
俺の基準だと
初級者：ちょっとだけできる（仕事でやるのはしんどいレベル。）
中級者：普通にできる（普通に仕事でやっていけるレベル。真ん中のグレード。）
上級者：何でもできる（周りのプログラマからすげーって言われるレベル。）
この基準だと、初級者はフレームワークなしじゃ、まともに動くものは何一つ作れない。
俺の基準だと
初級者：ちょっとだけできる（仕事でやるのはしんどいレベル。）
中級者：普通にできる（普通に仕事でやっていけるレベル。真ん中のグレード。）
上級者：何でもできる（周りのプログラマからすげーって言われるレベル。）
この基準だと、初級者はフレームワークなしじゃ、まともに動くものは何一つ作れない。
初級者にはMVCのアーキテクチャは理解できない
↓
理解せずに使うと必ずどっか壁にぶち当たる
↓
結局使えない
↓
理解せずに使うと必ずどっか壁にぶち当たる
↓
結局使えない
WebフレームワークってコントローラーとDB操作する部分とHTML表示する部分とを切り分けてるだけじゃん。
オブジェクト指向の理解なんて必要ない。
オブジェクト指向の理解なんて必要ない。
オブジェクト指向の話なんか出てない
158 ：nobodyさん：2007/06/29(金) 22:10:29 ID:u0ng+pVR
>>156
おまえこそ、オブジェクト指向わかってのかｗ
おまえこそ、オブジェクト指向わかってのかｗ
確かにな。純粋なオブジェクトで出来てないJAVAやPHPなどでオブジェクト指向は出来ないかも知れない。少なくともWebフレームワークはオブジェクト指向の理解はいらんな。
やはりRubyあたりがオブジェクト指向が語れる（実現できる）言語かな。
やはりRubyあたりがオブジェクト指向が語れる（実現できる）言語かな。
いやべつにそんな話題は出てないのにレス書いたバカがいるというだけの話だが
このスレはオブジェクト指向を語るスレになりました
俺のちんこは素敵なオブジェ
オブジェクト指向分からずしてフレームワークは使えない品
まあオレオレFW作ってるひとは当然OOPしてるんだろうな
既製のFW使うのに、クラスが何なのかくらいは知らんとムリだが
GoFだのなんだのって話になるわけでもあるまい
既製のFW使うのに、クラスが何なのかくらいは知らんとムリだが
GoFだのなんだのって話になるわけでもあるまい
166 ：nobodyさん：2007/07/01(日) 23:51:37 ID:KBDlHz5H
オレオレFW作れるだけまだ上等だろう
PHPでFWなんてそのうち時代遅れになるよ。
MyPHPAdminより高機能なDBオーサリングツールがついて
Flashみたいにオブジェクトをクリックして、プロパティの種類と名前追加して
自分でprotectedとかextendsとか何度も書かなくて良いようになる。
親クラスやインターフェースなんかを図でつなぐだけ。
FWみたいに実行環境でそのまま使われるモノではなくて
最適化したモノが書き出されるようになる。
編集するときはプロジェクトファイルで行うようになる。
フォームもドラッグアンドドロップでnameやaction指定して
typeを選ぶだけ。勿論DBと連動させられる。
マニュアルで記述もできる。
オブジェクトは、ECMAスクリプトと連動する事もできて、自由自在に
デスクトップGUIアプリのようにデザインすることも出来る。
来春発売で10万。
楽しみにしててくれ。
MyPHPAdminより高機能なDBオーサリングツールがついて
Flashみたいにオブジェクトをクリックして、プロパティの種類と名前追加して
自分でprotectedとかextendsとか何度も書かなくて良いようになる。
親クラスやインターフェースなんかを図でつなぐだけ。
FWみたいに実行環境でそのまま使われるモノではなくて
最適化したモノが書き出されるようになる。
編集するときはプロジェクトファイルで行うようになる。
フォームもドラッグアンドドロップでnameやaction指定して
typeを選ぶだけ。勿論DBと連動させられる。
マニュアルで記述もできる。
オブジェクトは、ECMAスクリプトと連動する事もできて、自由自在に
デスクトップGUIアプリのようにデザインすることも出来る。
来春発売で10万。
楽しみにしててくれ。
Delphyか。
Java系のIDEでもFlex BuilderでもVS.NETでも既にやってるし、いまさら自慢気に言うほどのものでもないよね。
>>167 もうでてるじゃん。 Delphi for PHP
先生質問！
いつも1人でｵﾚｵﾚFW使ってるんだが、ちょっと人と並行して作業する事になって、
さすがにｵﾚのじゃ申し訳ないって思ってるところ。
初見ではCakePHPかCodeIgniterが良さそうな印象なんだけど、
実際の使用感とか感想とかあったら参考にさせて欲しい〜、お願いします。
いつも1人でｵﾚｵﾚFW使ってるんだが、ちょっと人と並行して作業する事になって、
さすがにｵﾚのじゃ申し訳ないって思ってるところ。
初見ではCakePHPかCodeIgniterが良さそうな印象なんだけど、
実際の使用感とか感想とかあったら参考にさせて欲しい〜、お願いします。
オマイが決めていいんならオレオレでもいいんじゃね？
怠惰なやつにただで情報与えるのは気が進まないが、他の人の参考にもなるかもしれないから俺の使用感をメモっておく。
Cakeはデータベースとのアソシエーションが覚えるとやはり便利。外部ライブラリと併用すれば十分使える。実績も出てきた。
CIは、そのアソシエーションを削ることでよりシンプルにした感じ。Cake同様に他の機能も十分なので、FWとして合格点。
Cakeはデータベースとのアソシエーションが覚えるとやはり便利。外部ライブラリと併用すれば十分使える。実績も出てきた。
CIは、そのアソシエーションを削ることでよりシンプルにした感じ。Cake同様に他の機能も十分なので、FWとして合格点。
>>173
そんな情報いらないよ(w
そんな情報いらないよ(w
>>173
俺FWはSymfonyしか使ったことないんだけど、DBからデータ持ってくるのは
やっぱりSQL文直書きしちゃうなぁ・・・。
SQL書かないと、後で見たときすごい解りにくくない？
でも、SQL文がPHP内に混じるとやっぱり汚いね。
PHP版S2Daoの、2way SQLが良さそうなんだけど、時間ないのでまだ見れてない。
includeするファイルが多くなり過ぎて、Symfonyと併せるとすっごい遅くなりそうな気もする。
そうなると、CIと組み合わせた方が良いのかな？
俺FWはSymfonyしか使ったことないんだけど、DBからデータ持ってくるのは
やっぱりSQL文直書きしちゃうなぁ・・・。
SQL書かないと、後で見たときすごい解りにくくない？
でも、SQL文がPHP内に混じるとやっぱり汚いね。
PHP版S2Daoの、2way SQLが良さそうなんだけど、時間ないのでまだ見れてない。
includeするファイルが多くなり過ぎて、Symfonyと併せるとすっごい遅くなりそうな気もする。
そうなると、CIと組み合わせた方が良いのかな？
ちょっとややこしくなると、結局同じようにややこしかったりするし、
SQL自体がそもそも簡便に抽象化されたものとしてあるんだから、
プレースホルダを使ったりするくらいでも別にいいよな。
SQL自体がそもそも簡便に抽象化されたものとしてあるんだから、
プレースホルダを使ったりするくらいでも別にいいよな。
同意。
無駄にプァイル多くなるし。
あとから参照しずらい。
無駄にプァイル多くなるし。
あとから参照しずらい。
まあCIのactive recordは使い物にならんから、SQLガチガチ書きたい奴はある意味お勧め。
>>178のカキコも使いもんにならんから目を汚したいヤツには違う意味でお勧め。
情報出さないで文句ばっかいってる生産性のないやつがいるな。
>>175
Symfonyは使ったことないけど、Cakeの方がシンプルだということだからもっとみやすいんじゃない？
Cakeは慣れれば、一目見ただけでどんなデータとってきてるか分かるよ。
SQL文書くならRailsを模倣してるSymfonyとかCakeとか使わないで違うＦＷ使うべきなんじゃないかと思うけど。
>>175
Symfonyは使ったことないけど、Cakeの方がシンプルだということだからもっとみやすいんじゃない？
Cakeは慣れれば、一目見ただけでどんなデータとってきてるか分かるよ。
SQL文書くならRailsを模倣してるSymfonyとかCakeとか使わないで違うＦＷ使うべきなんじゃないかと思うけど。
Cakeとsymfonyやったらどっちのほうが覚えやすい？
railsはDB操作レイヤーといえばORMというような、間違った風潮を作ったね。
一見コード量から言えばCakeの方が「覚えやす」そうだけど、
symfonyの方が業務にすぐ使えるだろうね。
「覚える」ことは必要ないし。マニュアルにしたがってサクサクという感じで進むよ。
それと引き換えに「退屈さ」に耐えなければならない、という感じ。
横道にそれながらも楽しんで仕事したいならCake。
symfonyの方が業務にすぐ使えるだろうね。
「覚える」ことは必要ないし。マニュアルにしたがってサクサクという感じで進むよ。
それと引き換えに「退屈さ」に耐えなければならない、という感じ。
横道にそれながらも楽しんで仕事したいならCake。
>>181 業務ならCake 趣味ならSymfony (Cakeは4,5対応ということだけで、別に悪意はないから)
185 ：nobodyさん：2007/07/04(水) 17:50:11 ID:PWYSy+4p
退屈な方がいいよね
ああ、そう思う。仕事はそういうもんだな。
精度なんか落ちてないぞ。4と5に対応できるようにコードを裏側で切り替えてるだけ。
普通に優れてる
普通に優れてる
>>187
精度って何の精度？
精度って何の精度？
業務でSymfony使えばいいじゃない。 使いたい人は・・・。
むしろsymfonyが趣味にしか使えないというところに、突っ込むべきかと。
ありえんだろ。
ありえんだろ。
symfonyは趣味にはキツいな。どんなマゾやねん
〉189
性能といいたいのだと思われ
性能といいたいのだと思われ
趣味でやるなら、cakeかEthna。
仕事はsymfony。
仕事ならサーバー構築からできるからphp5を選択できるけど、趣味だと安いサーバーを借りたりするので
php4で動くやつの方がいい。
仕事はsymfony。
仕事ならサーバー構築からできるからphp5を選択できるけど、趣味だと安いサーバーを借りたりするので
php4で動くやつの方がいい。
>>194 のような趣味のような仕事をしてみたい。
196 ：nobodyさん：2007/07/07(土) 05:07:04 ID:1nTQ87n9
まず趣味で色々使ってみる。
そして自分なりのFAを出す。
それを仕事の現場で推薦する。
通らないこともあるが自分はこうしてる。
「2chで支持されてたので、これ使います。」
じゃまずいだろ。ｗ
そして自分なりのFAを出す。
それを仕事の現場で推薦する。
通らないこともあるが自分はこうしてる。
「2chで支持されてたので、これ使います。」
じゃまずいだろ。ｗ
http://www.symfony-project.com/weblog/2007/07/06/php4-is-dead-long-live-php5.html
ﾌﾗﾝﾁｮｽ「PHP4 is dead! いまどきPHP4にも対応してる中途半端なCakeはﾌﾟｷﾞｬｰものだ」
ﾌﾗﾝﾁｮｽ「PHP4 is dead! いまどきPHP4にも対応してる中途半端なCakeはﾌﾟｷﾞｬｰものだ」
正直、symfonyは機能をあれこれ盛り込んでるから
そこそこ利用出来るようになるまで時間が掛かりすぎる & ソースが見難い。
そこそこ利用出来るようになるまで時間が掛かりすぎる & ソースが見難い。
>>198
よくそういう意見を聞くけど、まずは自分が使いたいと思う機能だけ
使っていけば、複雑でも何でもないんじゃないかと思うんだが、どう？
ソースについても、Cakeの方が汚いと聞いた事はあるが、確認はしてないなぁ。
あ、見難いと汚いは違うか？
よくそういう意見を聞くけど、まずは自分が使いたいと思う機能だけ
使っていけば、複雑でも何でもないんじゃないかと思うんだが、どう？
ソースについても、Cakeの方が汚いと聞いた事はあるが、確認はしてないなぁ。
あ、見難いと汚いは違うか？
うん、むしろ、なにも考えずに使えてしまうよ。
symfonyに実装されてる機能を「そこそこ利用できる」学習する時間
＜Cake（とかCIとかライトウエイトのＦＷ）を使って自作点検する時間
って感じだから、symfonyは「退屈」なのよ。でもそれくらいならsymfony
よりは今後はＺＦ使いたい気がする。
symfonyに実装されてる機能を「そこそこ利用できる」学習する時間
＜Cake（とかCIとかライトウエイトのＦＷ）を使って自作点検する時間
って感じだから、symfonyは「退屈」なのよ。でもそれくらいならsymfony
よりは今後はＺＦ使いたい気がする。
ZFはあんだけ時間かけてあのザマだからなあ
ん、ZFわるくないじゃん。機能もそろってるし。
どこが「あのザマ」なの？
どこが「あのザマ」なの？
ZFがJAVAライクなフレームワークになってるのも分からず、叩きたがってる中二病なので、ご勘弁ください。
ZFはフレームワークって言うより
ライブラリ感が強いから
自前で用意しなきゃいけないことが多い
ソースは読みやすい
ライブラリ感が強いから
自前で用意しなきゃいけないことが多い
ソースは読みやすい
symfonyあたりからZF見て足らないっていう部分が、
本当にＦＷの必須要素なのかが疑問だけどね。
本当にＦＷの必須要素なのかが疑問だけどね。
別にsymfonyを叩きたいわけじゃないがsymfony信者多いな
PHP4って今でも多くのサイトで使われてるだろ。
PHP5はメモリを食いすぎるからね。
シンフォニーみたいな高機能なフレームワークはエクステンション化しないと実用的でないね。
PHP5はメモリを食いすぎるからね。
シンフォニーみたいな高機能なフレームワークはエクステンション化しないと実用的でないね。
> PHP5はメモリを食いすぎるからね。
具体的な数字希望
具体的な数字希望
海外国内問わずPHP4互換のFW未だにアップデートし続ける
FWの作者に告ぐ、はっきり言って老害だ、とっとと辞めてくれ
少しでもPHPの未来を考える気があるなら
そのサポート対象から4を切れ、今すぐに
そしてその4互換FWで未だに4のコードを書きつづけるユーザの人達、
4のコードでそのFWの使い方やサンプルをブログに書きつづける人達、
5のサポートをしないレンタルサーバ管理者の人達、
どうか心改めこれから5をインストールして5のコードを書くか
PHPを捨て去るかどちらかを選択して欲しい
これ以上4のコードを生産するべきではない
これ以上4のコードを書く人間を生産するべきではない
これ以上4のコードを書く人間を放置していてはいけない
PHPユーザは尊厳の意をもって4を葬り去るべき
FWの作者に告ぐ、はっきり言って老害だ、とっとと辞めてくれ
少しでもPHPの未来を考える気があるなら
そのサポート対象から4を切れ、今すぐに
そしてその4互換FWで未だに4のコードを書きつづけるユーザの人達、
4のコードでそのFWの使い方やサンプルをブログに書きつづける人達、
5のサポートをしないレンタルサーバ管理者の人達、
どうか心改めこれから5をインストールして5のコードを書くか
PHPを捨て去るかどちらかを選択して欲しい
これ以上4のコードを生産するべきではない
これ以上4のコードを書く人間を生産するべきではない
これ以上4のコードを書く人間を放置していてはいけない
PHPユーザは尊厳の意をもって4を葬り去るべき
仕事であの中途半端なオブジェクト指向をさわりたくない。
212 ：nobodyさん：2007/07/07(土) 16:45:01 ID:ORHn68Tc
PHP5は最近レンサバでも入ってるよ。
ってか、最近は最悪でもVPS以上を使わせることにしてる。
ってか、最近は最悪でもVPS以上を使わせることにしてる。
213 ：nobodyさん：2007/07/07(土) 22:00:26 ID:9N+o65yz
最近symfony使い始めて、掲示板なんか試しにつくってみたけどさ、
設定ファイルでだいたいの調整ができるから、実際のビジネスに使う
には、結構いいんでは？
ビジネスでは、スピードよりも保守性が重んじられることも多いから…。
設定ファイルでだいたいの調整ができるから、実際のビジネスに使う
には、結構いいんでは？
ビジネスでは、スピードよりも保守性が重んじられることも多いから…。
そうね。
何年も保守していくことを考えると、今さらphp4 てどうだろう。。
ていうか数年先にphpはどうなっているんだろうか。
何年も保守していくことを考えると、今さらphp4 てどうだろう。。
ていうか数年先にphpはどうなっているんだろうか。
php6でまた仕様が変わってうんざりしてrubyに
ruby 2 で仕様が変わってうんざりして pythonに
一方perlはのんびりと静かに暮らしていた
209の駄文にワラタ(笑)
PHP4 is dead, long live PHP5!
次のPHPにレキシカル変数、パッケージが導入されない限り、軽いPHP4で十分だな。
php4が軽いとか思ってる奴まだ居たんだ…
軽いPHP4で十分だよ！
>>222
php4が軽いとか思ってるのではなく、軽いPHP4で十分なのではないか？
php4が軽いとか思ってるのではなく、軽いPHP4で十分なのではないか？
じゃあ軽いPHP5でいいじゃん
>>208
ペチパーは自分で調べることが出来ないのかねえ。
↓これでPHP4と5で計ってみろ。
ps -eo vsz,command | grep httpd | awk '{sum+=$1}END{print sum}'
PHP5はこのでっぷり太ったプロセスでHTMLも画像も処理しないといけないんだ。
もっともYahooみたいにモジュールを全部外してコンパイルすれば4も5もそんなに違わないのかも。
が、ビジネスロジックをエクステンションに任せるというのは極めて例外的なPHPの使い方だから参考にならないな。
ペチパーは自分で調べることが出来ないのかねえ。
↓これでPHP4と5で計ってみろ。
ps -eo vsz,command | grep httpd | awk '{sum+=$1}END{print sum}'
PHP5はこのでっぷり太ったプロセスでHTMLも画像も処理しないといけないんだ。
もっともYahooみたいにモジュールを全部外してコンパイルすれば4も5もそんなに違わないのかも。
が、ビジネスロジックをエクステンションに任せるというのは極めて例外的なPHPの使い方だから参考にならないな。
おまえら4と5の負荷の差がボトルネックに感じる程の
WEBアプリを作ってんのかと小一時間問い詰めたい
例外処理とマジックメソッド使えるだけでも
どれだけ開発が楽になって生産性上がると思ってんだよ
微々たるPHPのバージョン差の負荷とか考える前に
自分が開発するためのフットワークを
軽くすることを先に考えるのがプログラマだろうが
WEBアプリを作ってんのかと小一時間問い詰めたい
例外処理とマジックメソッド使えるだけでも
どれだけ開発が楽になって生産性上がると思ってんだよ
微々たるPHPのバージョン差の負荷とか考える前に
自分が開発するためのフットワークを
軽くすることを先に考えるのがプログラマだろうが
富豪的発想が主流になるのはまだまだ先ってことだね。
目の前の負荷を軽くすることが優先されて、
それに割く労力を別の改良に振れるのに気づけない。
目の前の負荷を軽くすることが優先されて、
それに割く労力を別の改良に振れるのに気づけない。
ウェブアプリが複雑であるかそうでないかは関係ないよ。静的なHTMLでも画像でも同じこと。同じApacheを使うんだから。
むろんJavaのコンテナやfastcgiのように独立したアプリケーションサーバを用意して、ウェブサーバと分離できればいいんだが、そのコストがPHP5導入のメリットに見合わないつーこと。
バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。
それは、確かにVistaには目新しい機能があるが、重くてバギーだし、XPは安定していて困ることはないよ。っていうのと似たような話。
むろんJavaのコンテナやfastcgiのように独立したアプリケーションサーバを用意して、ウェブサーバと分離できればいいんだが、そのコストがPHP5導入のメリットに見合わないつーこと。
バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。
それは、確かにVistaには目新しい機能があるが、重くてバギーだし、XPは安定していて困ることはないよ。っていうのと似たような話。
パーソナルユースのOS話しと業務ベースのPHP導入の話しとを一緒にしてるってのが輪をかけてバカ
> バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。
すごーーく単純な理由で、
ひとつのapacheで共存できないから。
重いから5にしないって話はほとんど（皆無ではない）聞かないね……
すごーーく単純な理由で、
ひとつのapacheで共存できないから。
重いから5にしないって話はほとんど（皆無ではない）聞かないね……
PHP4 is dead ＝ PHP is dead
ｵ､ｵ、ｵﾜﾀｰｵﾜｵﾜｵﾜﾀｰ♪
＼ PHP is 全部 dead♪／
♪＼(^o^) ♪
＿ ) > ＿ ｷｭｯｷｭ♪
／.◎。／◎｡／|
＼(^o^)／.|￣￣￣￣￣| | ＼(^o^)／
) ) .| |／ ノ ノ
(((( >￣ > )))) ＼(^o^)／ ((( <￣< ))))
) )
((( >￣ > ))))
ｵ､ｵ、ｵﾜﾀｰｵﾜｵﾜｵﾜﾀｰ♪
＼ PHP is 全部 dead♪／
♪＼(^o^) ♪
＿ ) > ＿ ｷｭｯｷｭ♪
／.◎。／◎｡／|
＼(^o^)／.|￣￣￣￣￣| | ＼(^o^)／
) ) .| |／ ノ ノ
(((( >￣ > )))) ＼(^o^)／ ((( <￣< ))))
) )
((( >￣ > ))))
＞PHP5への移行が進まない
そもそも、これがどれだけ説得力を持つはなしなのかね。
個人レベルのPHPサイトとかが多いからそうなってるだけだろ。
業務ベースなら、新規は５が当然。既にあるやつもそれなりにリニューアルするなら５で
動かすようにリファクタかけるよ。
そもそも、これがどれだけ説得力を持つはなしなのかね。
個人レベルのPHPサイトとかが多いからそうなってるだけだろ。
業務ベースなら、新規は５が当然。既にあるやつもそれなりにリニューアルするなら５で
動かすようにリファクタかけるよ。
PHP4脂肪→
オブジェクト指向が理解できない大多数のプログラマ（PHPerの80％）の離脱→
PHP脂肪
オブジェクト指向が理解できない大多数のプログラマ（PHPerの80％）の離脱→
PHP脂肪
drupal使ってるやついねーのかな
結構色々できると思うんだけど
結構色々できると思うんだけど
drupalはフレームワークなわけ？
何が魅力なの？
Webページつくるだけなら違うcmsあるし、Webサービスつくるなら足りないだろ？
何が魅力なの？
Webページつくるだけなら違うcmsあるし、Webサービスつくるなら足りないだろ？
http://en.wikipedia.org/wiki/Drupal
にweb application frameworkって書かれてるよ
魅力はより少ない手間で作れたり、
高負荷のサイトで使われてたり、他のCMSより拡張性が高かったり。
cckとか色々モジュールがあるし、足りなければモジュールを作って拡張できるから
よっぽど複雑なことをするのでない限り、
大抵のことはdrupalでもできると思うんだが
Webサービスとかはできるかどうかわからないから、「結構」って表現にしたんだけど。
完璧じゃなくても、ほとんどの場合に十分使えればいいんじゃないかと
にweb application frameworkって書かれてるよ
魅力はより少ない手間で作れたり、
高負荷のサイトで使われてたり、他のCMSより拡張性が高かったり。
cckとか色々モジュールがあるし、足りなければモジュールを作って拡張できるから
よっぽど複雑なことをするのでない限り、
大抵のことはdrupalでもできると思うんだが
Webサービスとかはできるかどうかわからないから、「結構」って表現にしたんだけど。
完璧じゃなくても、ほとんどの場合に十分使えればいいんじゃないかと
すれ違い、それいっちゃ、XOOPSだって、フレームワークだろ。
ＣＭＳがMVC意識せずにどんどん肥大化していく中で、今で言うフレーム
ワークが展開していったっていう時間の流れだよ。自分はDrupalはその
最中に出てきた「スマート」なＣＭＳ奴で、XOOPSは一時代前のカオスCMS
っていう押さえをしてる。
ワークが展開していったっていう時間の流れだよ。自分はDrupalはその
最中に出てきた「スマート」なＣＭＳ奴で、XOOPSは一時代前のカオスCMS
っていう押さえをしてる。
243 ：nobodyさん：2007/07/09(月) 20:20:17 ID:sJXKqrgb
共存なんか大した手間じゃない。
まあriverse proxyとか含めればいくらでも出来るからなあ。
大した手間かけずに共存環境に移行できるサービスばかりだったらそれでよかったんだろうさ
？言ってる意味がわからん
CMSなんか使ってるやつはくず。
コード気にする価値なし。
コード気にする価値なし。
249はよくいるような「皆が使ってるものを否定する自分ｶｺｲｲ」なお子様に見えなくもないが
重厚長大なフルセットCMSって今もうそういう対象でもないよな
重厚長大なフルセットCMSって今もうそういう対象でもないよな
どのFWもプレゼンテーション層がお粗末なのがどうもなぁ。
Smartyとかデザイナにしてみたらえらい負担だろうし。
もっと連携のしやすいものがあればいいんだけど。
Smartyとかデザイナにしてみたらえらい負担だろうし。
もっと連携のしやすいものがあればいいんだけど。
今日びＰＨＰもできないデザイナーは死滅したらいいよ
>>253
お前がな
お前がな
うむ。今更感の漂う話題ではあるが
俺もついでに今更感の漂う話を投下しとくか
おまいら、CMSが好きならZope + Ploneが最強じゃね？
俺もついでに今更感の漂う話を投下しとくか
おまいら、CMSが好きならZope + Ploneが最強じゃね？
PHP4サポート打ち切りって影響甚大じゃね？
稼動してるサイトは膨大で
そのうちPHP5に移行できるのはどれだけあるのか？
サイバーテロが吹き荒れそう
稼動してるサイトは膨大で
そのうちPHP5に移行できるのはどれだけあるのか？
サイバーテロが吹き荒れそう
正直遅いぐらい
ようやく4排除への大義名分を得られるわけだ
ようやく4排除への大義名分を得られるわけだ
これで4しか入ってなかったレンサバも5に切り替わるといいな。
今PHP3で走ってるサイトってどのくらいあるのかな
4から5のリプレースがうまくいかなかったのを教訓に
6は5と共存できるような仕組みが欲しいところだな
6は5と共存できるような仕組みが欲しいところだな
「仕様が完全上位互換」とかじゃダメなんだよな
共存させたい環境のひとは新環境での再テストとかもしたくないだろうし
共存させたい環境のひとは新環境での再テストとかもしたくないだろうし
そもそもそのテスト費用が出して貰えないから困るわけで。
263 ：nobodyさん：2007/07/16(月) 23:55:55 ID:jJDluNIm
皆さん地震大丈夫ですか？
NTTの災害用ブロードバンド伝言板（web171）はPHPなんだね。
不謹慎かもしれないけど、ちょっと嬉しい…。
NTTの災害用ブロードバンド伝言板（web171）はPHPなんだね。
不謹慎かもしれないけど、ちょっと嬉しい…。
そうかな? PHPだと大規模災害時とかでロードが大きくなったときに
ホイホイとスケールできるのかちょっと心配な気が...
ホイホイとスケールできるのかちょっと心配な気が...
スケールできるよPHP
サーバ、ネットワーク周りの改善でなんとでもなる。
もっと直感的に使える高機能な独自タグってことだろ。MTみたいな感じじゃないか？
>>251が曖昧で分からないが
連携に関しては基本デザイナに埋め込みさせなきゃいいと思うんだが
連携に関しては基本デザイナに埋め込みさせなきゃいいと思うんだが
そんな事いってるから日本のPHPサイトは手抜きデザインばっかりなんだが
>>270
なんでそうなるんだよｗ
デザイン→HTMLコーディングまでデザイナ側で落とし込んで
PHPの埋め込みだけプログラマがやればって話なのに
「そんな事いってるから」の後になんで手抜きデザイン？
なんでそうなるんだよｗ
デザイン→HTMLコーディングまでデザイナ側で落とし込んで
PHPの埋め込みだけプログラマがやればって話なのに
「そんな事いってるから」の後になんで手抜きデザイン？
あとで修正はいったらどうすんの？
適時対応
静的部分だけの修正でデザイナだけで
修正できるようであればデザイナが修正
修正箇所に動的な部分を含んで
埋め込みコードの修正も伴うのであればプログラマが修正
で、なんか困ることある？
静的部分だけの修正でデザイナだけで
修正できるようであればデザイナが修正
修正箇所に動的な部分を含んで
埋め込みコードの修正も伴うのであればプログラマが修正
で、なんか困ることある？
結局デザイナーっていらないね
状況から真っ当な結論を導き出すのが極端に下手な奴がいるな
まともにデザイナと連携して仕事したことないんだろうな
277 ：nobodyさん：2007/07/18(水) 16:25:07 ID:3R7D5ath
SmartyのかわりにPHPTALとかじゃだめなの？
デザイナーと仕事するのが偉いと勘違いしてるやつがぽつぽつ
自分が一番偉いんだと勘違いしてるやつが・・・
コーダーでPGもこなす俺が真の勝ち組。
デザイナにはデザイン画像だけ描いてもらえばおｋ。
HTML起こすのは自分でできるもん♪
デザイナにはデザイン画像だけ描いてもらえばおｋ。
HTML起こすのは自分でできるもん♪
281 ：nobodyさん：2007/07/18(水) 18:45:26 ID:sJyKZns/
全部一人でやれる奴が最強な訳で・・・
実際ヘタな紙デザイナに変なHTML書かせるより
画像だけ描いてもらってHTMLに起こすのはプログラマがやった方が
結果としてキレイなものが出来上がる気がする
画像だけ描いてもらってHTMLに起こすのはプログラマがやった方が
結果としてキレイなものが出来上がる気がする
ズレてきてるな
どう役割分担して連携するかって話だろ
誰が偉いとかおまえらのHTMLコーダー自慢とかはどうでもいいよ
どう役割分担して連携するかって話だろ
誰が偉いとかおまえらのHTMLコーダー自慢とかはどうでもいいよ
読みこみファイル数がすごい数になってるんだけど
アクセラレータつこうたら大丈夫？
お前らどうしてますか？
アクセラレータつこうたら大丈夫？
お前らどうしてますか？
>>284
まずコードを見直す
まずコードを見直す
286 ：nobodyさん：2007/07/19(木) 14:46:00 ID:Qs6wUD6U
>>284
主要フレームワークってeaダメだよね？
主要フレームワークってeaダメだよね？
cakeはいけてますが
なんでeaってダメなの?
xcacheならOK?
xcacheならOK?
異常動作することがあるらしいね>ea
アクセラレータのスレにあったはず
別にフレームワークは関係ないと思うが
アクセラレータのスレにあったはず
別にフレームワークは関係ないと思うが
>>285
フレームワーク自体がファイル読みこみまくりだからコード見直しても意味ない
hello,worldですらファイルが数十個読まれる
つまりフレームワーク使うのは阿呆
ついでにいえばウェブプログラムごときでオブジェクト指向使うやつも阿呆
フレームワーク自体がファイル読みこみまくりだからコード見直しても意味ない
hello,worldですらファイルが数十個読まれる
つまりフレームワーク使うのは阿呆
ついでにいえばウェブプログラムごときでオブジェクト指向使うやつも阿呆
とオブジェクト指向が理解できない阿呆が申しております。
292 ：nobodyさん：2007/07/20(金) 09:49:57 ID:xk3U0lu8
protectedな変数持ってるとEA動きません。
まじで？
俺オワタ＼(^o^)／
俺オワタ＼(^o^)／
本当に必要なファイル読み込みなのかどうかコードを見直せ。
ＦＷ側で不要なインスタンスを発行しまくっているようなら、
それをコロすように継承自前クラスで上書き。
ＦＷって結局汎用だから、MVCの過程で、余分な処理をしてることが往々にしてある。
次に、ページキャッシュを考えろ。キャッシュ処理可能ページとそうでないページの
振り分けをちゃんとできるようにコードを見直す。
アクセとかハードウエア性能向上という手がつかえないなら、それしかないだろう。
ＦＷ側で不要なインスタンスを発行しまくっているようなら、
それをコロすように継承自前クラスで上書き。
ＦＷって結局汎用だから、MVCの過程で、余分な処理をしてることが往々にしてある。
次に、ページキャッシュを考えろ。キャッシュ処理可能ページとそうでないページの
振り分けをちゃんとできるようにコードを見直す。
アクセとかハードウエア性能向上という手がつかえないなら、それしかないだろう。
気にしないのが一番
inodeは上限あるけど
オープンできるファイルに上限てあんの？
オープンできるファイルに上限てあんの？
少なくともlinux, bsdにはある
windowsは知らん
windowsは知らん
>>292
いつの話よ？ 0.9.5.1 では直ってる。
いつの話よ？ 0.9.5.1 では直ってる。
299 ：nobodyさん：2007/07/20(金) 21:35:41 ID:g4/DmFJL
だいたいPHPはバギーすぎるんだよ。何、PHP5は安定しているので、PHP4は開発中止？こっちはキムチパッチ当ててる所だ。
>>299
それは使い物にならんな・・・
それは使い物にならんな・・・
オプチマイザなんてたいした効果もないんだからオフでおk
ポン入れでまもとに使えない時点でアウト。
たまに案件でphp.iniをグチャグチャいじってさらにPHP_VALUEまでいじってるあるのに遭遇するが、
開発サーバで再現しきれん設定とかがあってむかつく。
たまに案件でphp.iniをグチャグチャいじってさらにPHP_VALUEまでいじってるあるのに遭遇するが、
開発サーバで再現しきれん設定とかがあってむかつく。
アウトならこんなところまで来てネガってないで他の言語使えばいいじゃん……
何がしたいんだ？
再現しきれんってのは「設定できる場所を自分が把握できてない」って意味なだけだろ？
何がしたいんだ？
再現しきれんってのは「設定できる場所を自分が把握できてない」って意味なだけだろ？
O/Rマッパって何のためにあるんだ？
返り値がオブジェクトの配列である必要性がねーだろ
普通の連想配列で何の問題もない
返り値がオブジェクトの配列である必要性がねーだろ
普通の連想配列で何の問題もない
ＯＯＰのためにマッパが作られてるんだけどね。
何の問題もないなら使わなきゃいい
まあそれをわざわざここに書いてる事自体
「なんでO/Rマッパがいいのかわかりません」
って書いてるようなもんなんだけどねｗ
まあそれをわざわざここに書いてる事自体
「なんでO/Rマッパがいいのかわかりません」
って書いてるようなもんなんだけどねｗ
Oは、おぶじぇくとのおー
そういやFWのスレだったｗ
ヘルパーってかっこつけて言ってるけど単なる関数なんだな
本来viewのものなのに
グローバルスコープにあるのもダサいことこの上なし
本来viewのものなのに
グローバルスコープにあるのもダサいことこの上なし
オーバーライドできないのもまたビッチなり
それはおれも思った
ただのグローバルスコープにある関数がいつのまにヘルパなんて呼ばれて美化されてんだ，ってｗ
変数は view 展開時のみグローバルスコープに登録されるものが多いようだから
関数もそうするようになってるフレームワークがあってもいいように思うが
パフォーマンスとか色々の面で現実的じゃなさそうかな……
ただのグローバルスコープにある関数がいつのまにヘルパなんて呼ばれて美化されてんだ，ってｗ
変数は view 展開時のみグローバルスコープに登録されるものが多いようだから
関数もそうするようになってるフレームワークがあってもいいように思うが
パフォーマンスとか色々の面で現実的じゃなさそうかな……
CakePHPとかsymfonyのヘルパーってクラスじゃなかったっけ
rubyみたいにレシーバが省略できないから
railsのviewライクに使えるよう突き詰めた結果がああなったと思われる
まあ早い話が$this書きたくないっていうことだな
俺もview helperとはいえ単なるfunctionにするのは好みじゃないな
ZFのview helperはクラス（オブジェクト）になっている
view helperがfunctionになってるのはsymfonyだっけ？他にもあるかな
railsのviewライクに使えるよう突き詰めた結果がああなったと思われる
まあ早い話が$this書きたくないっていうことだな
俺もview helperとはいえ単なるfunctionにするのは好みじゃないな
ZFのview helperはクラス（オブジェクト）になっている
view helperがfunctionになってるのはsymfonyだっけ？他にもあるかな
>>318
cakeは見たことないけどsymfonyは関数だった
cakeは見たことないけどsymfonyは関数だった
あ、symfonyはfunctionか。ごめん
cakeはクラス。CIは関数
関数使うFWでも
読むファイル指定してるだけだからstaticなクラス書いてもいいけどね
読むファイル指定してるだけだからstaticなクラス書いてもいいけどね
staticなクラスにしちゃうと今度は使う時名前が長くなるんだよ
phpのどうしようもないところｗ
phpのどうしようもないところｗ
でも俺はstaticなクラス作って書いてる。
後から一括置換なんかも便利だし。
後から一括置換なんかも便利だし。
俺は関数でもいいと思う派だけど、
関数の場合、初めから用意されてるヘルパーがFW側に置いてあるのはどうかと思う。
コマンドでアプリケーションのディレクトリ構造を展開したときに、アプリ側に展開して欲しい。
クラスにした方がいいと思ったらクラスを作る。libなイメージ。
関数の場合、初めから用意されてるヘルパーがFW側に置いてあるのはどうかと思う。
コマンドでアプリケーションのディレクトリ構造を展開したときに、アプリ側に展開して欲しい。
クラスにした方がいいと思ったらクラスを作る。libなイメージ。
staticクラスで、ヘルパー関数を一旦ラップするのをお勧めする
viewにview helperがmixinされるような形のが一番いいよ
$thisを書くのは必要経費で
$thisを書くのは必要経費で
うーんmixinかー
メソッド名が元のviewと被ったら？
メソッド名が元のviewと被ったら？
unit test時にわかるでしょ
>>327
意図は？
staticクラスというのはstaticメソッド群からなるクラスのことだと思うが、
staticメソッドでラップしても関数を関数でラップするのと変わらない。
クラスの(static)プロパティも使用しいくつかのヘルパー関数群を
関連するものとして扱うなら、それはstaticよりもインスタンスにして
投げるインスタンスで振る舞いを変えられるようにしたほうが意味があると思うのだが。
意図は？
staticクラスというのはstaticメソッド群からなるクラスのことだと思うが、
staticメソッドでラップしても関数を関数でラップするのと変わらない。
クラスの(static)プロパティも使用しいくつかのヘルパー関数群を
関連するものとして扱うなら、それはstaticよりもインスタンスにして
投げるインスタンスで振る舞いを変えられるようにしたほうが意味があると思うのだが。
そこまでやるなら、既存のヘルパ関数なんかそもそも使わん。ヘルパー用クラスを
書くよ。保守を考えてstaticにするのは同一関数（メソッド）名で、とりあえずヘルパ使ってるってことを
明示しつつ拡張するため。関数を同一関数名でラップすることは出来ないからね。
書くよ。保守を考えてstaticにするのは同一関数（メソッド）名で、とりあえずヘルパ使ってるってことを
明示しつつ拡張するため。関数を同一関数名でラップすることは出来ないからね。
333 ：nobodyさん：2007/07/22(日) 19:18:21 ID:3PPkob3E
単にネームスペースの代わりだね。俺もやるよ。
まあFW側で直接定義されてるfunctionじゃな
オーバーライドすらできんしな、FWのソースを書き換えとか御免だ
ラッパーがstatic/dynamicどっちがいいとかは抜きにして
ラップして使う事自体に意味はちゃんとある
オーバーライドすらできんしな、FWのソースを書き換えとか御免だ
ラッパーがstatic/dynamicどっちがいいとかは抜きにして
ラップして使う事自体に意味はちゃんとある
関数だとどこで定義されているか、わかりにくいしねえ。
うん、grepすりゃいいからそれは別に困らないがｗ
関数ヘルパでも接頭辞付けたらラップできるな
〜〜すれば〜〜が無くてもおｋ
って発想を減らしていかないと「誰でも使えるフレームワーク」にならないんだろうね
わかってる人だけでいじるならこの思想の方が楽でいいんだがｗ
>>319
CodeIgniterも関数じゃなかったかな？
って発想を減らしていかないと「誰でも使えるフレームワーク」にならないんだろうね
わかってる人だけでいじるならこの思想の方が楽でいいんだがｗ
>>319
CodeIgniterも関数じゃなかったかな？
「誰でも使えるフレームワーク」とか要らん
誰でも使えないフレームワーク誕生の瞬間である
>>338
ＦＷが機能を実装してなくてもいいんじゃないのかね。
外部ライブラリの導入やユーザ拡張がしやすい設計（ＭＶＣが可能な限り疎結合的）
であることが、いいＦＷの第一条件だと思うよ。
その上で個別に、ＸＸのルータクラスは使いやすいとか、モデルが書きやすいとか、
そういう評価が出てくると思う。
ＦＷが機能を実装してなくてもいいんじゃないのかね。
外部ライブラリの導入やユーザ拡張がしやすい設計（ＭＶＣが可能な限り疎結合的）
であることが、いいＦＷの第一条件だと思うよ。
その上で個別に、ＸＸのルータクラスは使いやすいとか、モデルが書きやすいとか、
そういう評価が出てくると思う。
>>342
ＦＷとは何か？を理解してないやつが語ってるんだからしょうがあるまい。
こう書くと誤解を招く恐れもあるんだが、「仕様こそがＦＷである」とでも書いておくかな。
じゃないと、いつまで経ってもＦＷとライブラリの違いも判らん奴が妙な書込みを続けるし。
ＦＷとは何か？を理解してないやつが語ってるんだからしょうがあるまい。
こう書くと誤解を招く恐れもあるんだが、「仕様こそがＦＷである」とでも書いておくかな。
じゃないと、いつまで経ってもＦＷとライブラリの違いも判らん奴が妙な書込みを続けるし。
＞仕様こそがＦＷ
ﾜｹﾜｶﾗﾝ
ﾜｹﾜｶﾗﾝ
こう書くと誤解を招く恐れもあるんだが、
「『仕様こそがFWである』こそ妙な書込み」とでも書いておくかな。
じゃないと、いつまで経っても妙な書込みとそうでない書込みの
違いも判らん奴が妙な書込みを続けるし。
「『仕様こそがFWである』こそ妙な書込み」とでも書いておくかな。
じゃないと、いつまで経っても妙な書込みとそうでない書込みの
違いも判らん奴が妙な書込みを続けるし。
フレームワークこそがＦＷである。
最近出てきてるとかを見ると、バッドノウハウの温床だな。
348 ：nobodyさん：2007/07/24(火) 02:52:11 ID:Wl3XMVYJ
Fireworks
Firewall
Frank Williams
>>347
たとえば？典型例は？
たとえば？典型例は？
for ( $i=0,$count=count($contents); $i<$count; $i++ ){
}
ループ中のカウントを減らすためにこういう書き方すんのって
バッドノウハウですか？普通にあり？
}
ループ中のカウントを減らすためにこういう書き方すんのって
バッドノウハウですか？普通にあり？
>>352
アリじゃね？
アリじゃね？
「for文の条件内でcount()を使うな」はバッドノウハウではないと思うけど
その書き方はどうかと……
$count=count($contents);
for ( $i=0; $i<$count; $i++ ){
}
の方が見る人が理解しやすいと思うなぁ
その書き方はどうかと……
$count=count($contents);
for ( $i=0; $i<$count; $i++ ){
}
の方が見る人が理解しやすいと思うなぁ
激しくどっちでも良過ぎて溜息が漏れる
なにが「どうかと……」だよ。いたって普通だろうが。
ワンライナーで書けるものは書けばいいじゃんっていう空気が
phpはあんまりないよな言語仕様による要因が大きいけれども
rubyとかは仕様も使う側もそういう空気に満ち溢れてるから
コードは短いけど行単位の情報量が必然的に多くなる
phpはあんまりないよな言語仕様による要因が大きいけれども
rubyとかは仕様も使う側もそういう空気に満ち溢れてるから
コードは短いけど行単位の情報量が必然的に多くなる
forの式1はカンマ区切りで複数とれるのね。しらんかったよ。
>>359
よく読め
それを避けたいから
for ( $i=0; $i<count($contents); $i++ ){
でなく
for ( $i=0,$count=count($contents); $i<$count; $i++ ){
なんだろ
よく読め
それを避けたいから
for ( $i=0; $i<count($contents); $i++ ){
でなく
for ( $i=0,$count=count($contents); $i<$count; $i++ ){
なんだろ
たしかに、自分がPHPで書くときは出来るだけワンライナーは避けてるなぁ。
他者が関わる場合は、極端に言えば本当の初心者が見ても解るように書いてる。
コードの「格好良さ」より、「解りやすさ」重視って感じかな。
他者が関わる場合は、極端に言えば本当の初心者が見ても解るように書いてる。
コードの「格好良さ」より、「解りやすさ」重視って感じかな。
俺もそう。
なんかワンライナーの方がかっこよくみられるけどね。
わかりやすい方がいい。
Rubyみたいに . で右につないでいけると、
ワンライナーも使いやすくなるんだけど。
なんかワンライナーの方がかっこよくみられるけどね。
わかりやすい方がいい。
Rubyみたいに . で右につないでいけると、
ワンライナーも使いやすくなるんだけど。
366 ：nobodyさん ◆wSaCDPDEl2 ：2007/07/24(火) 20:10:07 ID:???
ワンライナーでなんか書いて
おとこわりだ！
どう考えても>>354のほうが視認性があるだろ。
for文のループに関する議論は、確かsymfonyで話題になったことが
あったみたいだけど、コレすなわち「FWを利用することによるバッドノウハウ」
とはならんよね。
あったみたいだけど、コレすなわち「FWを利用することによるバッドノウハウ」
とはならんよね。
一方ロシアは
foreach ($contents as $i => $content) { }
を使った
foreach ($contents as $i => $content) { }
を使った
それは、パフォ的にありまくり。使っちゃいけないだろうな。
えええええ
ロシア駄目じゃん
ロシア駄目じゃん
手元のテストループで言えば、ロシアは1.5倍増の時間がかかってる。
ロシアの負け。
ロシアの負け。
つーかPHPならforeachふつうに使うだろ。。
おまえら本当にPHP使ってるのか。
おまえら本当にPHP使ってるのか。
連想配列なら使うけど普通の配列なら使わない
for使う事自体が少ないしな
連想配列の話してるわけじゃないんだけどね。
・中身だけ使う
foreach ($array as $value) { }
・キーだけ使う
foreach (array_keys($array) as $key) { }
・両方使う
foreach ($array as $key => $value) { }
for使うってのは滅多にないな
しかしFWのスレなのに重隅論議だな
foreach ($array as $value) { }
・キーだけ使う
foreach (array_keys($array) as $key) { }
・両方使う
foreach ($array as $key => $value) { }
for使うってのは滅多にないな
しかしFWのスレなのに重隅論議だな
前にも出た結論な気がするけど
FW使うってだけでそんな重隅最適化なんてぜんぶチャラだよなｗ
FW使うってだけでそんな重隅最適化なんてぜんぶチャラだよなｗ
最適化っていう視点じゃなくて綺麗で視認性がある書き方したい
ってことで見れば別に重箱でもない。
ってことで見れば別に重箱でもない。
>綺麗で視認性がある書き方したい
そんなもんPHP使ってる時点で(
そんなもんPHP使ってる時点で(
お前みたいな思考停止はイラネ
ブロックスコープのある言語の使用者にとっては、ブロック内での使い捨ての変数は初期化式で宣言するのが当たり前なんだけどな。
この辺にペチパーの底力を感じる。
この辺にペチパーの底力を感じる。
人を見下さずに普通に発言できんものですかねおまいら
仕様です
>>351
ページごとにいちいちサブコントローラ(Action)を書かないと動かないような、
無駄にStrutsの汚点を継承しているEthnaとか。
処理系の実装してる組織のくせに言語仕様じゃなくて
コーディングルールでゴリゴリ縛ってるZendとか
しょうもない所でPEAR::DBに依存してるくせにDB::getAll()がラップされてなくて、
結局メンバのPEAR::DBインスタンスに直接アクセスするしか解決方法が無かったりとか
どうせ作業の流れなんて機能単位でしかやらないのに
ファイル構成でモデルとビューのディレクトリががロンドン・パリなみに離れてるわ
さらにそれぞれアクション命名規則に縛られてかなりディープなディレクトリ構成になるわで
Eclipseの画面からはみでてしまって小さい修正のたびに
スクロールバーいじらんなんハメになってたりとか
PHPなんて標準でフォームバリデータとモデル仕様がないから面倒なだけなのに
FWなんて大げさなもんにして一生使いもしないクラスを多重に内包して無駄なメモリ・CPU時間食ってる
PHP用FWの存在意義とか。
ページごとにいちいちサブコントローラ(Action)を書かないと動かないような、
無駄にStrutsの汚点を継承しているEthnaとか。
処理系の実装してる組織のくせに言語仕様じゃなくて
コーディングルールでゴリゴリ縛ってるZendとか
しょうもない所でPEAR::DBに依存してるくせにDB::getAll()がラップされてなくて、
結局メンバのPEAR::DBインスタンスに直接アクセスするしか解決方法が無かったりとか
どうせ作業の流れなんて機能単位でしかやらないのに
ファイル構成でモデルとビューのディレクトリががロンドン・パリなみに離れてるわ
さらにそれぞれアクション命名規則に縛られてかなりディープなディレクトリ構成になるわで
Eclipseの画面からはみでてしまって小さい修正のたびに
スクロールバーいじらんなんハメになってたりとか
PHPなんて標準でフォームバリデータとモデル仕様がないから面倒なだけなのに
FWなんて大げさなもんにして一生使いもしないクラスを多重に内包して無駄なメモリ・CPU時間食ってる
PHP用FWの存在意義とか。
今度は>>388が素晴らしいFWを教えてくれるそうです。
ページごとにサブコントローラを書かずに動くとしたらどんなの？
簡単さでいうと、
ちいたん＞CodeIgniter＞CakePHP＞Symfony
ですか？
ちいたん＞CodeIgniter＞CakePHP＞Symfony
ですか？
BKって何？
>>モデルとビューのディレクトリががロンドン・パリなみに離れてる
こんなん自分で変えたらいいだけじゃね
こんなん自分で変えたらいいだけじゃね
ディレクトリ構成自体がＦＷの設計であるということも
わからない奴はＦＷを触るなよ
わからない奴はＦＷを触るなよ
こう書くと誤解を招く恐れもあるんだが、「ディレクトリ構成こそがＦＷである」とでも書いておくかな。
>>388
> 処理系の実装してる組織のくせに言語仕様じゃなくて
> コーディングルールでゴリゴリ縛ってるZendとか
これはまさにその通りだな。
つーか、PHPの開発チームってどういう構成になってるんだ？
> 処理系の実装してる組織のくせに言語仕様じゃなくて
> コーディングルールでゴリゴリ縛ってるZendとか
これはまさにその通りだな。
つーか、PHPの開発チームってどういう構成になってるんだ？
>>397
俺はBerryz工房だな
俺はBerryz工房だな
FW（的なもの）ありきなものがいいんなら
勝手にcoldfusionなりwebobjectsなりやってくれ
勝手にcoldfusionなりwebobjectsなりやってくれ
>>399
俺は美少女教育が気になる
俺は美少女教育が気になる
>>401
これらね↓
ttp://framework.zend.com/manual/ja/coding-standard.html
?>書かないのも気持ち悪い〜とか思ってたけど、
自然と書かなくなったな。なんかめんどうだから。
これらね↓
ttp://framework.zend.com/manual/ja/coding-standard.html
?>書かないのも気持ち悪い〜とか思ってたけど、
自然と書かなくなったな。なんかめんどうだから。
へー。
？＞省略は糞だろうなあ。
単にヘッダの空文字列送出防ぐためにやってるんでしょ？
本末転倒だ
？＞省略は糞だろうなあ。
単にヘッダの空文字列送出防ぐためにやってるんでしょ？
本末転倒だ
さっさと <?php を省略できるようにしろよ、糞Zend
sigilは好みもあるからどっちでもいいけど、つけるんだったらコレくらいはパースしてほしい。
<?php
$a = array('a'=>1);
print "$a['a']\n";
?>
↑エラー
#!/usr/bin/perl
%a = ('a'=>1);
print "$a{'a'}\n";
↑「1」。当然の勝利。
<?php
$a = array('a'=>1);
print "$a['a']\n";
?>
↑エラー
#!/usr/bin/perl
%a = ('a'=>1);
print "$a{'a'}\n";
↑「1」。当然の勝利。
片方を文法に従わず書いて他方を文法に従って書いて何が勝利なのか全然わからんがｗ
既存の文法が気に食わないならソースにパッチ当ててオリジナルのPHP作って使ったら？
既存の文法が気に食わないならソースにパッチ当ててオリジナルのPHP作って使ったら？
要するにPHPのパーサーがヘボってこと。
要してねーだろ
ヘボいのはPHPの文字列解釈仕様であってパーサはその仕様の通りに正常に動いてるんだろーが
自分が何を気に入らないのかすら理解できてないアフォですか？
ヘボいのはPHPの文字列解釈仕様であってパーサはその仕様の通りに正常に動いてるんだろーが
自分が何を気に入らないのかすら理解できてないアフォですか？
仕様って…ｗ。
まあ、PHPはprint $a['a']."\n";とやるしかないわな。
$a = 0 || 100;とか3項演算子の左結合とか、たいそうな仕様だわ。
こういうのが積み重なって、PHPのヘボソースが出来上がる。
まあ、PHPはprint $a['a']."\n";とやるしかないわな。
$a = 0 || 100;とか3項演算子の左結合とか、たいそうな仕様だわ。
こういうのが積み重なって、PHPのヘボソースが出来上がる。
print "{$a['a']}\n";
何もそんなに自信満々で無知をひけらかすことはないと思うんだ。
何もそんなに自信満々で無知をひけらかすことはないと思うんだ。
print "$a[a]\n"; もしくは print "{$a[a]}\n";
PHPの糞仕様を擁護する気はさらさらねーが
悪口言いたい一心で研究不足を自慢されてもバカじゃね?としか思えん
PHPの糞仕様を擁護する気はさらさらねーが
悪口言いたい一心で研究不足を自慢されてもバカじゃね?としか思えん
>>411
その{}を面倒と思わないなら、それでいいよ。俺はノーサンキュー。
その{}を面倒と思わないなら、それでいいよ。俺はノーサンキュー。
>>412残念
配列ですべきこととしてはならないこと
なぜ、$foo[bar] は使用できないのか?
http://www.php.net/manual/ja/language.types.array.php
配列ですべきこととしてはならないこと
なぜ、$foo[bar] は使用できないのか?
http://www.php.net/manual/ja/language.types.array.php
>>412は釣りだろ？でなきゃ考え付かない
codeigniterのリンクヘルパの仕様おかしくね？
引数の順序はfunc(label,uri…）だろ、感覚的に考えて。
anchor(uri,label)ってなめてんのかこの野郎
引数の順序はfunc(label,uri…）だろ、感覚的に考えて。
anchor(uri,label)ってなめてんのかこの野郎
<a href="url">label</a> の順序に従ってるんじゃないか？
感覚の問題だから一概には言えないが俺もlabelが前の方が自然だと思う
感覚の問題だから一概には言えないが俺もlabelが前の方が自然だと思う
<a href="url">label</a>において
href…属性
label…内容
重要度から言えば内容>属性だから、
第一引数は内容=labelがふさわしい
href…属性
label…内容
重要度から言えば内容>属性だから、
第一引数は内容=labelがふさわしい
フレームワークでは標準的な、
「mod_rewriteを使ってindex.phpを隠す方式」の正式な名称って何ですか？
「mod_rewriteを使ってindex.phpを隠す方式」の正式な名称って何ですか？
>>419
symfony様に喧嘩売ってんのか
symfony様に喧嘩売ってんのか
PATH_INFO方式とはまた別なの？
>>424
PATH_INFOの場合は、..../index.php/foo/barが機能するから直接の関係性はない。
PATH_INFOの場合は、..../index.php/foo/barが機能するから直接の関係性はない。
隠れディスパッチャ方式でok
indexの話でもなくて
リライトルータ、URLマッパーの話でもない?
リライトルータ、URLマッパーの話でもない?
mod_rewriteを使ったフロントコントローラ、かなあ
>>428
機能そのまま説明してるだけじゃんｗ
機能そのまま説明してるだけじゃんｗ
>>427
ゼンブ違う
ゼンブ違う
いってる意味ﾜｶﾗﾝなあ。
URLが先、ラベルが後のほうが直感的にＯＫだろ
URLが先、ラベルが後のほうが直感的にＯＫだろ
まあ、感覚だから個人差はあるな
symfonyはlabel,url
ciはurl,label
他は？
symfonyはlabel,url
ciはurl,label
他は？
そもそも中に入るテキストを
「ラベル」って呼ぶ事に何の疑問を感じてないおまえらにイライラする
「ラベル」って呼ぶ事に何の疑問を感じてないおまえらにイライラする
呼んでいる奴に付き合ってあげてるだけだからそこでイライラするな
そんなこといえば「中に入るテキスト」なんてW3C定義と全然違うだろ。
そんなこといえば「中に入るテキスト」なんてW3C定義と全然違うだろ。
話題を振った416の用語に合わせてるだけだと思うが
そういう434は何と呼ぶのが良いと思う？
個人的には「アンカ」「アンカ文」あたりかと思うが
「ラベル」の方がより多くの人に意味が伝わりそうな気がするな
そういう434は何と呼ぶのが良いと思う？
個人的には「アンカ」「アンカ文」あたりかと思うが
「ラベル」の方がより多くの人に意味が伝わりそうな気がするな
どうでもいい定義に拘ってる434の方にイライラする
普通に伝わればいいだろ
テーマの中核じゃないんだから
普通に伝わればいいだろ
テーマの中核じゃないんだから
434の人気に、嫉妬はしない
リアル涙目なんで
引き続き 【PHP】フレームワークについて語るスレ7【総合】 でお楽しみください
「中に入るテキスト」はねーよ俺、反論できない
引き続き 【PHP】フレームワークについて語るスレ7【総合】 でお楽しみください
「中に入るテキスト」はねーよ俺、反論できない
泣いてるの？
ZFの場合
リンクのヘルパ自体無い
リンクのヘルパ自体無い
二大人気FWのsymfonyとcakeが
label,urlを採用しているということは
ciは異端
ZFはなめすぎワロタ
label,urlを採用しているということは
ciは異端
ZFはなめすぎワロタ
>>416
ヒント：イニシャルは姓と名が逆
ヒント：イニシャルは姓と名が逆
CIって規模小さいけど作ってるヤツ頭いいな〜。
label,urlは前々から疑問感じてた。
label,urlは前々から疑問感じてた。
擁護みたいな形になるが、俺も「ラベル」の意味がわからず読んでたが、
434を読んでやっと<a href=url>この部分</a>のことだとわかった
もちろんlink(label, url)ってペアで書いてあればすぐわかることだけど
434を読んでやっと<a href=url>この部分</a>のことだとわかった
もちろんlink(label, url)ってペアで書いてあればすぐわかることだけど
ciのヘルパが気持ち悪いから
my_anchor作りました(`Д´)
my_anchor作りました(`Д´)
ラベルって呼ぶのは
GUIのプログラミングの文化
GUIのプログラミングの文化
>>430
そんなにレアケースとも思わないけど。
入力されたURLを<a>タグに置き換える時とかに使わない？
ま、どっちが先だろうがどーでも良いけど、
>>447みたいな事するくらいなら他のFW使えば良いのに。
そんなにレアケースとも思わないけど。
入力されたURLを<a>タグに置き換える時とかに使わない？
ま、どっちが先だろうがどーでも良いけど、
>>447みたいな事するくらいなら他のFW使えば良いのに。
>>449
そりゃ気付かなかった
そりゃ気付かなかった
>>450
いやいやいや
他のFW使うくらいならヘルパ作る方が断然楽だろ
リンクヘルパの引数の順番の好みのために、学習曲線を登る苦労とか実装されてるユーティリティ機能とかを完全に無視できる奴はそうそういないだろｗ
いやいやいや
他のFW使うくらいならヘルパ作る方が断然楽だろ
リンクヘルパの引数の順番の好みのために、学習曲線を登る苦労とか実装されてるユーティリティ機能とかを完全に無視できる奴はそうそういないだろｗ
そのうち誰かがどっちでもいい関数作って、それが後々
セキュリティホールになったりするのがぺちぱークオリティ、
とか言ってみる。まぁ、冗談だけど。
セキュリティホールになったりするのがぺちぱークオリティ、
とか言ってみる。まぁ、冗談だけど。
いや、あるあるｗ
俺俺フレームワーク作ってるが
複数DBの抽象化面倒くせえええ
取得できるカラム情報のデータ形式がDBによってかなり違うし
複数DBの抽象化面倒くせえええ
取得できるカラム情報のデータ形式がDBによってかなり違うし
>>455
http://journal.mycom.co.jp/articles/2007/07/28/rubyphp/index.html
PHP版Ruby on Rails? - DB操作クラスを自動生成する"PHP Object Generator
こんなので手間を省けませんか？
http://journal.mycom.co.jp/articles/2007/07/28/rubyphp/index.html
PHP版Ruby on Rails? - DB操作クラスを自動生成する"PHP Object Generator
こんなので手間を省けませんか？
PHP版Ruby on Railsっていう呼び方は全然違くない？
ジャンルが違う感じだ
ジャンルが違う感じだ
なんかもうちょっとでもrailsと被ってたら
タイトルにrailsって書いとけみたいなノリで書いてるな
タイトルにrailsって書いとけみたいなノリで書いてるな
たしかにｗ
そのうち「生鮮食品版 rails！？」とかもう何でもrails付けときゃ売れるだろ的な
しかしまぁDBの抽象化だのDAOだのってのは
それこそもういっそ言語仕様に取り込んじゃってくれよって話だなぁ……
しかしまぁDBの抽象化だのDAOだのってのは
それこそもういっそ言語仕様に取り込んじゃってくれよって話だなぁ……
http://www.tsujita.jp/blojsom/blog/default/PHP/2007/07/13/PHPベンチマーク
code igniter以外遅すぎｗｗｗ
ｵ､ｵ、ｵﾜﾀｰｵﾜｵﾜｵﾜﾀｰ♪
＼ CodeIgniter以外ｵﾜﾀｰｵﾜｵｵﾜｵﾜﾀ／
♪＼(^o^) ♪
＿ ) > ＿ ｷｭｯｷｭ♪
／.◎。／◎｡／|
＼(^o^)／.|￣￣￣￣￣| | ＼(^o^)／
) ) .| |／ ノ ノ
(((( >￣ > )))) ＼(^o^)／ ((( <￣< ))))
) )
((( >￣ > ))))
code igniter以外遅すぎｗｗｗ
ｵ､ｵ、ｵﾜﾀｰｵﾜｵﾜｵﾜﾀｰ♪
＼ CodeIgniter以外ｵﾜﾀｰｵﾜｵｵﾜｵﾜﾀ／
♪＼(^o^) ♪
＿ ) > ＿ ｷｭｯｷｭ♪
／.◎。／◎｡／|
＼(^o^)／.|￣￣￣￣￣| | ＼(^o^)／
) ) .| |／ ノ ノ
(((( >￣ > )))) ＼(^o^)／ ((( <￣< ))))
) )
((( >￣ > ))))
表現の問題でなくて、Theをつけないと思ってる頭が幼稚
日本語を話してるのにtheとかつけたら
The PHP frameworkみたいな滑稽さになるね
The PHP frameworkみたいな滑稽さになるね
へーPHP frameworkって固有名詞なんだ
新しいバンドの名前
なぜPHP frameworkが固有名詞？
冠詞(The)を付けるからって勘違いしてんじゃね？
BSD licenseのTheは固有名詞のTheだろ。
Theで固有名詞って、いったいいつの時代の教育を受けたんだ？
固有名詞かどうかなんて考えて話すやつなんていないっつーの。
対象物を知ってるやつ相手ならThe、知らないやつならa、ってだけ。
The PHP frameworkのTheは、PHPはみんな知ってるからついてる。
The BSD licenseもBSDをみんなが知ってるからついてる。
固有名詞かどうかなんて考えて話すやつなんていないっつーの。
対象物を知ってるやつ相手ならThe、知らないやつならa、ってだけ。
The PHP frameworkのTheは、PHPはみんな知ってるからついてる。
The BSD licenseもBSDをみんなが知ってるからついてる。
(ﾟдﾟ)ﾎﾟｶｰﾝ
ザ・ガマン
PHP frameworkもBSD licenseも一般名詞であって、固有名詞じゃない。
定冠詞theは、他の一般名詞同様、文脈と英文法に従って付けられる。
しかし日本語で話している時に、そのような文脈的なtheは普通つけない。
「俺、そのフレームワーク知ってる！」という意味で「俺、the framework知ってる！」
なんて言うのは明らかにおかしい。
もちろんThe PHP Frameworkという「名称」のフレームワークを作れば固有名詞にもなるがな。
そうでない限り、日本語の文脈でtheをつけるのはおかしい。
定冠詞theは、他の一般名詞同様、文脈と英文法に従って付けられる。
しかし日本語で話している時に、そのような文脈的なtheは普通つけない。
「俺、そのフレームワーク知ってる！」という意味で「俺、the framework知ってる！」
なんて言うのは明らかにおかしい。
もちろんThe PHP Frameworkという「名称」のフレームワークを作れば固有名詞にもなるがな。
そうでない限り、日本語の文脈でtheをつけるのはおかしい。
なにをいっているのかわからない
the PHP frameworkもthe BSD licenseもおかしいってことだろ
えーっと
「The BSD Licence」というライセンス名なんだけどー……
「BSD Licence」に the を付けるかどうかなんて話はそもそも無関係なのよ
そもそも英語の名称の話をしてるのに「日本語で話してる時」って前提が既におかしいし
「ビーエスディーライセンス」という日本語名詞の話だと言い張りたいならそれでもいいけど
だとしたら皆と前提が違いすぎて会話になってないのは自分でもわからないかね？
「The BSD Licence」というライセンス名なんだけどー……
「BSD Licence」に the を付けるかどうかなんて話はそもそも無関係なのよ
そもそも英語の名称の話をしてるのに「日本語で話してる時」って前提が既におかしいし
「ビーエスディーライセンス」という日本語名詞の話だと言い張りたいならそれでもいいけど
だとしたら皆と前提が違いすぎて会話になってないのは自分でもわからないかね？
theの話とかどうでもいいよ
ほんとしねばいいのに
ほんとしねばいいのに
BSD licenceでググると57,200件見つかるが
"The BSD licence"でググると7件しか見つからない
つまりそういうことだ
"The BSD licence"でググると7件しか見つからない
つまりそういうことだ
しゃれにならんほどどうでも良い話題に萎え
THE END
> The BSD Licence の検索結果 約 1,260,000 件中 1 - 50 件目 (0.14 秒)
……？('A`)
http://www.opensource.org/licenses/bsd-license.php
とか見たことあるか？
……？('A`)
http://www.opensource.org/licenses/bsd-license.php
とか見たことあるか？
BSDライセンスのことを「The BSD Licence」って書く奴を
きもいと思うか思わないかだけの話だから、正解はないな
きもいと思うか思わないかだけの話だから、正解はないな
中一レベルの英語で揉めてんじゃねーよｗｗ
でもまあそのendにあたって、 licence には突っ込んでおきたい。
私は yu を fackします
ファイルのキャッシュ付いてるFW多いけど
ファイル数あほほど増えるな。
しかもディレクトリ掘りまくりでduでトータルサイズ計算するのにも
やたら時間かかる。
DBに入れた方がいいだろこれ。
ファイル数あほほど増えるな。
しかもディレクトリ掘りまくりでduでトータルサイズ計算するのにも
やたら時間かかる。
DBに入れた方がいいだろこれ。
古いキャッシュファイルを定期的に捨てるようにしたよ
これって常識？
これって常識？
普通はcronで削除する
お好みで。場合によるし一般論はない。
結局、FW実装のCacheじゃなくて、PEARのCache/Cache Liteを使っちゃうな。
使い勝手いいの？
ってか使い勝手悪い糞キャッシュしか実装してないのに
「キャッシュ実装！軽い！」とか宣伝するFW作者反省しろ
ってか使い勝手悪い糞キャッシュしか実装してないのに
「キャッシュ実装！軽い！」とか宣伝するFW作者反省しろ
ＦＷ実装のCacheが、処理プロセスと不可分になっちゃってるから柔軟性に
欠けるという面と、ファイルキャッシュ以外のサーバーAPI系（たとえばyoutube)の
ＰＥＡＲ実装が結局ＰＥＡＲのcache使ってるからね。どうせ導入しなきゃならないなら
最初から使わないって感じ
欠けるという面と、ファイルキャッシュ以外のサーバーAPI系（たとえばyoutube)の
ＰＥＡＲ実装が結局ＰＥＡＲのcache使ってるからね。どうせ導入しなきゃならないなら
最初から使わないって感じ
497 ：nobodyさん：2007/08/06(月) 18:54:30 ID:HUsmqTvF
興味深い話題age
EthnaといいPieceといいMapleといい
国産フレームワークって何でマニュアルがええ加減なやつばっかなんだ？ｗ
国産フレームワークって何でマニュアルがええ加減なやつばっかなんだ？ｗ
ドキュメント整備ってめんどくさいから
どの分野でもテクノロジーを文章して伝達・教育する技術や能力は英語圏は他のついづいを許さんよね。
釣り針が太すぎます
仕様が固まりきってないからドキュメントにしにくいんじゃね？
ドキュメント化すると実態と乖離していきかねないから、
ちょっと曖昧なままにしておきたいっていうか。
すくなくとも俺はそういうのあるね。
ドキュメント化すると実態と乖離していきかねないから、
ちょっと曖昧なままにしておきたいっていうか。
すくなくとも俺はそういうのあるね。
つまり面倒だと
日本には「見て技術を盗め」という文化がある・・・のか？
>>506みたいに何もしないくせにしたり顔で文句言う奴ばかりいるので
真面目にやる気がしなくなるという事情もある
真面目にやる気がしなくなるという事情もある
>>507
まあいいんじゃね。お前のような人のせいにする奴のプログラムは誰も使わないから。
まあいいんじゃね。お前のような人のせいにする奴のプログラムは誰も使わないから。
なんでアウトラインが関係あるのかよく分からないな
ソース改変
だけの労力が、
ソースを改変＋ドキュメント改変
になるのがしんどいんだよ
まあ、ドキュメントを書くことでインターフェイスが簡素になるという
いい作用もあるけど…
ソース改変
だけの労力が、
ソースを改変＋ドキュメント改変
になるのがしんどいんだよ
まあ、ドキュメントを書くことでインターフェイスが簡素になるという
いい作用もあるけど…
testを載せるだけでも違うけどね。
ちいたん使ってみた。けっこう扱い易くていい感じなんだが、
MojaviやSymfonyに慣れてるとフロントコントローラが欲しくなるな。
アクションの遷移が従来通りだからなあ。よくもわるくも。
アクションといえば、action()がクラスじゃなくて関数での実装なのは、
ソースコピペする時に
ｸﾗｽ名変ｴﾙﾉﾓﾏﾝﾄﾞｸｾ
なんだと気付いた。Mojviじゃけっこうそんなクラスないぞって怒られたからな。
MojaviやSymfonyに慣れてるとフロントコントローラが欲しくなるな。
アクションの遷移が従来通りだからなあ。よくもわるくも。
アクションといえば、action()がクラスじゃなくて関数での実装なのは、
ソースコピペする時に
ｸﾗｽ名変ｴﾙﾉﾓﾏﾝﾄﾞｸｾ
なんだと気付いた。Mojviじゃけっこうそんなクラスないぞって怒られたからな。
>>511 さあ、つくろ
PHPの分際でaf->getとかアホじゃね？って思う。
$_REQUEST上書きで十分。
てかPHP自体にバリデータがない時点でそこから発展する事になるFWなんてウンコ化は既定路線なんだがな。
$_REQUEST上書きで十分。
てかPHP自体にバリデータがない時点でそこから発展する事になるFWなんてウンコ化は既定路線なんだがな。
>>513 ウンコ！
いよいよ政治的に大成功してきたRuby
貧民言語PHPm9 (^Д^)ﾌﾟｷﾞｬｰ
貧民言語PHPm9 (^Д^)ﾌﾟｷﾞｬｰ
他言語をわざわざ貶す理由が分からない。
自分が好きな言語使ってればいいだろｗ
自分が好きな言語使ってればいいだろｗ
cakeとかMapleとか、まぁPHP用に現存するフレームワークって
MVCを実現するため「だけ」のライブラリ？
MVCを実現するため「だけ」のライブラリ？
＞MVCを実現するため「だけ」のライブラリ
が何を示しているのか理解しかねるが、
MVCの分離構造を実現するだけという意味であれば、
そのほかにもActiveRecordだのORMだのDIだの実現すんじゃね
MVCの分離構造を実現するだけでよければちいたん超おすすめｗｗｗ
が何を示しているのか理解しかねるが、
MVCの分離構造を実現するだけという意味であれば、
そのほかにもActiveRecordだのORMだのDIだの実現すんじゃね
MVCの分離構造を実現するだけでよければちいたん超おすすめｗｗｗ
漏れんとこ、開発チームごとにレベル差があってさ、
ずっと生PHPだけで力任せに案件こなしてきていて、
生PHPじゃないっていうだけでなかなか受け付けないような
DQNぎみの連中対策がそろそろ必要なんだよね。
でもいきなり本格的なフレームワークだと学習コストが云々、
兵隊にはメンテさせられん云々……
とかなんとか管理職に言われてしまうよな。
それを避ける意味でも、
ちいたんに限らなくってもいいんだけど、
あのくらいの規模でコードの見通しの効くフレームワークで小さい案件やらせて
段階的にMVC開発に慣れさせるといいかもしれんと思ってる。
もちろん悩み易いconfig類のカスタマイズは先に片付けておいて、
あとはアクションとコンポーネントとテンプレート作るだけとなるように
兵隊向け作業手順のマニュアル書くんだけどな。
ずっと生PHPだけで力任せに案件こなしてきていて、
生PHPじゃないっていうだけでなかなか受け付けないような
DQNぎみの連中対策がそろそろ必要なんだよね。
でもいきなり本格的なフレームワークだと学習コストが云々、
兵隊にはメンテさせられん云々……
とかなんとか管理職に言われてしまうよな。
それを避ける意味でも、
ちいたんに限らなくってもいいんだけど、
あのくらいの規模でコードの見通しの効くフレームワークで小さい案件やらせて
段階的にMVC開発に慣れさせるといいかもしれんと思ってる。
もちろん悩み易いconfig類のカスタマイズは先に片付けておいて、
あとはアクションとコンポーネントとテンプレート作るだけとなるように
兵隊向け作業手順のマニュアル書くんだけどな。
>>518
ちいたん初耳だった。調べてみる。
> ＞MVCを実現するため「だけ」のライブラリ
> が何を示しているのか理解しかねるが、
ごめん、質問の意図と質問文が乖離してた。
まぁFWによるんだろうけど、
PHP用のFWを使う ＝ MVCサイト構築
ってことになるのかな。
つまり。そのFWでサイト構築するには、MVC方式を余儀なくされてしまうとか。
もしそうだったら、なんかそれって「縛り」だよなぁってふと思っただけ。
>>519
DQN環境乙。
何でもかんでもMVCってのもどうかと思うけど、
とりあえずそういうときはMVCとかOOPとか、
開発手法の素晴らしさをアピールするといいかもしれん。
もうしたのかもだけど。
うちは、「一時の痛みを我慢して、その後が楽になるなら」
ってことで学習コストとか割いてくれた。
ちいたん初耳だった。調べてみる。
> ＞MVCを実現するため「だけ」のライブラリ
> が何を示しているのか理解しかねるが、
ごめん、質問の意図と質問文が乖離してた。
まぁFWによるんだろうけど、
PHP用のFWを使う ＝ MVCサイト構築
ってことになるのかな。
つまり。そのFWでサイト構築するには、MVC方式を余儀なくされてしまうとか。
もしそうだったら、なんかそれって「縛り」だよなぁってふと思っただけ。
>>519
DQN環境乙。
何でもかんでもMVCってのもどうかと思うけど、
とりあえずそういうときはMVCとかOOPとか、
開発手法の素晴らしさをアピールするといいかもしれん。
もうしたのかもだけど。
うちは、「一時の痛みを我慢して、その後が楽になるなら」
ってことで学習コストとか割いてくれた。
>>520
MVCサイトというのもいまいちよくわからん表現だが
そもそもフレームワークっていうのは縛りでしょ
フレームワークの提供する枠組み＝制約というのが一定のルールになって
同じフレームワークを使っている人間のコンセンサス取りやすくなったり
問題点の発見が早くなったり
そもそも問題が発生しづらくなるわけで
MVCサイトというのもいまいちよくわからん表現だが
そもそもフレームワークっていうのは縛りでしょ
フレームワークの提供する枠組み＝制約というのが一定のルールになって
同じフレームワークを使っている人間のコンセンサス取りやすくなったり
問題点の発見が早くなったり
そもそも問題が発生しづらくなるわけで
>>520
なるほど。言う通りですよ。一部DQNなのをなんとかしたい。
ときどき手法の説明をしたり改善策として提案してるんだけど、
従来の流れと違うといまいちピンと来ないらしい。
既存案件におわれて勉強する時間もとれてないようだし。
漏れのところでいちばん効果的だったのは、
10ページくらいの小規模な案件をあっというまに片付けて、
目の前で速度差を見せつけた時かな。
慣れれば効果あるっていうのは分かったみたいだった。
規模によってはMVCでさえ大袈裟すぎる場合や、
ビューの要らないバッチ処理やインタフェース物ももちろんあるわけで。
そこは適材適所。
本格的なフレームワークで大き目の案件だと、
開発速度以上に分業しやすさとメンテ性のためにMVC開発をするんだと思ってるんだけど、
開発速度ほど有利さを披露しにくいのが難点だよね。
なるほど。言う通りですよ。一部DQNなのをなんとかしたい。
ときどき手法の説明をしたり改善策として提案してるんだけど、
従来の流れと違うといまいちピンと来ないらしい。
既存案件におわれて勉強する時間もとれてないようだし。
漏れのところでいちばん効果的だったのは、
10ページくらいの小規模な案件をあっというまに片付けて、
目の前で速度差を見せつけた時かな。
慣れれば効果あるっていうのは分かったみたいだった。
規模によってはMVCでさえ大袈裟すぎる場合や、
ビューの要らないバッチ処理やインタフェース物ももちろんあるわけで。
そこは適材適所。
本格的なフレームワークで大き目の案件だと、
開発速度以上に分業しやすさとメンテ性のためにMVC開発をするんだと思ってるんだけど、
開発速度ほど有利さを披露しにくいのが難点だよね。
>>520
pradoっていうのが、確かMVCじゃなくてイベントドリブン型のどうのこうのって読んだな
http://www.pradosoft.com/demos/quickstart/index.php?page=GettingStarted.AboutPrado&lang=ja
http://hain.jp/index.php/tech-j/2007/08/06/p166
ということらしいよ。
pradoっていうのが、確かMVCじゃなくてイベントドリブン型のどうのこうのって読んだな
http://www.pradosoft.com/demos/quickstart/index.php?page=GettingStarted.AboutPrado&lang=ja
http://hain.jp/index.php/tech-j/2007/08/06/p166
ということらしいよ。
ピースFWもイベントドリブンらしいね
そのpradoのページを何枚か眺めただけだけど、ＭＶＣ的に実装していくんじゃないの結局は。
View部分はこうだ、って言ってるだけで、そのイベントに対応するクラスはコントローラを基底に
持つと思うぜ。
View部分はこうだ、って言ってるだけで、そのイベントに対応するクラスはコントローラを基底に
持つと思うぜ。
viewにガシガシロジック書いてく時点でMVC分離じゃねーべ
普通にやれば、結局そのview用コントローラー実装することになるんだよ。
なるほど理解しました。おもろそうだなprado。でもコンポーネント溜まるまではちときついか
ウェブアプリにイベントドリブンもへったくれもねーよ。
出たな半生野郎
533は何勘違いしてるんだ？
削除依頼だしてこいよ。
削除依頼だしてこいよ。
PHP on Rails って PHP on Trax の旧名だよな
536 ：nobodyさん：2007/08/18(土) 16:49:31 ID:XeatXWbb
こいつも佐久間と一緒で本出しすぎだな。
>>536
発売したら立ち読みしてこよっと
発売したら立ち読みしてこよっと
そしたらレポして３行で総括よろしく
なんかドキュメント印刷しただけっぽい内容だな。
携帯サイトに相性がいいフレームワークってある？
>>541
何を求めてフレームワーク使おうとしているかがわからんから答えようがない
何を求めてフレームワーク使おうとしているかがわからんから答えようがない
フレームワーク本は予想通り、マニュアルコピペ＆彼女の他作の流用でした
545 ：nobodyさん：2007/08/22(水) 08:04:04 ID:4atvg3yr
掲示板の投稿で
フォーム記入→確認顔面→投稿
この流れを簡単にしやすいFWないかな？
フォーム記入→確認顔面→投稿
この流れを簡単にしやすいFWないかな？
PEARのQuickFormだか何だかは？
一瞬いい本が出ると思ったが
マニュアルをネットからダウンロードすればいいだけの話か
マニュアルをネットからダウンロードすればいいだけの話か
549 ：nobodyさん：2007/08/23(木) 15:37:34 ID:gq3i3Qc4
>>546
顔面はともかくethnaかな？
顔面はともかくethnaかな？
551 ：nobodyさん：2007/08/24(金) 00:42:54 ID:YoTG53/u
なぜethnaが優位性を持つのか説明してくれ
ふじもと神の顔面が優位(=イケメン)なのかと思った。
554 ：nobodyさん：2007/08/25(土) 15:41:51 ID:m12CHPqL
QFがダメな子とは良く聞くけど、
ダメさを今一理解していない俺に、QFの機能でダメな点を教えてくれ。
QF無しだと確認画面尽きデータ更新画面作るの超面倒臭くない？
入力値のバリデートもフィルタも。
そういう時は皆QF以外の何使ってるんでしょう。
ダメさを今一理解していない俺に、QFの機能でダメな点を教えてくれ。
QF無しだと確認画面尽きデータ更新画面作るの超面倒臭くない？
入力値のバリデートもフィルタも。
そういう時は皆QF以外の何使ってるんでしょう。
> そういう時は皆QF以外の何使ってるんでしょう。
CakePHPなどのフレームワーク。
CakePHPなどのフレームワーク。
QFはフォームの組み立てから入力のバリデートにHTML出力まで全部こなそうとするんで
特に入力値のバリデーションとかで
Mojaviとかのフルスタックのフレームワークに組み込みにくいという事情があった
でも今でもSymfonyとかCakeとかCIとかが持つフォームシステムで
QFほど何から何まできちんとやってくれるものはないと思う
特にバリデーションJavaScript自動生成とfreeze()あたりは
今風のフレームワークでも何らかで実装してほしいものだなー
あとQFCは死んでるしやるだけ時間の無駄だと思うｗ
特に入力値のバリデーションとかで
Mojaviとかのフルスタックのフレームワークに組み込みにくいという事情があった
でも今でもSymfonyとかCakeとかCIとかが持つフォームシステムで
QFほど何から何まできちんとやってくれるものはないと思う
特にバリデーションJavaScript自動生成とfreeze()あたりは
今風のフレームワークでも何らかで実装してほしいものだなー
あとQFCは死んでるしやるだけ時間の無駄だと思うｗ
>>554
2年前の記事だけど
http://hatotech.org/kumatch/archives/000475.html
一時期QFが取り上げられて流行ったけど
QFだとフォームのエレメント主導の作りになっちゃうんだな
フォームにvalidationがぶら下がっちゃうっていうか
コントローラにエレメント生成のコードが入っちゃうし
あと複雑なフォームの構成になるとトリッキーなコードになりやすかった
現状のFWなら大体フォームエレメントの生成はViewHelper、
入力値のvalidationはValidatorでやる形が主流だな
歴史的にそういう経緯があって、今こうなっているということは
結局今の形がよりベターな構成だということなんじゃないかな
2年前の記事だけど
http://hatotech.org/kumatch/archives/000475.html
一時期QFが取り上げられて流行ったけど
QFだとフォームのエレメント主導の作りになっちゃうんだな
フォームにvalidationがぶら下がっちゃうっていうか
コントローラにエレメント生成のコードが入っちゃうし
あと複雑なフォームの構成になるとトリッキーなコードになりやすかった
現状のFWなら大体フォームエレメントの生成はViewHelper、
入力値のvalidationはValidatorでやる形が主流だな
歴史的にそういう経緯があって、今こうなっているということは
結局今の形がよりベターな構成だということなんじゃないかな
>>555
>>556
自社製FWしか使った事が無くて、
それはQFを組み込んだものでして。
CIとかCakeのマニュアルを流し読み程度はしてみたものの、
面倒臭い確認画面尽きの時の画面遷移コントロールなんかがカバーされてるようには見えなくて、不思議に思ってました。
海の向こうでは確認画面あまり出さないからなのかな、とか。
フォーム要素をPHPオブジェクトと対応させるQFの発想は悪くないと思うのになぁ、とか。
まぁ、とりあえず実際にCI、Cake辺り触ってみるのが早そうですね。
>>556
自社製FWしか使った事が無くて、
それはQFを組み込んだものでして。
CIとかCakeのマニュアルを流し読み程度はしてみたものの、
面倒臭い確認画面尽きの時の画面遷移コントロールなんかがカバーされてるようには見えなくて、不思議に思ってました。
海の向こうでは確認画面あまり出さないからなのかな、とか。
フォーム要素をPHPオブジェクトと対応させるQFの発想は悪くないと思うのになぁ、とか。
まぁ、とりあえず実際にCI、Cake辺り触ってみるのが早そうですね。
JavaScriptによるクライアントサイドバリデーションはUI的には良いかもしれないけど
信頼性は皆無なので、結局サーバサイドでのバリデーションが必要になるよね。
だからバリデーションJavaScript自動生成を好んで実装したがるFW作者は少ないと思う。
フォーム要素とPHPオブジェクトのバインディングとは少し違うけど、
HTML_Template_Flexyでのフォーム要素の扱いは知っておいて損はないかも。
信頼性は皆無なので、結局サーバサイドでのバリデーションが必要になるよね。
だからバリデーションJavaScript自動生成を好んで実装したがるFW作者は少ないと思う。
フォーム要素とPHPオブジェクトのバインディングとは少し違うけど、
HTML_Template_Flexyでのフォーム要素の扱いは知っておいて損はないかも。
>>560
QFだとバリデーションをひとつ設定すればサーバサイドとクライアントサイドを自動的にやってくれるんで
信頼性をサーバサイドで確保しつつUI利便性のためクライアントサイドで……ってのが
とても簡単にできたのよ
（自作ルールセットではさすがにそうもいかないけど）
最近じゃクライアントサイドの利便性はAJAX使えってことになっちゃうのかなぁ
でもそれ自体をやりやすくしてるフレームワークってあるのかな
AJAX対応のASP.NETとかはそれに近いことをやってた気がするが……
QFだとバリデーションをひとつ設定すればサーバサイドとクライアントサイドを自動的にやってくれるんで
信頼性をサーバサイドで確保しつつUI利便性のためクライアントサイドで……ってのが
とても簡単にできたのよ
（自作ルールセットではさすがにそうもいかないけど）
最近じゃクライアントサイドの利便性はAJAX使えってことになっちゃうのかなぁ
でもそれ自体をやりやすくしてるフレームワークってあるのかな
AJAX対応のASP.NETとかはそれに近いことをやってた気がするが……
562 ：nobodyさん：2007/08/25(土) 18:45:15 ID:CTb1TM+m
そもそも、フォームの生成なんてするもんじゃないだろ。
それに、主要フレームワークはほとんどビューヘルパーとか用意してるけど、
実際問題、ベタ書きした方が正確だし、デザイナーにも易しいだろ。
それに、主要フレームワークはほとんどビューヘルパーとか用意してるけど、
実際問題、ベタ書きした方が正確だし、デザイナーにも易しいだろ。
563 ：nobodyさん：2007/08/25(土) 19:07:06 ID:S/G680iY
>>562
自分もそう思う。
自分もそう思う。
QF2なんてのも出てきてる。。。
なんだこりゃ。
なんだこりゃ。
>>562
フォームがDBのテーブルへの操作窓であるような概念のアプリの場合は
クラスがバリデータとかを提供する方がむしろ自然になるような設計もあると思う
QFでそれをやろうとすると、HTMLとか$_POSTとかまでQFが面倒みちゃうんで
その辺が激しく気持ち悪いことになるのが難点だけど……
HTMLについてはベタ書きよりもきちんと生成されたものの方が正確って考え方もできると思うよ
あとデザイナはフォームがどうなろうと周囲の枠だけ書けば良いような場合もあるし。
結局いつもの「適材適所で」みたいな結論になっちゃうのが残念だがなぁ
フォームがDBのテーブルへの操作窓であるような概念のアプリの場合は
クラスがバリデータとかを提供する方がむしろ自然になるような設計もあると思う
QFでそれをやろうとすると、HTMLとか$_POSTとかまでQFが面倒みちゃうんで
その辺が激しく気持ち悪いことになるのが難点だけど……
HTMLについてはベタ書きよりもきちんと生成されたものの方が正確って考え方もできると思うよ
あとデザイナはフォームがどうなろうと周囲の枠だけ書けば良いような場合もあるし。
結局いつもの「適材適所で」みたいな結論になっちゃうのが残念だがなぁ
566 ：nobodyさん：2007/08/25(土) 21:37:02 ID:S/G680iY
POST値に対するvalidataだけなら、既存FWのクラスで十分だよ
>>556の言う「QFほど何から何まできちんとやってくれるものはないと思う」って
具体的になにをさしてるのかわからんわ。JSとか言ってるところ見ると
仔細なチェックまでFWに背負わせようとしてるんじゃないの。そんなの
スクラッチでやったほうが確実だっての。
>>556の言う「QFほど何から何まできちんとやってくれるものはないと思う」って
具体的になにをさしてるのかわからんわ。JSとか言ってるところ見ると
仔細なチェックまでFWに背負わせようとしてるんじゃないの。そんなの
スクラッチでやったほうが確実だっての。
手書きは不確実です。絶対にミスが出ます。
>>566
スクラッチでやるよりも、
何もしないほうが確実ですよ？
JavaScriptはほぼ自動生成です。
仔細なチェックは当然、phpコードで書きます。
それだけで自動でJavaScriptコードが生成されるのです。
スクラッチでやるよりも、
何もしないほうが確実ですよ？
JavaScriptはほぼ自動生成です。
仔細なチェックは当然、phpコードで書きます。
それだけで自動でJavaScriptコードが生成されるのです。
連続で真っ赤になって書かなくてもいいのにw
反論できないなら書かなくていいのにｗｗｗｗ
w多い人ですね
二人の証明すべきだな。>>571は
なんかいきなり荒れたなぁ……
べつに相手を言い負かそうとかどっちが勝ちとか考えずに
フレームワークとかフォーム処理とかの良い実装について語り合えるって程度でいいんだけどー
>>566
FWのクラスでも充分だしQFでも充分なバリデートが出来るって話でしょ。
FWの意義のひとつにはなるけどQFが不要になる理由にはならないよね。
あとQFでJSを自動生成できるのはサーバ側でできるチェックより劣るので
完全にUI利便性（POSTする前にすぐにエラーを見つけられるとかその程度）だけの問題。
べつに相手を言い負かそうとかどっちが勝ちとか考えずに
フレームワークとかフォーム処理とかの良い実装について語り合えるって程度でいいんだけどー
>>566
FWのクラスでも充分だしQFでも充分なバリデートが出来るって話でしょ。
FWの意義のひとつにはなるけどQFが不要になる理由にはならないよね。
あとQFでJSを自動生成できるのはサーバ側でできるチェックより劣るので
完全にUI利便性（POSTする前にすぐにエラーを見つけられるとかその程度）だけの問題。
使いたいなら使えばいいと思うけど結局メンテしにくいのよQFで書いてると
フォームちょこっと変えたいだけなのに
ViewじゃなくてControllerにあるエレメント設定をいじらないといけないとか
ちょっと入力必須にしたいだけなのにエレメント設定しないといけないとか
でQFでやってるとフォームに関する全ての処理を
QFでやらないといけない感が漂ってきて
FWでMVCに沿ってるはずがだんだんQF主導のコードになっちゃうわけ
RequestもValidationもViewHelperも兼ねてるからそうならざるを得ない
多機能なライブラリが故にそれが仇となってFWに組み込みづらくなる
だからといってそれらの処理をFWによる機能とQFの機能で
中途半端に混ぜて使ってしまうともう最悪のパターンになる
だから、使わない
フォームちょこっと変えたいだけなのに
ViewじゃなくてControllerにあるエレメント設定をいじらないといけないとか
ちょっと入力必須にしたいだけなのにエレメント設定しないといけないとか
でQFでやってるとフォームに関する全ての処理を
QFでやらないといけない感が漂ってきて
FWでMVCに沿ってるはずがだんだんQF主導のコードになっちゃうわけ
RequestもValidationもViewHelperも兼ねてるからそうならざるを得ない
多機能なライブラリが故にそれが仇となってFWに組み込みづらくなる
だからといってそれらの処理をFWによる機能とQFの機能で
中途半端に混ぜて使ってしまうともう最悪のパターンになる
だから、使わない
QFを使うと氏ぬ
いっそQFに合わせたFWというのはどうだろう。
webベースのエディタ画面でフォームを作成すると、
それに合わせたコードが吐き出されて、
ついでにDBのテーブルも作ってくれる。
これで名実共にWeb版VBの名を欲しいままに・・。
webベースのエディタ画面でフォームを作成すると、
それに合わせたコードが吐き出されて、
ついでにDBのテーブルも作ってくれる。
これで名実共にWeb版VBの名を欲しいままに・・。
フォームからDBスキーマを予想するのは無理ぽ
>>579
マスタ系テーブルだけ先に手動で作らせておいて、
セレクトボックス、チェックボックス、ラジオボタンはそれを使わせる。
連関エンティティが必要になるようなフォームは自動生成からは切り捨てる。
idはサロゲートキー。
text=varchar
textarea=text
マスタ系テーブルだけ先に手動で作らせておいて、
セレクトボックス、チェックボックス、ラジオボタンはそれを使わせる。
連関エンティティが必要になるようなフォームは自動生成からは切り捨てる。
idはサロゲートキー。
text=varchar
textarea=text
すみません、恥を忍んで言いますと、私JSが全く書けないんです。
なので、JS付きのValidateしてくれるQFを見た瞬間！！！これだ！！と。
それだけなんです。JS覚えればQFなんていらないです。
でも覚えられないんです。すみませんでした。
なので、JS付きのValidateしてくれるQFを見た瞬間！！！これだ！！と。
それだけなんです。JS覚えればQFなんていらないです。
でも覚えられないんです。すみませんでした。
入力チェックのjsなんて難しくねーだろ
HTMLにjsが入るのも気に食わん
HTMLにjsが入るのも気に食わん
JSでチェックするメリットはあんまりないよな
ajaxでやるならともかく
QFみたいなﾀﾞｻﾀﾞｻﾁｪｯｸは素人くさいよ
まだあるっちゃあるけど
ajaxでやるならともかく
QFみたいなﾀﾞｻﾀﾞｻﾁｪｯｸは素人くさいよ
まだあるっちゃあるけど
まさかとは思うが、JSのみでValidateしてる人っていないよね。
あくまでUIの快適さをあげるために存在する
追加の機能であるJavaScriptでの検証。
それもサーバー側でのチェックと同じ機能を
二回も書くなんて面倒。
DRYの原則に反する。
自動で生成されたら楽。
追加の機能であるJavaScriptでの検証。
それもサーバー側でのチェックと同じ機能を
二回も書くなんて面倒。
DRYの原則に反する。
自動で生成されたら楽。
自動生成だから使うってのはどうかと思うが。サーバチェックだけでいいし
でなきゃ、「UI」改善のための実装ならajax使うでしょ。
今時html埋め込みの単なるjs使う意味は？
でなきゃ、「UI」改善のための実装ならajax使うでしょ。
今時html埋め込みの単なるjs使う意味は？
できる限り無駄な通信を避けたい時。
そんなことも想定できないほど脳が腐ってますか？
そんなことも想定できないほど脳が腐ってますか？
JSチェックで削減できる通信量がどれだけあるのかって話だよな
貧者の発想という気がする
貧者の発想という気がする
結局サーバー側でもチェックするんだから
通信量なんか関係ないんじゃね？
通信量なんか関係ないんじゃね？
JSでチェックしてNGならsubmit止める（＝通信させない）とかじゃね？
>>589
> JSチェックで削減できる通信量がどれだけあるのかって話だよな
> 貧者の発想という気がする
どうやっても、JavaScriptによるレスポンスの速さを
サーバー通信が必要な方法で超えることはできんよ。
問題は通信量ではなく、すばやい反応。
そこを勘違いしていたお前の負けだ。
> JSチェックで削減できる通信量がどれだけあるのかって話だよな
> 貧者の発想という気がする
どうやっても、JavaScriptによるレスポンスの速さを
サーバー通信が必要な方法で超えることはできんよ。
問題は通信量ではなく、すばやい反応。
そこを勘違いしていたお前の負けだ。
なんか「AJAX=新しい=あらゆる最強」みたいな都市伝説を信奉してる人がいる気がする……
郵便番号から住所への変換とかはAJAXで利便性も上がる一例だけど
項目のrequiredチェックなんぞにいちいちAJAX使ったら利便性下がる一方じゃないかな。
httpdの受け口が増えまくるのはサーバ負荷管理的にもおいしくない。
それが問題にならない程度のアクセス数/サーバ数の予算が取れるなら
負荷の点は問題にしなくてもいい場合もあるが。
郵便番号から住所への変換とかはAJAXで利便性も上がる一例だけど
項目のrequiredチェックなんぞにいちいちAJAX使ったら利便性下がる一方じゃないかな。
httpdの受け口が増えまくるのはサーバ負荷管理的にもおいしくない。
それが問題にならない程度のアクセス数/サーバ数の予算が取れるなら
負荷の点は問題にしなくてもいい場合もあるが。
JSチェック支持派はJSでだっさいalert出したりしてんの？
動的にDOMいじってサーバと通信した場合と同じ画面にするなら
まあありとも思うが
そこまで手間をかけるならもういいわってなるな。
動的にDOMいじってサーバと通信した場合と同じ画面にするなら
まあありとも思うが
そこまで手間をかけるならもういいわってなるな。
>>595
お前言っていることが極端だぞ。
動的にDOMいじってきれいな画面を作る手間をかけるのなら
もういいやと思うんだろ？
そこで普通はもういいやってことでJavaScriptのalertを出すだろ。
１．DOMいじる
２．JavaScriptのalert（コードを別に書く必要は無い）
３．なにもしない
１番がいやだからっていきなり3番の案に飛ぶなよｗ
それに、俺ならalert(msg)の代わりにdocument.getElementById("msg") = msg;に
置き換えるだけだが？ これがそんなに手間がかかることかよｗ
お前言っていることが極端だぞ。
動的にDOMいじってきれいな画面を作る手間をかけるのなら
もういいやと思うんだろ？
そこで普通はもういいやってことでJavaScriptのalertを出すだろ。
１．DOMいじる
２．JavaScriptのalert（コードを別に書く必要は無い）
３．なにもしない
１番がいやだからっていきなり3番の案に飛ぶなよｗ
それに、俺ならalert(msg)の代わりにdocument.getElementById("msg") = msg;に
置き換えるだけだが？ これがそんなに手間がかかることかよｗ
>>596
> ajaxで転送量減らすこともできるよ
転送を伴わないAjaxってJavaScriptと同じことだろｗ
> 別にリアルタイム性だけがajaxの利点でもない
操作性向上に必要なのはリアルタイム性です。
いまはリアルタイム性の高さが（通信をしない）
JavaScriptのエラーチェックの利点だねって話をしているのです。
> ajaxで転送量減らすこともできるよ
転送を伴わないAjaxってJavaScriptと同じことだろｗ
> 別にリアルタイム性だけがajaxの利点でもない
操作性向上に必要なのはリアルタイム性です。
いまはリアルタイム性の高さが（通信をしない）
JavaScriptのエラーチェックの利点だねって話をしているのです。
*'``・* 。
| `*。
,｡∩ * もうどうにでもな〜れ
+ (´･ω･`) *｡+ﾟ
`*｡ ヽ、 つ *ﾟ*
`・+｡*・' ﾟ⊃ +ﾟ
☆ ∪~ ｡*ﾟ
`・+｡*・ ﾟ
| `*。
,｡∩ * もうどうにでもな〜れ
+ (´･ω･`) *｡+ﾟ
`*｡ ヽ、 つ *ﾟ*
`・+｡*・' ﾟ⊃ +ﾟ
☆ ∪~ ｡*ﾟ
`・+｡*・ ﾟ
頑なにJSでのヴァリデートを否定してるヤツは単に書けないだけじゃねーのか。
別に俺は使わないが「利点がわからない」とか言ってる奴は本当に脳が爛れてるとしか思えんｗ
別に俺は使わないが「利点がわからない」とか言ってる奴は本当に脳が爛れてるとしか思えんｗ
最初の問題設定を改竄しちゃいけねーよ。
FWにQFを乗っけて使う煩瑣さの指摘があって、
それを打ち消すだけのメリットとしてjsエラーチェックの自動生成なるもの
が持ち上げられてるから、突っ込みが入ってるだけだろ。
FWにQFを乗っけて使う煩瑣さの指摘があって、
それを打ち消すだけのメリットとしてjsエラーチェックの自動生成なるもの
が持ち上げられてるから、突っ込みが入ってるだけだろ。
普通に>>585のあたりからJSのヴァリデートの利点そのものに疑問を抱いてるヤツいるじゃん。
そういう人に対して言ってるんですがｗ
そういう人に対して言ってるんですがｗ
だったらはげしくスレ違い
>>601
ちょっと誤解があるようだ。
おれが>>556で書いたのは
「打ち消すだけのメリットがjsエラーチェックにある」ではなく
「打ち消すほどのメリットではないが今のFWにも実装してほしい機能としてjsエラーチェックなどがある」なので
jsエラーチェックがなきゃﾔﾀﾞﾔﾀﾞ!と言ってるわけじゃない。
で「jsエラーチェックなんてそもそも不要じゃん」という意見が出てきたのだが
まぁそういう仕事もあるかもしれないけど、あれば便利だとおれは思うし、必要になる案件もある。
AJAX云々は完全に話がすれ違ってると思うが。
ちょっと誤解があるようだ。
おれが>>556で書いたのは
「打ち消すだけのメリットがjsエラーチェックにある」ではなく
「打ち消すほどのメリットではないが今のFWにも実装してほしい機能としてjsエラーチェックなどがある」なので
jsエラーチェックがなきゃﾔﾀﾞﾔﾀﾞ!と言ってるわけじゃない。
で「jsエラーチェックなんてそもそも不要じゃん」という意見が出てきたのだが
まぁそういう仕事もあるかもしれないけど、あれば便利だとおれは思うし、必要になる案件もある。
AJAX云々は完全に話がすれ違ってると思うが。
話は変わるが俺のアイデアを聞いてくれ。
QFの利点はPHPでコードを書くだけでJavaScriptの
エラーチェックに変換してくれる。つまりエラーチェックコードを二度書かなくていいことにあるわけだが、
そのためにはaddRuleメソッドでrequiredを設定するというコードを書く必要がある。
そう、PHPのエラーチェックコードではなく、
フォームに、requiredなどの属性を設定するわけだ。
だから複雑なエラーチェックがやりにくい。
そこでだ、PHPコードそのものでエラーチェックできたら良いとは思わないか？
たとえば、if ( $value == "") {return false;} こういう感じだ。
しかしこのコードをよく見てほしい。なんとそのままでJavaScriptコードとしても通用してしまうのだ！
これを応用すれば、一つのコードでPHPでもJavaScriptでも通用するコードを作れるではないか。
つまり書くのは一度ですむんだ！ ちなみに互換性が無い部分は関数を使用することで対処できる。
QFの利点はPHPでコードを書くだけでJavaScriptの
エラーチェックに変換してくれる。つまりエラーチェックコードを二度書かなくていいことにあるわけだが、
そのためにはaddRuleメソッドでrequiredを設定するというコードを書く必要がある。
そう、PHPのエラーチェックコードではなく、
フォームに、requiredなどの属性を設定するわけだ。
だから複雑なエラーチェックがやりにくい。
そこでだ、PHPコードそのものでエラーチェックできたら良いとは思わないか？
たとえば、if ( $value == "") {return false;} こういう感じだ。
しかしこのコードをよく見てほしい。なんとそのままでJavaScriptコードとしても通用してしまうのだ！
これを応用すれば、一つのコードでPHPでもJavaScriptでも通用するコードを作れるではないか。
つまり書くのは一度ですむんだ！ ちなみに互換性が無い部分は関数を使用することで対処できる。
>>598
画面を書き換えずにxmlなりjsonなりのデータだけをやりとりすることで
転送量を減らすことができる
それもまたajax。
まあJSチェックをサーバプログラムと別に書くのは基本的にダサい方法だが
十分に抽象化して自動生成するならクリーンにもなりうるな。
書くのは面倒くさそうだが。
画面を書き換えずにxmlなりjsonなりのデータだけをやりとりすることで
転送量を減らすことができる
それもまたajax。
まあJSチェックをサーバプログラムと別に書くのは基本的にダサい方法だが
十分に抽象化して自動生成するならクリーンにもなりうるな。
書くのは面倒くさそうだが。
> 画面を書き換えずにxmlなりjsonなりのデータだけをサーバーとデータを転送してやりとりすることで
> 転送量を減らすことができる
あふぉか？ｗ
> 転送量を減らすことができる
あふぉか？ｗ
なんか文脈なしに非ajax的js過剰に擁護してんの一人だろ
もういいからどっかへ行けよ。スレ違いすぎる
もういいからどっかへ行けよ。スレ違いすぎる
>>607
xmlやjsonってサーバーと通信するだろ普通。
そりゃサーバーと通信しないで使えないことも無いだろうけどさ、
何のためにxmlやjsonに変換するのかって話。
JavaScriptのオブジェクトそのままでいいじゃんか。
xmlやjsonってサーバーと通信するだろ普通。
そりゃサーバーと通信しないで使えないことも無いだろうけどさ、
何のためにxmlやjsonに変換するのかって話。
JavaScriptのオブジェクトそのままでいいじゃんか。
必死です
>>609
AjaxもJavaScriptも同じもんだろ・・・
AjaxもJavaScriptも同じもんだろ・・・
更に必死です
みなさん。反論できないのがどっちかはいわなくてもわかるよね？
互いに話が食い違ってるように見える
そりゃ、「AjaxとかXMLとかJSONとかとりあえず関係ありそうな言葉を並べてみました。
でも意味はよくわかっていません。なにが間違っているというのですか？」な
素人が混じっているんだから無理ないなｗ
でも意味はよくわかっていません。なにが間違っているというのですか？」な
素人が混じっているんだから無理ないなｗ
いや、一人でやってるように見える
レスを見たくないのなら自分が消えるしか方法はありません。
なーんでそんなに相手を論破しようとがんばっちゃうのかね
正直自前でやった方がPHPもJSもHTMLもすっきりすると思うんだが。
QF使ったソースって見辛くね？
QF使ったソースって見辛くね？
通信回数と転送量を一緒にして、区別できていないようだな。
転送量が同じでも、PHPを1回呼ぶのと10回呼ぶのでは、
サーバーの負荷（主にCPU）が異なる。
ajax利用では、転送量よりも通信回数が意識されるところ。
転送量が同じでも、PHPを1回呼ぶのと10回呼ぶのでは、
サーバーの負荷（主にCPU）が異なる。
ajax利用では、転送量よりも通信回数が意識されるところ。
>>623
なんでそんな当たり前のこと言ったん
なんでそんな当たり前のこと言ったん
でもそんなの関係ねぇ！
∩＿＿＿∩
ノ ヽ /⌒)
/⌒) (ﾟ) (ﾟ) |／ ／ はい
/ / ( _●_) ミ／ オッパッピー
.（ ヽ |∪| ／
＼ ヽノ /
＿＿＿ / /
（＿＿＿＿＿ /
＼ ＼
) )
（ ＼
＼＿)
ノ ヽ /⌒)
/⌒) (ﾟ) (ﾟ) |／ ／ はい
/ / ( _●_) ミ／ オッパッピー
.（ ヽ |∪| ／
＼ ヽノ /
＿＿＿ / /
（＿＿＿＿＿ /
＼ ＼
) )
（ ＼
＼＿)
oreoreFW作ってるんだが
クラス名の命名規則からファイルの位置が決まるようにするのと
ﾁﾝﾎﾟﾆｰのように事前にサーチして
クラスファイル位置のインデックスを作っておくの
どっちがベター？
クラス名の命名規則からファイルの位置が決まるようにするのと
ﾁﾝﾎﾟﾆｰのように事前にサーチして
クラスファイル位置のインデックスを作っておくの
どっちがベター？
テトリスでも作ってんの？
作っていませんが何の関係があるんですかねぇ？
∩＿＿＿∩
ノ ヽ /⌒)
/⌒) (ﾟ) (ﾟ) |／ ／ はい
/ / ( _●_) ミ／ PHP
.（ ヽ |∪| ／
＼ ヽノ /
＿＿＿ / /
（＿＿＿＿＿ /
＼ ＼
) )
（ ＼
＼＿)
ノ ヽ /⌒)
/⌒) (ﾟ) (ﾟ) |／ ／ はい
/ / ( _●_) ミ／ PHP
.（ ヽ |∪| ／
＼ ヽノ /
＿＿＿ / /
（＿＿＿＿＿ /
＼ ＼
) )
（ ＼
＼＿)
今まで読んできたけど
少なくとも
>>598
> >>596
> > ajaxで転送量減らすこともできるよ
> 転送を伴わないAjaxってJavaScriptと同じことだろｗ
こいつは馬鹿な素人だと言うことはわかった
少なくとも
>>598
> >>596
> > ajaxで転送量減らすこともできるよ
> 転送を伴わないAjaxってJavaScriptと同じことだろｗ
こいつは馬鹿な素人だと言うことはわかった
あと、これもアフォですね
>>623
> 通信回数と転送量を一緒にして、区別できていないようだな。
> 転送量が同じでも、PHPを1回呼ぶのと10回呼ぶのでは、
> サーバーの負荷（主にCPU）が異なる。
> ajax利用では、転送量よりも通信回数が意識されるところ。
多分自分の中のAJAXの利用方法しか思いつかないからこういう発言になっちゃうん
だろうけど
>>623
> 通信回数と転送量を一緒にして、区別できていないようだな。
> 転送量が同じでも、PHPを1回呼ぶのと10回呼ぶのでは、
> サーバーの負荷（主にCPU）が異なる。
> ajax利用では、転送量よりも通信回数が意識されるところ。
多分自分の中のAJAXの利用方法しか思いつかないからこういう発言になっちゃうん
だろうけど
Ajax = Asynchronous JavaScript + XML だ。
JavaScriptの一種に過ぎないんだよ。 よく覚えとけ。
JavaScriptの一種に過ぎないんだよ。 よく覚えとけ。
ははーん
ずっと当たり前のことを言うという新手の釣りだな
ずっと当たり前のことを言うという新手の釣りだな
引用だけして罵倒とか、実のあるレスがほとんどねぇ。
もう2chのレベルは初心者おしえて掲示板と変わらんがな。
それでいて口は悪いんだから最悪というか・・・。
もう2chのレベルは初心者おしえて掲示板と変わらんがな。
それでいて口は悪いんだから最悪というか・・・。
583 名前：nobodyさん[sage] 投稿日：2007/08/26(日) 05:59:51 ID:???
JSでチェックするメリットはあんまりないよな
ajaxでやるならともかく
こいつもあふぉだな。
AJAXで使われている言語はJavaScriptのだってーの。
JSでチェックするメリットはあんまりないよな
ajaxでやるならともかく
こいつもあふぉだな。
AJAXで使われている言語はJavaScriptのだってーの。
もう釣りなのか馬鹿なのか分からなくなってきた
混沌としすぎ
混沌としすぎ
ajaxでチェックするってどういう意味だろ？
ajaxならかっこいい画面になる？
否 ajaxだからといってかっこよくなるわけでもないし、
javascriptでもかっこよく作れる。
ajaxならダサい標準のダイアログボックスがでない？
否 ajaxでも基本は標準のダイアログボックスだし
javascriptでも標準のダイアログボックス以外を使える。
たぶん、チェックをクライアントコードじゃなくて、
サーバーに問い合わせてやるといいたいんだろうけどさ、
そんなことしたら、サーバーと通信する分遅くなるじゃん？
ajaxならかっこいい画面になる？
否 ajaxだからといってかっこよくなるわけでもないし、
javascriptでもかっこよく作れる。
ajaxならダサい標準のダイアログボックスがでない？
否 ajaxでも基本は標準のダイアログボックスだし
javascriptでも標準のダイアログボックス以外を使える。
たぶん、チェックをクライアントコードじゃなくて、
サーバーに問い合わせてやるといいたいんだろうけどさ、
そんなことしたら、サーバーと通信する分遅くなるじゃん？
サーバーに通信しないとチェックできない項目もある。
メアドが登録済みかどうかとか。
メアドが登録済みかどうかとか。
俺が少し整理してみる。
1)クライアントサイドのみのJavaScriptチェック
入力不足や間違いを即座に指摘できる。
2)Ajaxでサーバサイドをも巻き込んだチェック
1.の発展版。サーバサイドでしかチェックできないような項目を即座に指摘できる。
3)サーバサイドチェック
最終チェック。これは必須。
1や2は利用者の操作性をうｐする。うまく作りこめば確認画面は要らないかも。
1)クライアントサイドのみのJavaScriptチェック
入力不足や間違いを即座に指摘できる。
2)Ajaxでサーバサイドをも巻き込んだチェック
1.の発展版。サーバサイドでしかチェックできないような項目を即座に指摘できる。
3)サーバサイドチェック
最終チェック。これは必須。
1や2は利用者の操作性をうｐする。うまく作りこめば確認画面は要らないかも。
もうみんな閲覧条件としてJavaScript必須前提なのか。
何というwhile(1)な流れ
はいはい。もうそのQFのJS自動生成の話いいから。
スレ違いだつーのに。
スレ違いだつーのに。
逃げたｗ
フレームワークがjsの自動生成までカバーするべきか否かにも繋がるので、あながちスレ違いというわけでも。
QFもフレームワークと言えばフレームワークだよね。
フォーム処理に特化した。
QFもフレームワークと言えばフレームワークだよね。
フォーム処理に特化した。
symfonyとAkelosを比べた場合お勧めはどっちだろう。
誰か両方使ってみた。な人いる？
誰か両方使ってみた。な人いる？
PHP5で完全なMVC構造を維持してるコードが少ないフレームワークが欲しい
PHP5で完全なMVC構造を維持してるコードがないフレームワークが欲しい
完璧なMVCというものがそもそも存在しなくね？
インターフェイス間でやりとりするんだから少し混じり合うよ
インターフェイス間でやりとりするんだから少し混じり合うよ
さらに、その比較をどこかのwikiにでも書いてくれたら嬉しいかな。
pieceでsubmitボタンじゃなくて、一般ボタンを使用してonClickイベントで
jsからサブミットさせても動かないんだけどなぜ？
jsからサブミットさせても動かないんだけどなぜ？
PEARやってみたんだけど、
フレームワークも似たようなもん？
ほしいクラスのあるスクリプトをインクルードして
それを使うってな感じでおｋ？
フレームワークも似たようなもん？
ほしいクラスのあるスクリプトをインクルードして
それを使うってな感じでおｋ？
おまえが呼ぶように書くのはライブラリ
呼ばれる部分を書くのがフレームワーク
まあフレームワークは大体ライブラリの側面も含んでるけど
呼ばれる部分を書くのがフレームワーク
まあフレームワークは大体ライブラリの側面も含んでるけど
>>656
そんなレベルではまだはやい。フレームワークも知る必要もない。
そんなレベルではまだはやい。フレームワークも知る必要もない。
チュートリアルが何かわからないので0割習得！
フレームワークを変更した人とかいるかな
今使っているフレームワークが変えても動くように設計していたりする?
ビジネスモデルはクラスとか作っておけばいいけど、viewは結構移植が難しいかな
今使っているフレームワークが変えても動くように設計していたりする?
ビジネスモデルはクラスとか作っておけばいいけど、viewは結構移植が難しいかな
>>662
気持ちはわかるけど、やめておけ。ろくなことにならない。
気持ちはわかるけど、やめておけ。ろくなことにならない。
>>662
できたら公開してね
できたら公開してね
意味あるのかないのか良く分からん。
ここにいるぺちぱーでセミナーとか勉強会行ってる人いる？
勉強会とか行きまくってたひとが作ったフレームワークからsymfonyに移す作業を今やってる。
ビジネスロジックは可能な限りフレームワーク依存を避けたんでほとんど手付かずでよかったが
ViewはSmartyから生PHPに変更だーね。
でも逆方向の移植よりは作業は難しくないと思う。より何でもできる側への移植だし。
まぁサイトデザインリニューアルだから今回はそれは大した問題ではないが。
DaoをDB_DataObjectからpropelにする作業がいちばん面倒くさい気がする……
これもあらかじめラッパ1枚挟んでおいてたからまだ楽な方だとは思うけど。
ビジネスロジックは可能な限りフレームワーク依存を避けたんでほとんど手付かずでよかったが
ViewはSmartyから生PHPに変更だーね。
でも逆方向の移植よりは作業は難しくないと思う。より何でもできる側への移植だし。
まぁサイトデザインリニューアルだから今回はそれは大した問題ではないが。
DaoをDB_DataObjectからpropelにする作業がいちばん面倒くさい気がする……
これもあらかじめラッパ1枚挟んでおいてたからまだ楽な方だとは思うけど。
何の話？
もはやJavaでいいじゃないかと思えるレベルの手間だな。
DBの操作がし易いFWないかな？
$array['field1'] = "テスト１";
$array['field2'] = "テスト２";
$array['field3'] = "テスト３";
を簡単に
INSERT SET field1,field2,field3 VALUES('テスト１','テスト２','テスト３')
みたいな感じにして実行してくれるのが嬉しいんだが・・・
ってこれくらいならfunctionでいけるかな
$array['field1'] = "テスト１";
$array['field2'] = "テスト２";
$array['field3'] = "テスト３";
を簡単に
INSERT SET field1,field2,field3 VALUES('テスト１','テスト２','テスト３')
みたいな感じにして実行してくれるのが嬉しいんだが・・・
ってこれくらいならfunctionでいけるかな
1回でおk
>>671
DAOでぐぐれとかそういう
DAOでぐぐれとかそういう
>>673
zendがやってたきがす
zendがやってたきがす
676 ：nobodyさん：2007/09/07(金) 17:35:52 ID:AJh2IEJ8
フレームワークっぽくはないけどrhacoが気になる
>>671
MDB2のautoExecute()とか。
MDB2のautoExecute()とか。
>>671
どんなFWでも出来ると思うが、それ以前に、
$array = array('field1'=>'テスト1,'field2'=>'テスト2,'field3'=>'テスト3,);
という書き方を知っているか？
どんなFWでも出来ると思うが、それ以前に、
$array = array('field1'=>'テスト1,'field2'=>'テスト2,'field3'=>'テスト3,);
という書き方を知っているか？
680 ：nobodyさん：2007/09/07(金) 21:29:31 ID:dCrM/XyG
ブログシステム的なものを作るのに、Django使いには何がお勧めですかね?
てか、もうフレームワークにしなくても
独自で作った関数・クラスを使いまくるので、よくねぇ？
独自で作った関数・クラスを使いまくるので、よくねぇ？
それはライブラリじゃね？
PHP at Yahoo! JAPAN
http://searchblog.yahoo.co.jp/2007/09/php_at_yahoo_japan.html
日本のYahoo!でも使っているようだし、フレームワークの本命は、やはりsymfonyかな。
http://searchblog.yahoo.co.jp/2007/09/php_at_yahoo_japan.html
日本のYahoo!でも使っているようだし、フレームワークの本命は、やはりsymfonyかな。
php.netってyahooが提供してたのか・・・知らんかった
てか、GoogleもPHP使ってるし、楽天もPHP+MySQLだったはず。
割と有名な大企業で使っているから、もうPHPだけで良い気がする。
割と有名な大企業で使っているから、もうPHPだけで良い気がする。
googleはpythonだろ
Yahooとか楽天とか、バックエンドのコアな処理はみんなJavaだけどな。
確かにフロントではPHPを使ってるけど。
DBも当然オラクルだよ。MySQLなんかじゃ機能も性能も追いつけるわけないじゃん。
確かにフロントではPHPを使ってるけど。
DBも当然オラクルだよ。MySQLなんかじゃ機能も性能も追いつけるわけないじゃん。
やっぱり、まだまだ俺たちには勉強が必要ってことか・・・
googleは数千台のMySQLだろ
>>680
Django使いにはrhacoがオススメだと親分が言っていた
Django使いにはrhacoがオススメだと親分が言っていた
>>692
で、それを指導してたのが若き日のふじもとさんなんだな。
で、それを指導してたのが若き日のふじもとさんなんだな。
ライブラリーとかフレームワーク使ってると
早く完成品が拝める。
でも正直自分が作った気がしないのは俺だけ？
早く完成品が拝める。
でも正直自分が作った気がしないのは俺だけ？
作者が楽天に走ってrubyの印象が悪くなったよな
大手出版社の人が「Ruby on Rails」は一過性のブームで終わったと言ってたな。
たくさん入門書が出たけど、どれも全然売れてないとか。
自分の周りでは、中規模案件を中心に「Beyond Java To PHP」って感じ。
たくさん入門書が出たけど、どれも全然売れてないとか。
自分の周りでは、中規模案件を中心に「Beyond Java To PHP」って感じ。
結構yahooでsymfony使われてることが意外
あれそんなにいいか？
俺もフレームワーク発表してyahooに入社したろか
あれそんなにいいか？
俺もフレームワーク発表してyahooに入社したろか
699 ：nobodyさん：2007/09/08(土) 18:31:05 ID:+ZuhJBWz
701 ：nobodyさん：2007/09/08(土) 21:33:52 ID:+ZuhJBWz
rhaco公式のデザインの悪さには同意せざるを得ない。
ダウンロードして欲しくないかのようなデザイン。
もしそっちのセンスがないのなら、いますぐにでも任せられる人を募るべき。
あのサイトのデザインは、フレームワークを使いはじめた人間が、
なんでもかんでもリストで出力してテンプレートで並べたてるのに酷似している。
（そして、そうなるのもよくわかる。すごく簡単にできるから。）
ダウンロードして欲しくないかのようなデザイン。
もしそっちのセンスがないのなら、いますぐにでも任せられる人を募るべき。
あのサイトのデザインは、フレームワークを使いはじめた人間が、
なんでもかんでもリストで出力してテンプレートで並べたてるのに酷似している。
（そして、そうなるのもよくわかる。すごく簡単にできるから。）
結局フレームワークはどれがいいのよ
だれかそれぞれの特徴とかまとめて
だれかそれぞれの特徴とかまとめて
どれがいいかわからんやつはフレームワークに使われる落ち
大手出版社の売り上げで技術選ぶアホが居るよ
>>697
馬鹿じゃない？
馬鹿じゃない？
でも、言語の部分であまり重い処理とかやらないから関係なくね？
大部分がデータベースの処理とそのI/O速度に依存しているんだし。
大部分がデータベースの処理とそのI/O速度に依存しているんだし。
そこまで速度にこだわるなら、Yahooがやっているようにextension化すればいい。
PHPとはそういうもの。
PHPとはそういうもの。
710 ：nobodyさん：2007/09/09(日) 15:07:33 ID:KH7TY7ET
フレームワークにはいろいろなタイプのものがあるんですね。
MVCパターンというフレームワークと、ステートマシンというフレームワークは、根本的に何か違うんでしょうか？
PHPプロが肩入れしている(?)Piece Frameworkってどうですか？
http://www.phppro.jp/news/415
MVCパターンというフレームワークと、ステートマシンというフレームワークは、根本的に何か違うんでしょうか？
PHPプロが肩入れしている(?)Piece Frameworkってどうですか？
http://www.phppro.jp/news/415
MVCとステートマシンを考慮したフレームワークを作る事ができる。
もうちょっとそれぞれを調べてから質問した方が、話が広がって良い。
もうちょっとそれぞれを調べてから質問した方が、話が広がって良い。
>質問が自分の知識レベルの範囲内で回答できる内容だった場合、
>「そんな事も知らないのか」「そんな事も知らないならこのツールを使うべきではない」
>「少しは努力しろ」等と罵倒するだけで、絶対に回答しない。
>質問が高度すぎて自分の知識レベルでは理解できなかった場合、質問を無視する。
>「そんな事も知らないのか」「そんな事も知らないならこのツールを使うべきではない」
>「少しは努力しろ」等と罵倒するだけで、絶対に回答しない。
>質問が高度すぎて自分の知識レベルでは理解できなかった場合、質問を無視する。
714 ：nobodyさん：2007/09/09(日) 16:14:40 ID:T1ZRLBlB
最大で五倍。多くの場合は変わらない。よくある話。
ちなみにステートマシン・フレームワークがあることを知らなかったのだけど、
これは状態遷移図とそれぞれのアクションを記述するというような理解でいいの？
Javaのフレームワークについて書いた記事しか見てないけど。
まあ、確かにわかりやすそうだし、全ての状態を一目で把握できるというのはよさそう。
MVCでアクションを書いてると際限なく増やせるから、それを管理できなくなるって話はありそうだし。
でも、例えばステートマシンをMVCのコントローラで採用すれば、って話にならないの？
これは状態遷移図とそれぞれのアクションを記述するというような理解でいいの？
Javaのフレームワークについて書いた記事しか見てないけど。
まあ、確かにわかりやすそうだし、全ての状態を一目で把握できるというのはよさそう。
MVCでアクションを書いてると際限なく増やせるから、それを管理できなくなるって話はありそうだし。
でも、例えばステートマシンをMVCのコントローラで採用すれば、って話にならないの？
うーん。
なんかベンチ合戦に巻き込まれてるような気がする。
実装を換えて何倍速くなりましたっていうのは、本来つまらない話のはずなんだけど…。
なんかベンチ合戦に巻き込まれてるような気がする。
実装を換えて何倍速くなりましたっていうのは、本来つまらない話のはずなんだけど…。
Piece Frameworkによるブログアプリケーションの作成
http://gihyo.jp/dev/serial/01/piece
JavaのStrutsみたいなフレームワークなんですかね？
Ruby on Railsもどきとは一味違うタイプなのかな。
煩雑なFWに見えたのは、多分俺が単純な人間だからだと思います。orz
http://gihyo.jp/dev/serial/01/piece
JavaのStrutsみたいなフレームワークなんですかね？
Ruby on Railsもどきとは一味違うタイプなのかな。
煩雑なFWに見えたのは、多分俺が単純な人間だからだと思います。orz
>>720
作者はPoEAA読むのを人にもすすめるほどだから、それは仕方ないだろう。
pearコマンドでインストールというのがまず壁だな。
アーカイブ落として、解凍して、ドキュメントルートにおけば使えるようにして欲しいよ。
作者はPoEAA読むのを人にもすすめるほどだから、それは仕方ないだろう。
pearコマンドでインストールというのがまず壁だな。
アーカイブ落として、解凍して、ドキュメントルートにおけば使えるようにして欲しいよ。
722 ：親分：2007/09/09(日) 23:46:25 ID:uiImO4wM
>>721
YOU! rhacoやっちゃいなYO!
YOU! rhacoやっちゃいなYO!
というより一昔前の設計なだけ
Ruby on Railsがでてから、
一気に世代が変わっちゃったよな。
一気に世代が変わっちゃったよな。
rails使えない環境も多いわけで自社開発でやる気のあるとこ以外はrailsに移行しないきがす。
うちはrails部隊もあるが。phpでほとんど組んでる
うちはrails部隊もあるが。phpでほとんど組んでる
phpにもRails風のフレームワークがいくつかあるじゃん
CakePHP楽だよ。本当に楽。
レンタルサーバーは実際問題PHP5への切り替え断行なんてできるのかな？
4でしか動かないクライアントのスクリプトも相当あるだろうし
それをバッサリ切ると業務に支障をきたして大問題になると思うんだが…
運営各社はいったいどうやって切り抜けるんだろうな
4でしか動かないクライアントのスクリプトも相当あるだろうし
それをバッサリ切ると業務に支障をきたして大問題になると思うんだが…
運営各社はいったいどうやって切り抜けるんだろうな
PHP5の最新版って毎回セキュリティフィックスが山のようにある。セキュリティを考えるならPHP4の最終版を使い続けた方がまし。
つ、釣られないぞ
他の言語使ってたりして、一度例外処理になれてしまうと〜finallyの無いphp5には
戻れなくなるよｗ
戻れなくなるよｗ
4厨必死すぎｗｗｗｗ
736 ：nobodyさん：2007/09/10(月) 16:17:21 ID:oeJv3ute
日本発のフレームワークって徐々に開発が滞る気がするのですが間違った認識ですか?
>>736
大丈夫です、海外の奴も長続きするのは100にひとつもありません。
sf.netへ行って"php framework"してみるとわかります。
単に確率の問題でしょうが、日本初のフレームワークの絶対数がすくないので、
日本だからどうこう、というのを論じるのはまだ早いと思われます。
大丈夫です、海外の奴も長続きするのは100にひとつもありません。
sf.netへ行って"php framework"してみるとわかります。
単に確率の問題でしょうが、日本初のフレームワークの絶対数がすくないので、
日本だからどうこう、というのを論じるのはまだ早いと思われます。
>>736
Kaedeを心待ちにしてた俺に対する挑戦状か？
Kaedeを心待ちにしてた俺に対する挑戦状か？
俺frameworkでやってきたけど、
自分一人で開発することがほとんどなので、間違ってなかった気がする。
自分一人で開発することがほとんどなので、間違ってなかった気がする。
それで済んでるなら間違ってないと思うよ
失礼、なんか煽ってるみたいな文になってしまった
プログラムそのものの美しさを求める趣味人でもない限り、
正しく目的を達成できるなら俺FWでもSymfonyでも国産FWでも同列だろう、
って意味で。間違ってないと思うよ。
プログラムそのものの美しさを求める趣味人でもない限り、
正しく目的を達成できるなら俺FWでもSymfonyでも国産FWでも同列だろう、
って意味で。間違ってないと思うよ。
PHP総受け
744 ：nobodyさん：2007/09/11(火) 03:26:25 ID:fZWv6wPR
Zend Framework 本
http://www.sotechsha.co.jp/pc/html/593.htm
http://www.sotechsha.co.jp/pc/html/593.htm
>>745 昔そう思ったのですがネットで日本語訳が既に入手できる上に
貰える印税が通常よりも少ないのでやらないでしょう。
貰える印税が通常よりも少ないのでやらないでしょう。
中身まで薄そうな本だな
748 ：744：2007/09/11(火) 18:56:13 ID:fZWv6wPR
Zendなんてまだ安定してないのに
よく本なんか出すよなｗ
よく本なんか出すよなｗ
Zend_Pdfは結局正式リリースになってもマルチバイト無視だったしな。
びっくりするほど完成度が低い。
びっくりするほど完成度が低い。
一人で作ってるから仕方ない
pdfなんてコアな部分でもないしな
zendは流行らない気がするよ。
フレームワークとしてははやらないかもな
zendは使ってる人も一人
Zendはライブラリ的に使えるのかなと思ったら、
requireがどこかに飛んでいく・・・
requireがどこかに飛んでいく・・・
飛んでるのおまえのZendだけだぞ
はい ｵｯﾊﾟｯﾋﾟｰ(^o^)／
小島よしろ24時間テレビ事件についていまごろ知った、、
このスレがこんな寂れるとは何事だ。
このスレはけっこう浮き沈み激しいからな
自作MVCフレームワーク作ってみた。
MVC分離だけやってるが、ちょっと勉強になった。
MVC分離だけやってるが、ちょっと勉強になった。
763 ：nobodyさん：2007/09/23(日) 22:53:51 ID:gK2i0s5m
>>762
公開しる
公開しる
http://www.amazon.co.jp/gp/product/4881665936
↑この本の著者の藤野って元有限会社アームワークス社長の藤野やん。ｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
しかもコンピュータ総合学園HAL(大阪)の卒業生且つ非常勤講師ってのは皆知ってる？
↑この本の著者の藤野って元有限会社アームワークス社長の藤野やん。ｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
しかもコンピュータ総合学園HAL(大阪)の卒業生且つ非常勤講師ってのは皆知ってる？
宣伝乙
http://slashdot.jp/articles/07/09/23/2357202.shtml
RoRからPHPへの逆流開始でRuby脂肪ｗｗｗ
RoRからPHPへの逆流開始でRuby脂肪ｗｗｗ
>>743
ワロタｗ
ワロタｗ
768 ：nobodyさん：2007/09/24(月) 22:47:17 ID:JlRJpJ4M
JavaでMVCモデルに慣れてたからSmartyは便利だね。
PHPは何でも気軽に作れて簡単でいい言語だよ。
PHPは何でも気軽に作れて簡単でいい言語だよ。
>>766 原文をよく読んでみな。自分がしたいことをするために適切なツールを選ぶことの大切さと
Railsを勉強したおかげでPHPできれいなコードを書けるようになったと書いてあるよ。
Railsを勉強したおかげでPHPできれいなコードを書けるようになったと書いてあるよ。
そりゃ2年も費やしたらそれくらい学べるだろ・・・Railsがなくても
rorに限らず、他の言語とかテクニックとか思想とか
しっとくのは幅が広がるわね
しっとくのは幅が広がるわね
,. -‐'''''""¨¨¨ヽ
(.＿＿_,,,... -ｧァﾌ| あ…ありのまま 今 起こった事を話すぜ！
|i i| }! }} /／|
|l､{ j} /,,ｨ//｜ 『おれは30分でアプリが作れると
i|:!ヾ､_ﾉ／ u {:}//ﾍ 思ったらいつのまにか2年かかってもできてなかった』
|ﾘ u' } ,ﾉ _,!V,ﾊ |
／´fト､_{ﾙ{,ィ'ｅﾗ , ﾀ人 な… 何を言ってるのか わからねーと思うが
/' ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ おれも何をされたのかわからなかった…
,ﾞ ／ )ヽ iLﾚ u' | | ヾｌﾄﾊ〉
|／_／ ﾊ !ニ⊇ '／:} V:::::ヽ 頭がどうにかなりそうだった…
/／ 二二二7'T'' ／u' __ /:::::::/｀ヽ
/'´r -―一ｧ‐ﾞＴ´ '"´ ／::::／-‐ ＼ 時間の無駄だとか出来る出来る詐欺だとか
/ // 广¨´ /' ／:::::／´￣｀ヽ ⌒ヽ そんなチャチなもんじゃあ 断じてねえ
ﾉ ' / ノ:::::`ー-､___／:::::／/ ヽ }
_／｀丶 /::::::::::::::::::::::::::￣`ー-{:::... ｲ もっと恐ろしいものの片鱗を味わったぜ…
(.＿＿_,,,... -ｧァﾌ| あ…ありのまま 今 起こった事を話すぜ！
|i i| }! }} /／|
|l､{ j} /,,ｨ//｜ 『おれは30分でアプリが作れると
i|:!ヾ､_ﾉ／ u {:}//ﾍ 思ったらいつのまにか2年かかってもできてなかった』
|ﾘ u' } ,ﾉ _,!V,ﾊ |
／´fト､_{ﾙ{,ィ'ｅﾗ , ﾀ人 な… 何を言ってるのか わからねーと思うが
/' ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ おれも何をされたのかわからなかった…
,ﾞ ／ )ヽ iLﾚ u' | | ヾｌﾄﾊ〉
|／_／ ﾊ !ニ⊇ '／:} V:::::ヽ 頭がどうにかなりそうだった…
/／ 二二二7'T'' ／u' __ /:::::::/｀ヽ
/'´r -―一ｧ‐ﾞＴ´ '"´ ／::::／-‐ ＼ 時間の無駄だとか出来る出来る詐欺だとか
/ // 广¨´ /' ／:::::／´￣｀ヽ ⌒ヽ そんなチャチなもんじゃあ 断じてねえ
ﾉ ' / ノ:::::`ー-､___／:::::／/ ヽ }
_／｀丶 /::::::::::::::::::::::::::￣`ー-{:::... ｲ もっと恐ろしいものの片鱗を味わったぜ…
しかし2ヶ月でできるものを2年かかってできなかったなんて、
言語やフレームワークを語る以前にエンジニアとして駄目な気がする・・・
そんなんRubyどころかCでも1年もあればできそうなもんだがw
言語やフレームワークを語る以前にエンジニアとして駄目な気がする・・・
そんなんRubyどころかCでも1年もあればできそうなもんだがw
レールから脱線して走ろうとしたらそんなことになるんじゃね
ないとは言えないな
賢くあろうとして泥沼にはまることはむしろよくあることかも・・・
ないとは言えないな
賢くあろうとして泥沼にはまることはむしろよくあることかも・・・
フレームワーク病だな
,. -‐'''''""¨¨¨ヽ
(.＿＿_,,,... -ｧァﾌ| あ…ありのまま 今 起こった事を話すぜ！
|i i| }! }} /／|
|l､{ j} /,,ｨ//｜ 『おれは10分でアプリが作れると聞いたから使った。
i|:!ヾ､_ﾉ／ u {:}//ﾍ なのにできたのはアプリとは思えないものだった。』
|ﾘ u' } ,ﾉ _,!V,ﾊ |
／´fト､_{ﾙ{,ィ'ｅﾗ , ﾀ人 な… 何を言ってるのか わからねーと思うが
/' ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ おれも何を作ったかわからなかった…
,ﾞ ／ )ヽ iLﾚ u' | | ヾｌﾄﾊ〉
|／_／ ﾊ !ニ⊇ '／:} V:::::ヽ 頭がどうにかなりそうだった…
/／ 二二二7'T'' ／u' __ /:::::::/｀ヽ
/'´r -―一ｧ‐ﾞＴ´ '"´ ／::::／-‐ ＼ デザインに調整が要るとか、インターフェースが使いにくいとか
/ // 广¨´ /' ／:::::／´￣｀ヽ ⌒ヽ 実用的なアプリはそんなチャチなもんじゃあ 断じてねえ
ﾉ ' / ノ:::::`ー-､___／:::::／/ ヽ }
_／｀丶 /::::::::::::::::::::::::::￣`ー-{:::... ｲ もっと恐ろしいものの片鱗を味わったぜ…
(.＿＿_,,,... -ｧァﾌ| あ…ありのまま 今 起こった事を話すぜ！
|i i| }! }} /／|
|l､{ j} /,,ｨ//｜ 『おれは10分でアプリが作れると聞いたから使った。
i|:!ヾ､_ﾉ／ u {:}//ﾍ なのにできたのはアプリとは思えないものだった。』
|ﾘ u' } ,ﾉ _,!V,ﾊ |
／´fト､_{ﾙ{,ィ'ｅﾗ , ﾀ人 な… 何を言ってるのか わからねーと思うが
/' ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ おれも何を作ったかわからなかった…
,ﾞ ／ )ヽ iLﾚ u' | | ヾｌﾄﾊ〉
|／_／ ﾊ !ニ⊇ '／:} V:::::ヽ 頭がどうにかなりそうだった…
/／ 二二二7'T'' ／u' __ /:::::::/｀ヽ
/'´r -―一ｧ‐ﾞＴ´ '"´ ／::::／-‐ ＼ デザインに調整が要るとか、インターフェースが使いにくいとか
/ // 广¨´ /' ／:::::／´￣｀ヽ ⌒ヽ 実用的なアプリはそんなチャチなもんじゃあ 断じてねえ
ﾉ ' / ノ:::::`ー-､___／:::::／/ ヽ }
_／｀丶 /::::::::::::::::::::::::::￣`ー-{:::... ｲ もっと恐ろしいものの片鱗を味わったぜ…
PHPのフレームワークはどれもDBまわりがヘボいな
だからフレームワークなんて使う奴が馬鹿だって前から言ってるじゃん
フレームワーク厨プギャー
フレームワーク厨プギャー
んー、まずウェブアプリ作る上で言語は決定的なファクターにはならないんだよな。Cで書こうがRubyで書こうが、出来ることはPHPで書くのと同じなんだから。
まあ、確かにPHPの言語仕様はしょぼいけど、その分開発メンバーを集めやすいというメリットはある。
あとRailsのせいでウェブフレームワークにはORマッパーが当たり前みたいな風潮が出来たけど、別にORマッパーなんてなくてもいい。
手軽で便利ではあるけど、SQLの知識が十分あれば普通にDAOクラスを書く方が効率のよい処理になる。長短あるから、適材適所だな。
まあ、確かにPHPの言語仕様はしょぼいけど、その分開発メンバーを集めやすいというメリットはある。
あとRailsのせいでウェブフレームワークにはORマッパーが当たり前みたいな風潮が出来たけど、別にORマッパーなんてなくてもいい。
手軽で便利ではあるけど、SQLの知識が十分あれば普通にDAOクラスを書く方が効率のよい処理になる。長短あるから、適材適所だな。
フレームワーク使って作業効率が上がるわけがない
オブジェクト指向言語で作る場合、O/Rマッパーは必須だよな。
フレームワークは作業効率が上がる。
なぜなら、フレームワークに相当する部分を
自分で作らなくていいからだ。
フレームワークは作業効率が上がる。
なぜなら、フレームワークに相当する部分を
自分で作らなくていいからだ。
なんでそんな今更なところまで話が立ち返っちゃってんの？
CakePHPってフレームワーク使っているけど、
ORマッパーはやっぱり便利だよ。
オブジェクトに変換してくれるのも便利だけど、
where条件をオブジェクト（配列）で指定できるのがいい。
たとえば、where a=1 and (b=2 or c=3) and d like '%4%' and e in(5,6,7) なんて文は
array(
'a'=>1,
'OR' => array('b' => 2, 'c'=>3),
'd' => 'LIKE %4%',
'e' => array(5,6,7)
)
とより直感的に作れる。（テストしないで書いたんで間違っていたらすまん）
whereの文が固定で値だけが変わるなら、"where a=$a and ・・・" って
直接書いてもいいけど、条件によって文自体が変わる場合の
くだらない文字列演算によるバグ（スペースが足りなかったり）に惑わされる必要もない。
SQLの知識があるかどうかじゃないんだよね。
くだならいケアミス（こんなの知識と関係ない）が大幅に減ることが重要。
ORマッパーはやっぱり便利だよ。
オブジェクトに変換してくれるのも便利だけど、
where条件をオブジェクト（配列）で指定できるのがいい。
たとえば、where a=1 and (b=2 or c=3) and d like '%4%' and e in(5,6,7) なんて文は
array(
'a'=>1,
'OR' => array('b' => 2, 'c'=>3),
'd' => 'LIKE %4%',
'e' => array(5,6,7)
)
とより直感的に作れる。（テストしないで書いたんで間違っていたらすまん）
whereの文が固定で値だけが変わるなら、"where a=$a and ・・・" って
直接書いてもいいけど、条件によって文自体が変わる場合の
くだらない文字列演算によるバグ（スペースが足りなかったり）に惑わされる必要もない。
SQLの知識があるかどうかじゃないんだよね。
くだならいケアミス（こんなの知識と関係ない）が大幅に減ることが重要。
それO/Rマッパというよりクエリビルダ寄りな話だな
言いたい事はわかるが
言いたい事はわかるが
(1) SQL自分で書く
↓
(2) DB抽象化レイヤは現状欠かせない
↓
(3) プレースホルダと自動エスケープ機能が欲しくなる
↓
(4) どうせならクエリビルダ化
↓
(5) だったら実行結果も自動でORM
下に行くほど書くの楽になるけど自由度が減る（特例に対処しにくくなる）ので
ときどき上に登りたくなるが
それでも(3)より上には行く気しないなぁ
↓
(2) DB抽象化レイヤは現状欠かせない
↓
(3) プレースホルダと自動エスケープ機能が欲しくなる
↓
(4) どうせならクエリビルダ化
↓
(5) だったら実行結果も自動でORM
下に行くほど書くの楽になるけど自由度が減る（特例に対処しにくくなる）ので
ときどき上に登りたくなるが
それでも(3)より上には行く気しないなぁ
Railsで言ってるみたいに10分でウェブアプリを作りたいならORマッパーがいいだろう。が、現実的にはそんな要求はほとんどない。
(3) って prepared statement と何が違うの?
違わないんじゃない？
>>785あたりについて詳しい解説してる本やサイトってあるかな。
hibernateのドキュメント読めば？
>>783
その配列本当？
CakePHPはソース見た程度で使ったこと無いが、その程度の
Criteriaしかないならうんこだな。
ORMにJOINまでの複雑さは求めないけど、その配列じゃすぐ破綻する。
その配列本当？
CakePHPはソース見た程度で使ったこと無いが、その程度の
Criteriaしかないならうんこだな。
ORMにJOINまでの複雑さは求めないけど、その配列じゃすぐ破綻する。
俺はORマッパー使い辛い派なんだけど、その配列が直感的だとはとても思えない。
ケアレスミスも防げるとは全く思えない。SQLで書けば、別でテストも出来るし。
逆にミスが増えそう。パッと見何やってるのか解りつらい（慣れだろうけど）。
また、JOIN使おうとすると、とたんに面倒になる＆解りにくくなる印象がある。
というか、結合を使わないSQL文を発行することって、ほとんどないと思う。
他人に処理を教える時も、SQL文で書いてる方が教えやすいしね。
同じような理由で、SymfonyのJavascript系のHelperも使ってないな。
ケアレスミスも防げるとは全く思えない。SQLで書けば、別でテストも出来るし。
逆にミスが増えそう。パッと見何やってるのか解りつらい（慣れだろうけど）。
また、JOIN使おうとすると、とたんに面倒になる＆解りにくくなる印象がある。
というか、結合を使わないSQL文を発行することって、ほとんどないと思う。
他人に処理を教える時も、SQL文で書いてる方が教えやすいしね。
同じような理由で、SymfonyのJavascript系のHelperも使ってないな。
>>791 >>793
とりあえず、もう少し勉強してからレスしてくれんか？
使ったこと無くて否定している感がでているんだが。
CakePHPはあれだけしかできない。JOINは複雑。根拠なしで思い込みで言っちゃってるでしょ？
当たり前だが、あれがすべてじゃないよ。というかORマッパーと
あまり関係ない検索条件の話。SQLインジェクション対策も考えながら、
文字列を組み立てるよりもデータとして扱ったほうが楽。
後から条件を編集するのも楽。そういう話。JOINの話はしていない。
JOINは本質的には検索条件と関係ない話だってのはわかるね？
where句にJOINの条件を書くこともあるけど、本当は、ONの後に書いたほうがいい。
select * from a left join b on (a.id = b.a_id) where 〜検索条件〜
見てのとおり検索条件とJOINは関係ない。
さてCakePHPでのJOINだが、これ知るときっと衝撃を受けるんじゃないのかな？
複雑どころか、なんと書く必要すらない。
まあ、何もないところからJOINがでてくるわけないので何かの情報は
必要なわけだが、ER図で、1対1とか1対多とか多対多とか定義するでしょ？
あの情報を、このテーブルは他のテーブルとどういう関係にあると書くだけ。
あとは一つのテーブルの情報を取り出すと、それに関連付けられたテーブルを勝手にJOINしてくれる。
勝手にJOINするということは必要ないところまでJOINしてパフォーマンスが落ちるって考えた？
そういうものはちゃんとはずしたり、またあとから付け加えたりできるから問題ない。
たしかに、ORマッパーで扱いににくい、扱えないテーブルはあるだろう。
が、そういうのは例外。例外に対応するために直接SQLも発行できるから問題ない。
とりあえず、もう少し勉強してからレスしてくれんか？
使ったこと無くて否定している感がでているんだが。
CakePHPはあれだけしかできない。JOINは複雑。根拠なしで思い込みで言っちゃってるでしょ？
当たり前だが、あれがすべてじゃないよ。というかORマッパーと
あまり関係ない検索条件の話。SQLインジェクション対策も考えながら、
文字列を組み立てるよりもデータとして扱ったほうが楽。
後から条件を編集するのも楽。そういう話。JOINの話はしていない。
JOINは本質的には検索条件と関係ない話だってのはわかるね？
where句にJOINの条件を書くこともあるけど、本当は、ONの後に書いたほうがいい。
select * from a left join b on (a.id = b.a_id) where 〜検索条件〜
見てのとおり検索条件とJOINは関係ない。
さてCakePHPでのJOINだが、これ知るときっと衝撃を受けるんじゃないのかな？
複雑どころか、なんと書く必要すらない。
まあ、何もないところからJOINがでてくるわけないので何かの情報は
必要なわけだが、ER図で、1対1とか1対多とか多対多とか定義するでしょ？
あの情報を、このテーブルは他のテーブルとどういう関係にあると書くだけ。
あとは一つのテーブルの情報を取り出すと、それに関連付けられたテーブルを勝手にJOINしてくれる。
勝手にJOINするということは必要ないところまでJOINしてパフォーマンスが落ちるって考えた？
そういうものはちゃんとはずしたり、またあとから付け加えたりできるから問題ない。
たしかに、ORマッパーで扱いににくい、扱えないテーブルはあるだろう。
が、そういうのは例外。例外に対応するために直接SQLも発行できるから問題ない。
それをせけんじゃORMと呼んでるんだが・・・
そんなことわかっているが？
ORMとしてクエリビルダなんてORMとはまったく対極の説明初めて、
Cakeダサいって言われて、ORMの基本の説明始めたから。
わかってるならいいんだ。
Cakeダサいって言われて、ORMの基本の説明始めたから。
わかってるならいいんだ。
仕方ないだろ。俺は元々（ORMも便利だが）クエリビルダも便利だよって
話をしているのに、JOINというクエリビルダではなく
ORMに関係する話を持ち出してきてダサイ（しかも根拠無し）とか言い出したんだから。
ところで、こういう感じの良く考え抜かれたクエリビルダって
CakePHP特有のものなの？ ORMでは一般的なものだと思っていたから持ち出したんだけど。
だとしたらCakePHPってすごいな。
話をしているのに、JOINというクエリビルダではなく
ORMに関係する話を持ち出してきてダサイ（しかも根拠無し）とか言い出したんだから。
ところで、こういう感じの良く考え抜かれたクエリビルダって
CakePHP特有のものなの？ ORMでは一般的なものだと思っていたから持ち出したんだけど。
だとしたらCakePHPってすごいな。
> ORMとしてクエリビルダなんてORMとはまったく対極の説明初めて、
別に対極の話じゃないと思うけどね。
条件をSQL文字列ではなくオブジェクトで指定できるわけだから。
一旦>>783のオブジェクトから、SQL文字列を生成して
それを基にクエリーするわけじゃないよ。
あれ自体が、検索条件オブジェクト。
クエリーするときにあのオブジェクトを引数にいれて呼び出せばいい。
（当然内部でSQL文字列に変換しているわけだが）
別に対極の話じゃないと思うけどね。
条件をSQL文字列ではなくオブジェクトで指定できるわけだから。
一旦>>783のオブジェクトから、SQL文字列を生成して
それを基にクエリーするわけじゃないよ。
あれ自体が、検索条件オブジェクト。
クエリーするときにあのオブジェクトを引数にいれて呼び出せばいい。
（当然内部でSQL文字列に変換しているわけだが）
> ところで、こういう感じの良く考え抜かれたクエリビルダって
> CakePHP特有のものなの？ ORMでは一般的なものだと思っていたから持ち出したんだけど。
> だとしたらCakePHPってすごいな。
Railsのパクリ。もちろんそれが悪いわけではない
> CakePHP特有のものなの？ ORMでは一般的なものだと思っていたから持ち出したんだけど。
> だとしたらCakePHPってすごいな。
Railsのパクリ。もちろんそれが悪いわけではない
>>800
なるほど。ORMとしては一般的というわけじゃないが、
CakePHPが参考にした、Railsのパクリということか。
別にパクリだろうがパクリでなかろうが、それでどういう言うつもりはないｗ
それはそれとして、Railsは言語ごとよくわからんのだが、
Railsの本、一応二冊持っている。それを見たのだが、どうも
検索条件の所は、SQL+プレースフォルダって感じなんだけど
本当にオブジェクトで指定できるの？
俺が知らないだけって可能性のほうが高いんだけどさ。
なるほど。ORMとしては一般的というわけじゃないが、
CakePHPが参考にした、Railsのパクリということか。
別にパクリだろうがパクリでなかろうが、それでどういう言うつもりはないｗ
それはそれとして、Railsは言語ごとよくわからんのだが、
Railsの本、一応二冊持っている。それを見たのだが、どうも
検索条件の所は、SQL+プレースフォルダって感じなんだけど
本当にオブジェクトで指定できるの？
俺が知らないだけって可能性のほうが高いんだけどさ。
>>801
もうおまえはcakeｽﾚに帰れ
もうおまえはcakeｽﾚに帰れ
CakePHPもフレームワークだろｗ
なんか変なの湧いてるな
あぁ、フレームワーク（CakePHP）の話題をしていたら、
スレ違いでもないのに帰れといっちゃうやつのことだな。
話についていけないからってｗ
スレ違いでもないのに帰れといっちゃうやつのことだな。
話についていけないからってｗ
ここをORMスレと勘違いしていたか、
それともCakePHPがフレームワークだと知らなかったんだろうなｗ
それともCakePHPがフレームワークだと知らなかったんだろうなｗ
おお、俺がJOINがどうこうとか書いちゃったか荒れちゃったか、すまん。
あの配列をどうこうって言いたかったわけじゃなくて、SQLをPHPで表すことが
「解りにくい」って事を言いたかった。
別にCakePHPを指して「不便だ」って言ってるのではなくて、ORMそのものが
自分には合わないし、"例えば"CakePHPを知らない人（もしくはPHPを知らない人）に
教えるには、ORMを使うより、SQL直書きの方が理解が早いだろう、と。
ただそれだけだったの。ごめんね。
あの配列をどうこうって言いたかったわけじゃなくて、SQLをPHPで表すことが
「解りにくい」って事を言いたかった。
別にCakePHPを指して「不便だ」って言ってるのではなくて、ORMそのものが
自分には合わないし、"例えば"CakePHPを知らない人（もしくはPHPを知らない人）に
教えるには、ORMを使うより、SQL直書きの方が理解が早いだろう、と。
ただそれだけだったの。ごめんね。
別に荒れてない変な奴がいるだけだ、どうでもいいが
ORM使ってても極端な話全部クエリベタ書きでも済ませられるわけで、
こんな定型的で単純なクエリいちいち書くの面倒だな、ってとこだけ
ORM側でクエリ生成してもらって抽象的に書けばいいだけのもんだと思うんだけど
ORMを使ってても何から何までORMでやるわけじゃない
ベタ書きや部分的にクエリを生書きするケースなんていくらでも出る
でもその上で単純で面倒な部分を抽象化して楽させてくれるのがORMの役割だろう
教えるにはってのは分かるけどさすがに別問題
SQLは最低限理解してる上でのORMなんだから
ただphpのORMがどれも使いにくいのは分かる、
どちらかというとphpの言語仕様に起因する問題が大きいけど
railsから戻ってくると使い辛くて仕方ない
ORM使ってても極端な話全部クエリベタ書きでも済ませられるわけで、
こんな定型的で単純なクエリいちいち書くの面倒だな、ってとこだけ
ORM側でクエリ生成してもらって抽象的に書けばいいだけのもんだと思うんだけど
ORMを使ってても何から何までORMでやるわけじゃない
ベタ書きや部分的にクエリを生書きするケースなんていくらでも出る
でもその上で単純で面倒な部分を抽象化して楽させてくれるのがORMの役割だろう
教えるにはってのは分かるけどさすがに別問題
SQLは最低限理解してる上でのORMなんだから
ただphpのORMがどれも使いにくいのは分かる、
どちらかというとphpの言語仕様に起因する問題が大きいけど
railsから戻ってくると使い辛くて仕方ない
> こんな定型的で単純なクエリいちいち書くの面倒だな、ってとこだけ
単純なクエリ(俺は”単純なクエリ”にJOINを使ったものも含める)が
それがほとんどなんだけどね。
> こんな定型的で単純なクエリいちいち書くの面倒だな、ってとこだけ
> ORM側でクエリ生成してもらって
ORMで解消される面倒な部分はクエリ生成部分だけじゃないでしょ？
もっと面倒な変数への代入をやってくれるのがいい。
JOINが含まれている場合、ORMを使わないとベタな二次元の表にしかならないが
ORMならコードで扱いやすいようにちゃんとした階層構造になっている。
ORMとは、その名前の通り、オブジェクト と リレーショナル のマッピング。
普段オブジェクト指向でプログラミングしていたら、ベタな二次元の表は扱いにくい。
> ただphpのORMがどれも使いにくいのは分かる、
で、肝心の使いにくいと言う理由は？
それがないと、なんだかなぁで終わり。
>>793さんはORMに慣れていないってだけで、
ORMが使いにくいとは言っていないと解釈した。
つまり使いにくいと言っているのは>>808だけ。
単純なクエリ(俺は”単純なクエリ”にJOINを使ったものも含める)が
それがほとんどなんだけどね。
> こんな定型的で単純なクエリいちいち書くの面倒だな、ってとこだけ
> ORM側でクエリ生成してもらって
ORMで解消される面倒な部分はクエリ生成部分だけじゃないでしょ？
もっと面倒な変数への代入をやってくれるのがいい。
JOINが含まれている場合、ORMを使わないとベタな二次元の表にしかならないが
ORMならコードで扱いやすいようにちゃんとした階層構造になっている。
ORMとは、その名前の通り、オブジェクト と リレーショナル のマッピング。
普段オブジェクト指向でプログラミングしていたら、ベタな二次元の表は扱いにくい。
> ただphpのORMがどれも使いにくいのは分かる、
で、肝心の使いにくいと言う理由は？
それがないと、なんだかなぁで終わり。
>>793さんはORMに慣れていないってだけで、
ORMが使いにくいとは言っていないと解釈した。
つまり使いにくいと言っているのは>>808だけ。
っていうか、JOINを使って実現するような場合こそORMの本領発揮だろ？
JOINを使わない場合、二次元の表にしかやりようがないわけで、
それくらいなら、直接データを扱っても変わらない。
ここで勘違いさんは、ORM使わないでやったほうが良いじゃんと思う。
本領発揮のJOINが含まれている場合だと、アソシエーションという新しい用語が
でてくるため、勘違いさんはORMはわけわからんとアソシエーション以前の知識で思考停止する。
単に一対多とかいう情報を設定しているだけなのにね。
この二つの勘違いから、ORMを使う必要はないし、
JOINをやるときは複雑だ。という結論になるんだろうな。
本当は、特にJOINが含まれるようなときに面倒な部分がかなりなくなるから
ORMを使ったほうが便利。なのにね。
JOINを使わない場合、二次元の表にしかやりようがないわけで、
それくらいなら、直接データを扱っても変わらない。
ここで勘違いさんは、ORM使わないでやったほうが良いじゃんと思う。
本領発揮のJOINが含まれている場合だと、アソシエーションという新しい用語が
でてくるため、勘違いさんはORMはわけわからんとアソシエーション以前の知識で思考停止する。
単に一対多とかいう情報を設定しているだけなのにね。
この二つの勘違いから、ORMを使う必要はないし、
JOINをやるときは複雑だ。という結論になるんだろうな。
本当は、特にJOINが含まれるようなときに面倒な部分がかなりなくなるから
ORMを使ったほうが便利。なのにね。
>>809
使いにくいよ
cakeだとそもそもデータ取得して戻ってくるのオブジェクトじゃなく配列だし
model自体(取得して返って来るレコードオブジェクト）の拡張できない
symfonyのpropelはmodelの生成でファイル増えまくるし
Criteriaは冗長過ぎる、生で書いた方がマシ
使いにくいよ
cakeだとそもそもデータ取得して戻ってくるのオブジェクトじゃなく配列だし
model自体(取得して返って来るレコードオブジェクト）の拡張できない
symfonyのpropelはmodelの生成でファイル増えまくるし
Criteriaは冗長過ぎる、生で書いた方がマシ
読む気にもならん臭いスレになりさがったな。
とりあえずcommon.phpに戻ってみ本当に自分にFWがいるのか再考してみたら？
とりあえずcommon.phpに戻ってみ本当に自分にFWがいるのか再考してみたら？
配列ってだけでしょ？
modelの拡張？ 継承して普通にやっているが？
検索後のデータを内容を加工したり、またセーブ直前にデータを加工
（たとえばひらがなをカタカナに変換するなどしていれたり何でも出来る。
ひらがなをカタカナに変換する例なら、behaviorを継承したオブジェクトを作って
beforeSaveで変換すればいいだけだな。
データベースに無い合計フィールドを付け加えるとかいうのなら、
単にAfterFindでデータを付け加えればいいだけだな。
手間はデータがオブジェクトである場合となにもかわらない。
こういう実装になっていますって言っているだけじゃ使いにくいの説明になっていない。
具体的に、どんなことが出来ないのか言ってくれないとわからないなぁ。
> 生で書いたほうがマシ
いやさ、生でかいたらデータは配列だよ？
自分でオブジェクトじゃなければ使いにくいと言っておきながらｗ
modelの拡張？ 継承して普通にやっているが？
検索後のデータを内容を加工したり、またセーブ直前にデータを加工
（たとえばひらがなをカタカナに変換するなどしていれたり何でも出来る。
ひらがなをカタカナに変換する例なら、behaviorを継承したオブジェクトを作って
beforeSaveで変換すればいいだけだな。
データベースに無い合計フィールドを付け加えるとかいうのなら、
単にAfterFindでデータを付け加えればいいだけだな。
手間はデータがオブジェクトである場合となにもかわらない。
こういう実装になっていますって言っているだけじゃ使いにくいの説明になっていない。
具体的に、どんなことが出来ないのか言ってくれないとわからないなぁ。
> 生で書いたほうがマシ
いやさ、生でかいたらデータは配列だよ？
自分でオブジェクトじゃなければ使いにくいと言っておきながらｗ
>>812
> とりあえずcommon.phpに戻ってみ本当に自分にFWがいるのか再考してみたら？
再考するまでも無いな。フレームワークとかそんな大げさに考える必要は無い。
common.phpを何倍も便利にしたライブラリ。
より便利なライブラリを使う。
それだけの話
> とりあえずcommon.phpに戻ってみ本当に自分にFWがいるのか再考してみたら？
再考するまでも無いな。フレームワークとかそんな大げさに考える必要は無い。
common.phpを何倍も便利にしたライブラリ。
より便利なライブラリを使う。
それだけの話
長文日本語ばかりで萎える
精神論ばかりでなく、コードを提示して
ほら便利だよとか言って欲しい
精神論ばかりでなく、コードを提示して
ほら便利だよとか言って欲しい
>>813
> > 生で書いたほうがマシ
> いやさ、生でかいたらデータは配列だよ？
> 自分でオブジェクトじゃなければ使いにくいと言っておきながらｗ
propel の Criteria が冗長すぎて、生で条件を書いたほうがマシって話だろ。
> > 生で書いたほうがマシ
> いやさ、生でかいたらデータは配列だよ？
> 自分でオブジェクトじゃなければ使いにくいと言っておきながらｗ
propel の Criteria が冗長すぎて、生で条件を書いたほうがマシって話だろ。
なんだ、随分とのびたな。
>>794
>複雑どころか、なんと書く必要すらない。
>
>まあ、何もないところからJOINがでてくるわけないので何かの情報は
>必要なわけだが、ER図で、1対1とか1対多とか多対多とか定義するでしょ？
>あの情報を、このテーブルは他のテーブルとどういう関係にあると書くだけ。
書く必要ないって、・・・書いてんじゃん。w
オレもORMは使うよ。でもCakePHPは使ったこと無くて、
Cakeではあの配列をORMっていうのか？って思ったから聞いただけ。
MLでもなし、にちゃんでいちいち勉強してから書き込むかっつの。
791はORM知らない。ORMは銀の弾丸。根拠なしで思い込みで言っちゃってるでしょ？
>>794
>複雑どころか、なんと書く必要すらない。
>
>まあ、何もないところからJOINがでてくるわけないので何かの情報は
>必要なわけだが、ER図で、1対1とか1対多とか多対多とか定義するでしょ？
>あの情報を、このテーブルは他のテーブルとどういう関係にあると書くだけ。
書く必要ないって、・・・書いてんじゃん。w
オレもORMは使うよ。でもCakePHPは使ったこと無くて、
Cakeではあの配列をORMっていうのか？って思ったから聞いただけ。
MLでもなし、にちゃんでいちいち勉強してから書き込むかっつの。
791はORM知らない。ORMは銀の弾丸。根拠なしで思い込みで言っちゃってるでしょ？
普通に配列で戻ってきた方が使いやすいんだが。関数の豊富さにもあらわれているようにPHPは配列多様言語だから
結果は配列でいいよな
オブジェクトにするにしてもほとんど単なるValueObjectだろう
オブジェクトにするにしてもほとんど単なるValueObjectだろう
配列ってのは間違い。ハッシュってのが正解。
だってさ、配列といったら俺でも不便に思うけど、
それは a[0] ・・・これがID、 a[1] ・・・これがタイトルという風に
インデックス番号でしかアクセスできないからでしょ？
もちろん実際はそんなことは無く、名前でアクセスできるわけで。
それからCakePHPの話だが、Modelの中のデータが配列で格納されているだけであって、
Model自体はクラスだよ。
だってさ、配列といったら俺でも不便に思うけど、
それは a[0] ・・・これがID、 a[1] ・・・これがタイトルという風に
インデックス番号でしかアクセスできないからでしょ？
もちろん実際はそんなことは無く、名前でアクセスできるわけで。
それからCakePHPの話だが、Modelの中のデータが配列で格納されているだけであって、
Model自体はクラスだよ。
連想配列は配列の一種だろ
自分だけの定義で話をすんな
自分だけの定義で話をすんな
> ハッシュってのが正解。
まったくの不正解。
まったくの不正解。
連想配列と配列は他の言語ではまったくの別物。
それをわかっていない奴がいる。
それをわかっていない奴がいる。
えっ、どこにどこに?
なんで他の言語が出てくるんだよw
要するに峻別できるもんじゃねーんだよ
それをとりあげて正解だ不正解だいってるお前の頭が不正解
要するに峻別できるもんじゃねーんだよ
それをとりあげて正解だ不正解だいってるお前の頭が不正解
連想配列と配列の区別が無い言語ってPHPだけだと思うが？
フレームワークを使おうが使うまいが、
気の利くUIを、動作調整しながら丁寧に作ってたりすると、
それだけで一日くらいすぐ経っちゃう。
気の利くUIを、動作調整しながら丁寧に作ってたりすると、
それだけで一日くらいすぐ経っちゃう。
>>827
そうでもないよ
そうでもないよ
へぇ。だったらその言語言ってみせてよ。
話がそれてるよ
話の主旨は「配列なのか連想配列なのか」ではなく
「（連想）配列なのかオブジェクトなのか」だろ？
array_map() とか使える配列もなかなか便利だけど
メソッド定義で拡張できるオブジェクトの方が潰しが利くと個人的には思う．
>>813みたいな例でいうと
後で必要になる形式のデータを配列作成時に全部生成しておくより，
必要に応じてメソッド呼んで使う時に使うデータを生成するって方が
個人的には好みだ．
話の主旨は「配列なのか連想配列なのか」ではなく
「（連想）配列なのかオブジェクトなのか」だろ？
array_map() とか使える配列もなかなか便利だけど
メソッド定義で拡張できるオブジェクトの方が潰しが利くと個人的には思う．
>>813みたいな例でいうと
後で必要になる形式のデータを配列作成時に全部生成しておくより，
必要に応じてメソッド呼んで使う時に使うデータを生成するって方が
個人的には好みだ．
だから、Model内部が連想配列になっているだけで、
Model自体はオブジェクトだってｗ
Model自体はオブジェクトだってｗ
この場合 array_map とかが便利な状況ってあまりない気がするが、
どんな使い方が考えられるんだろうか。
どんな使い方が考えられるんだろうか。
強引なのは承知だが、PHPにおいては、
配列≒連想配列≒≒≒≒≒オブジェクト
でいいじゃん
聞いててもつまらん話題だ
配列≒連想配列≒≒≒≒≒オブジェクト
でいいじゃん
聞いててもつまらん話題だ
連想配列で十分なときは連想配列を使う。
オブジェクトが必要ならオブジェクトを使う。
PHPでオブジェクト（クラス）が使えないとでも思っているの？
オブジェクトが必要ならオブジェクトを使う。
PHPでオブジェクト（クラス）が使えないとでも思っているの？
> 連想配列で十分なときは連想配列を使う。
> オブジェクトが必要ならオブジェクトを使う。
なかなかインテリジェントなORMだな。
> オブジェクトが必要ならオブジェクトを使う。
なかなかインテリジェントなORMだな。
ORMの話していたのかｗ
CakePHPの場合はModelはオブジェクトだね。
だからなに？って感じなんだが。
CakePHPの場合はModelはオブジェクトだね。
だからなに？って感じなんだが。
使っている人いない。Googleの検索数が今の10倍になってから出直してね。
rhacoに限らず、やはりドキュメントが揃ってないと使い辛いよね。
http://cakephp.seesaa.net/article/53564832.html
間もなくCake本登場！！
今日のPHPカンファレンスで安藤さんが発表されていると思うので、ここら辺で発表・・・。
世界に先駆けて？CakePHPフレームワークの解説本を出すことになりました。
CakePHPの紹介
Cakeに特徴的な、モデルの使い方詳説
コントローラ、ビューについても解説
PHPプログラミングで必要とされるセキュリティの知識、CakePHP流に実現する方法
Ajaxの隅から隅まで
マイコミ出版から、10月に出版される"予定"です
間もなくCake本登場！！
今日のPHPカンファレンスで安藤さんが発表されていると思うので、ここら辺で発表・・・。
世界に先駆けて？CakePHPフレームワークの解説本を出すことになりました。
CakePHPの紹介
Cakeに特徴的な、モデルの使い方詳説
コントローラ、ビューについても解説
PHPプログラミングで必要とされるセキュリティの知識、CakePHP流に実現する方法
Ajaxの隅から隅まで
マイコミ出版から、10月に出版される"予定"です
Ethnaあたりでもういいだろ
>>842
確かにあの妥協さ加減は、テロっとWeb制作するにはちょうどいいよな。
確かにあの妥協さ加減は、テロっとWeb制作するにはちょうどいいよな。
データベースを使わないようなウェブサービス → Ethna
データベースを使う大規模なウェブサービス → CakePHP
こんな感じか。
あと個人的にはどうしても世界レベルではやっているもので
なければ使いたくないな。
データベースを使う大規模なウェブサービス → CakePHP
こんな感じか。
あと個人的にはどうしても世界レベルではやっているもので
なければ使いたくないな。
Ethnaって世界レベル？
846 ：nobodyさん：2007/09/30(日) 14:43:18 ID:H/GK0oDX
データベースを使わないWebサービスなんて・・・
英語圏のものでも
utf8があたりまえになりつつあるから、
昔より敷居は低くなってるんじゃないかな
ま、utf8ですべて解決とは言わないが
utf8があたりまえになりつつあるから、
昔より敷居は低くなってるんじゃないかな
ま、utf8ですべて解決とは言わないが
世界レベル（笑）
Cakeってソース見ると、クラクラするほど汚いのになぜ流行るんだろう？
PHPerがバカばっかりだからだよ
ソースが汚くてもフレームワーク自体を改造するわけじゃないから、
便利に使えればOKっていうやつがおおいからだろ？
便利に使えればOKっていうやつがおおいからだろ？
ピーエイチパー？
ぺちぱー
国産のMoonyとか言うフレーム発見したが既出？
cakeは見たことないがソース汚かったらそれだけで使う気は失せるな
汚いのなら、直せば良いだろ。
オープンソースなんだから。
オープンソースなんだから。
結論：PEARで十分
>>852
たぶん、Railsゆずり。
RailsはRubyの強力過ぎるリフレクションでどうにかまとまっているようにも見えるが、
PHPで書くとなんだかRailsの悪いとこだけコピったような感じになる。
たぶん、Railsゆずり。
RailsはRubyの強力過ぎるリフレクションでどうにかまとまっているようにも見えるが、
PHPで書くとなんだかRailsの悪いとこだけコピったような感じになる。
>>862
え、ソース読んだことある?
とくにActiveRecordの宣言チックに機能追加する部分はほとんどリフレクションのはず
module_eval とか instance_eval とか method_missing とかで検索するといい。
こいつらのいで、機能の定義場所が追えないことが良くある。
え、ソース読んだことある?
とくにActiveRecordの宣言チックに機能追加する部分はほとんどリフレクションのはず
module_eval とか instance_eval とか method_missing とかで検索するといい。
こいつらのいで、機能の定義場所が追えないことが良くある。
>>863
いやね。何がいいたいかと言うと、一言で言うと、
それのどこが「強力すぎるリフレクション」なの？ ということ。
たとえば、CakePHPなら、model->findBy○○(△△)で
データベースの○○フィールドが△△のものを検索とかね。
もちろん、findBy○○メソッドが定義されているわけじゃない。
実行時にメソッド名からフィールド名を取り出して検索している。
そのレベルのリフレクションなら、ほとんどのオブジェクト指向言語にあるよ。
無いのは純粋なC++ぐらいかな。
いやね。何がいいたいかと言うと、一言で言うと、
それのどこが「強力すぎるリフレクション」なの？ ということ。
たとえば、CakePHPなら、model->findBy○○(△△)で
データベースの○○フィールドが△△のものを検索とかね。
もちろん、findBy○○メソッドが定義されているわけじゃない。
実行時にメソッド名からフィールド名を取り出して検索している。
そのレベルのリフレクションなら、ほとんどのオブジェクト指向言語にあるよ。
無いのは純粋なC++ぐらいかな。
メソッドがないってことは
ideの自動補完も使えないってことか
そんなのいらねー(#・д・)､ﾍﾟｯ
ideの自動補完も使えないってことか
そんなのいらねー(#・д・)､ﾍﾟｯ
Ruby強力すぎるリフレクションを持っていると聞いて
？と思っただけだが。
？と思っただけだが。
PHP5.3で名前空間実装でRuby脂肪ｗｗｗ
スクリプトが走ってる最中に動的に
メソッド定義そのものを書き換えられるなんて
rubyの強力な機能以外の何者でもないと思うが
で、それは同時に諸刃でもある
リフレクションは自身の定義の読み取りだけじゃなく書き換えもある
phpは読み取りのリフレクションは備えてるけど
メソッドを直接書き換えたりはできない、せいぜい__callで頑張るくらい
メソッド定義そのものを書き換えられるなんて
rubyの強力な機能以外の何者でもないと思うが
で、それは同時に諸刃でもある
リフレクションは自身の定義の読み取りだけじゃなく書き換えもある
phpは読み取りのリフレクションは備えてるけど
メソッドを直接書き換えたりはできない、せいぜい__callで頑張るくらい
module_eval見たいな奴がある言語って他にあるの? メジャー系で。
ほいほいオブジェクトのメソッドを上書きできるのってあんまり見ない気が。
メソッドの型とか一覧とかにアクセス出来るだけならたくさんあるけど。
ほいほいオブジェクトのメソッドを上書きできるのってあんまり見ない気が。
メソッドの型とか一覧とかにアクセス出来るだけならたくさんあるけど。
PHPもPECL使えば、メソッド書き換えできるよ。
runkit見てみた。
なかなか面白いね。とくにSandboxを作るのは面白い。
言語仕様に組み込めないのはしかたないとして、
実験室レベルから成長する日は果して来るか...
こいつをバリバリ使ったRails級のキラーアプリとか、ないよね。
なかなか面白いね。とくにSandboxを作るのは面白い。
言語仕様に組み込めないのはしかたないとして、
実験室レベルから成長する日は果して来るか...
こいつをバリバリ使ったRails級のキラーアプリとか、ないよね。
面白いだろうけど、書き換えられまくれるのもそれはそれで問題あるしな
結局言語内仕様じゃない１拡張なんだから
その書き換えに発生するコストも高くつくだろうし
railsから参考になる部分はいっぱいあるけど
phpはphpで言語内仕様でサポートする範囲内で
使いやすいようなFW作ればいいと思う
結局言語内仕様じゃない１拡張なんだから
その書き換えに発生するコストも高くつくだろうし
railsから参考になる部分はいっぱいあるけど
phpはphpで言語内仕様でサポートする範囲内で
使いやすいようなFW作ればいいと思う
Rubyが実行時にメソッド書き換えができるのはわかったが、
それをRailsで使いまくっているのか？
っていうか、ここはPHPスレ。Ruby厨はカエレ！
それをRailsで使いまくっているのか？
っていうか、ここはPHPスレ。Ruby厨はカエレ！
Rubyも自動補完ほとんど効かないの？
そんな言語使う人いんの？
そんな言語使う人いんの？
guessworkの中の人のブログに載ってたこれでPython勧められた
http://dame.dyndns.org/misc/llahp/
ちなみにPHPのおすすめされ度は最下位ｗ
PHPとはお別れします
ｱﾃﾞｭｰ( ´_｀)丿☆
http://dame.dyndns.org/misc/llahp/
ちなみにPHPのおすすめされ度は最下位ｗ
PHPとはお別れします
ｱﾃﾞｭｰ( ´_｀)丿☆
>>874
2chで名無しにどう言われても信用できないだろ?
だからRailsのソースを読め
そしてインスタンスのmethod_missingとかを実行時に書き換えるのを見れ。
ARのアソシエーションはたいていそうやって見かけの便利メソッドを増やしてる。
あとはaliasで既存のメソッドをコピった後に同名のメソッドを追加するとか。
2chで名無しにどう言われても信用できないだろ?
だからRailsのソースを読め
そしてインスタンスのmethod_missingとかを実行時に書き換えるのを見れ。
ARのアソシエーションはたいていそうやって見かけの便利メソッドを増やしてる。
あとはaliasで既存のメソッドをコピった後に同名のメソッドを追加するとか。
ここはPHPスレなんだから、PHP使いのレベルに合わせないと・・・
DBから引いてくるデータでオブジェクトだと便利なのはせいぜいDATE型のカラムくらいで、他はオブジェクトである必要はない。
配列つっこんでおけば取り出す時にオブジェクト化してくれるファクトリ書けば
万事解決
万事解決
>>878
> ARのアソシエーションはたいていそうやって見かけの便利メソッドを増やしてる。
> あとはaliasで既存のメソッドをコピった後に同名のメソッドを追加するとか。
うん。Rubyすごいね。PHPでも同じことできるけどねｗ
さっさとRubyスレに帰れよｗ
> ARのアソシエーションはたいていそうやって見かけの便利メソッドを増やしてる。
> あとはaliasで既存のメソッドをコピった後に同名のメソッドを追加するとか。
うん。Rubyすごいね。PHPでも同じことできるけどねｗ
さっさとRubyスレに帰れよｗ
>>883
その程度ならインスタンスでも出来るけどね。runkitを使わなくても。php4でも。
（実際に実行した）実証コード。
<?php
class CLS extends MIXIN {
function foo() {
return 'foo';
}
}
class CLS2 {
function bar() {
return 'bar';
}
}
$a = new CLS();
print $a->foo();
//print $a->bar(); //当然エラー
print $a->includeClass('CLS2'); //includeClassメソッドはMIXINクラスに実装
print $a->bar();
$b = new CLS();
//print $b->bar(); //当然エラー
?>
※CLSはCLS2を継承していない。
で、MIXINクラスは何かって？ 少し、考えてくれｗ
それらしい答えが出なかったら夕方にでもうｐするよ。
その程度ならインスタンスでも出来るけどね。runkitを使わなくても。php4でも。
（実際に実行した）実証コード。
<?php
class CLS extends MIXIN {
function foo() {
return 'foo';
}
}
class CLS2 {
function bar() {
return 'bar';
}
}
$a = new CLS();
print $a->foo();
//print $a->bar(); //当然エラー
print $a->includeClass('CLS2'); //includeClassメソッドはMIXINクラスに実装
print $a->bar();
$b = new CLS();
//print $b->bar(); //当然エラー
?>
※CLSはCLS2を継承していない。
で、MIXINクラスは何かって？ 少し、考えてくれｗ
それらしい答えが出なかったら夕方にでもうｐするよ。
わかってないのにもったいつけなくてもいいよ
わかってない ということにしたい理由はなに？ ほんとうにわかってないのは（ｒｙ
>>884
インスタンス変数を使ってインスタンスの振舞を変更するのは
あたりまえじゃぁないすか?
そのためにインスタンス変数ってあるもんだし。
できるかできんかで言えば、C言語でオブジェクト指向で書くことはできるし、
実際そういうのは結構あるわけで。
インスタンス変数を使ってインスタンスの振舞を変更するのは
あたりまえじゃぁないすか?
そのためにインスタンス変数ってあるもんだし。
できるかできんかで言えば、C言語でオブジェクト指向で書くことはできるし、
実際そういうのは結構あるわけで。
>>884 激しくダサいな・・・
>>888
なぜ？
なぜ？
>>887
あのさぁ。出来るか出来ないかの話を吹っかけておいてさ、
「出来るけど、（その後なんて言いたいのか知らん）」と
言い訳するのやめてくんない？
そんなこというなら、最初っから出来ないなんて大口たたかないで、
「出来るけど、（その後なんて言いたいのか知らん）」と言えという話。
でなんて言いたいのさ、出来るけど時間がかかる？ コード書くのが手間？
一度書けば、それで終わりだよね。
あのさぁ。出来るか出来ないかの話を吹っかけておいてさ、
「出来るけど、（その後なんて言いたいのか知らん）」と
言い訳するのやめてくんない？
そんなこというなら、最初っから出来ないなんて大口たたかないで、
「出来るけど、（その後なんて言いたいのか知らん）」と言えという話。
でなんて言いたいのさ、出来るけど時間がかかる？ コード書くのが手間？
一度書けば、それで終わりだよね。
rubyの擁護ってわけじゃないけど、
ARのリレーションで実行時に書き換えるインスタンスはクラスオブジェクトそのものだとおもうよ。
ARクラスをnewしたオブジェクトじゃなく。
だから>>884の例はARを実装してるRubyの機能をPHPで実現できた証明には弱いと思う。
なにか見えない大きな敵に向かっているようだけど
おれはこの流れで>>887が最初の発言
まぁ、喧嘩腰にならずに
なかよくやろうや。
ARのリレーションで実行時に書き換えるインスタンスはクラスオブジェクトそのものだとおもうよ。
ARクラスをnewしたオブジェクトじゃなく。
だから>>884の例はARを実装してるRubyの機能をPHPで実現できた証明には弱いと思う。
なにか見えない大きな敵に向かっているようだけど
おれはこの流れで>>887が最初の発言
まぁ、喧嘩腰にならずに
なかよくやろうや。
ごめん名前欄まちがえた
>>891
でもさ、たとえ内部の仕組みが違ったとしても、
それで出来ることと同じことが、同じ程度の手間で
PHPででも実現できるわけだよ。
出来ないと言うのなら、具体的にどんなことが出来ないのか示してほしいね。
でもさ、たとえ内部の仕組みが違ったとしても、
それで出来ることと同じことが、同じ程度の手間で
PHPででも実現できるわけだよ。
出来ないと言うのなら、具体的にどんなことが出来ないのか示してほしいね。
クラス定義の中でクラス関数を呼んで、
そのクラス関数が自分自身のクラスを書き換える、とか?
でも最初はRailsはrubyのリフレクション使いまくりで読みにくいという
話だったはずだけど、いつのまに出来る出来ないという話がでたわけだろうか。
話の流れに関係ない煽りにのせられてないかい?
そのクラス関数が自分自身のクラスを書き換える、とか?
でも最初はRailsはrubyのリフレクション使いまくりで読みにくいという
話だったはずだけど、いつのまに出来る出来ないという話がでたわけだろうか。
話の流れに関係ない煽りにのせられてないかい?
rubyはfastcgiなんて不安定なものを使わないと行けないって時点で相当ポイント低いよな。
phpやperlならcgiでもそこそこ動くけど、rubyはfastcgiなしじゃ話にならない。
phpやperlならcgiでもそこそこ動くけど、rubyはfastcgiなしじゃ話にならない。
オープンソースで作る場合、rubyは選択しづらいな。
rubyが動く環境が少なすぎる。
それらの環境を切り捨てるほどの理由が見つからない。
rubyが動く環境が少なすぎる。
それらの環境を切り捨てるほどの理由が見つからない。
JRubyでRailsの.warファイルをJBossとかにデプロイしてイェーイという話も
実運用の話はまだ聞かないしね。Sunはどんだけ本気なのかしらんけど。
実運用の話はまだ聞かないしね。Sunはどんだけ本気なのかしらんけど。
898 ：nobodyさん：2007/10/03(水) 20:50:42 ID:L+I4Rl+L
アドバイスしねーよｗｗｗ つか宣伝すんな。
>>898
嘘ばっか教えてやります
嘘ばっか教えてやります
おまいらのレベルの低さに絶望した
http://japan.zdnet.com/security/story/0,3800079245,20357867,00.htm
なりすまされてRuby脂肪ｗｗｗ
なりすまされてRuby脂肪ｗｗｗ
それぐらいで死んでたらPHPなんてもうないじゃんw
それで死ぬならWindowsもLinuxもとっくに滅びてるなｗ
女子中学生がプログラミング勉強ブログを書いていたら、全力でレスしていたはずのスレはここですか？
ちがいます。女児の間違いです。
いいえ70歳のお婆ちゃんです
//mix-inっぽいこと PHP4用 PHP5では修正する必要あり
class MIXIN {
var $classes = array();
function MIXIN() {
overload(get_class($this));
}
function __call($method, $param, &$r) {
if(strtolower(get_class($this))===$method) return true;
$class = null;
foreach($this->classes as $c) {
if(in_array($method,get_class_methods($c))) {
$class = $c;
}
}
if($class === null) return false;
$r = call_user_func_array(array($class,$method), $param);
return true;
}
function includeClass($class_name) {
$cls = new $class_name();
$this->classes[$name] = $cls;
}
}
class MIXIN {
var $classes = array();
function MIXIN() {
overload(get_class($this));
}
function __call($method, $param, &$r) {
if(strtolower(get_class($this))===$method) return true;
$class = null;
foreach($this->classes as $c) {
if(in_array($method,get_class_methods($c))) {
$class = $c;
}
}
if($class === null) return false;
$r = call_user_func_array(array($class,$method), $param);
return true;
}
function includeClass($class_name) {
$cls = new $class_name();
$this->classes[$name] = $cls;
}
}
PHPフレームワーカーはどんなPC使ってますか？
メーカー製PCは、妙に高いし、
自作機作るのも調査が大変だしで
迷ってます
メーカー製PCは、妙に高いし、
自作機作るのも調査が大変だしで
迷ってます
PHP専用PCきぼんぬ
>>912
目の前にあるPCにテプラで「PHP専用」って貼っておけ。
目の前にあるPCにテプラで「PHP専用」って貼っておけ。
テプラ買うか・・
PHPしか走らず、他の言語、特にRubyが走ったら爆発するPCがいいの!（><)
>>915
PHPしか使えないようにした1CD Linuxでもセットアップしなよ。
PHPしか使えないようにした1CD Linuxでもセットアップしなよ。
メーカー製でも安いPCはあるよ
http://akiba.kakaku.com/shop/0710/03/220000.php
【タワー型サーバ】日本HP「HP ProLiant ML115(Athlon64 3500+搭載モデル)」 17,800円
ある程度予算があるなら、DELLのOpteron搭載サーバがいいと思います。
＝はてなとかでも使っている
自作するなら、マザーボードはSuperMicroにするのが良いと思います。
http://akiba.kakaku.com/shop/0710/03/220000.php
【タワー型サーバ】日本HP「HP ProLiant ML115(Athlon64 3500+搭載モデル)」 17,800円
ある程度予算があるなら、DELLのOpteron搭載サーバがいいと思います。
＝はてなとかでも使っている
自作するなら、マザーボードはSuperMicroにするのが良いと思います。
>>909
MIXINはどういう時に使えばいいですか？
（Rubyは勉強していません。）
[php]eval使わずにPHP5でmix-inを実現 (Mixins in PHP without eval)
http://d.hatena.ne.jp/akkun_choi/20070215/1172457075
■[PHP]mixin for PHP
http://d.hatena.ne.jp/sweeper/20051207/p3
オブジェクトの集約/合成関数
http://jp.php.net/manual/ja/ref.objaggregation.php
MIXINはどういう時に使えばいいですか？
（Rubyは勉強していません。）
[php]eval使わずにPHP5でmix-inを実現 (Mixins in PHP without eval)
http://d.hatena.ne.jp/akkun_choi/20070215/1172457075
■[PHP]mixin for PHP
http://d.hatena.ne.jp/sweeper/20051207/p3
オブジェクトの集約/合成関数
http://jp.php.net/manual/ja/ref.objaggregation.php
Zendがさっさと安定したバージョン出せば
バカみたいにPHPフレームワークが乱立することは無くなるのに
バカみたいにPHPフレームワークが乱立することは無くなるのに
>>917
市販のPCケースより安いってどんだけ
市販のPCケースより安いってどんだけ
zendはポストpearって感じ
>>919
自分で使ってみてレポしろよ・・・
自分で使ってみてレポしろよ・・・
4切り捨てとか当然だろ
いつまで4使うつもりだよ
いつまで4使うつもりだよ
> 4切り捨てとか当然だろ
> いつまで4使うつもりだよ
うん？ レンタルサーバーからPHP4が無くなるまでだけど。
> いつまで4使うつもりだよ
うん？ レンタルサーバーからPHP4が無くなるまでだけど。
>>925
鯖ごと納めたシステムが使われなくなるまでｗｗｗ
鯖ごと納めたシステムが使われなくなるまでｗｗｗ
>>925は5だけでやってんの？
自社物onlyか、趣味でやってるだけ？
自社物onlyか、趣味でやってるだけ？
PHP4のリファレンスの説明って分かりにくいよな・・・
リファレンスのリファレンスを渡したら
ポインタのポインタみたいになるかと思ってずっと避けてた(><)
リファレンスのリファレンスを渡したら
ポインタのポインタみたいになるかと思ってずっと避けてた(><)
つうかリファレンスは糞
PHPは名前の付け方がアホなんだよ。リファレンスもそうだし、オーバーロードとかも。一般的な言語の知識があると混乱するだけ。
pu-he-po-
>>933
リファレンスもオーバーロードも一般的な意味だと思いますが
リファレンスもオーバーロードも一般的な意味だと思いますが
リファレンスは
ショートカットやポインタとは違うことを明確に示すために
アナザーネームでいいんじゃね
ショートカットやポインタとは違うことを明確に示すために
アナザーネームでいいんじゃね
ショートカット (´ﾟдﾟ｀)！
アナザーネーム (´ﾟдﾟ｀)！
アナザーネーム (´ﾟдﾟ｀)！
すれ違い
mixinはrhaco
別窓で開かれたページから、別窓を開く前のページへ値は渡せますか？？
管理画面のボタンを押すと別窓を開き、別窓に表示されたサムネイルを選択すると管理画面に反映されるという仕組みです。
管理画面のボタンを押すと別窓を開き、別窓に表示されたサムネイルを選択すると管理画面に反映されるという仕組みです。
ありがとうございます
>>936
PHPのリファレンスは参照じゃなくて別名。エイリアスとかハードリンクとか言うべき物。
PHPのオーバーロードは、普通の言語のメソッドオーバーロードとか演算子オーバーロードじゃなくって、Perlのオートロードみたいな物。
JavaとかC++とかの一般的な言語の知識しかない人がPHPのマニュアル読んだら確実に混乱するだろう。
PHPのリファレンスは参照じゃなくて別名。エイリアスとかハードリンクとか言うべき物。
PHPのオーバーロードは、普通の言語のメソッドオーバーロードとか演算子オーバーロードじゃなくって、Perlのオートロードみたいな物。
JavaとかC++とかの一般的な言語の知識しかない人がPHPのマニュアル読んだら確実に混乱するだろう。
>>944
フレームワークの話をしていただきたい
フレームワークの話をしていただきたい
小さなサイトだからと生書きで書き始めたが
後から一括処理を追加するのが面倒に・・・
ちいたんくらい使っておけばよかったか
後から一括処理を追加するのが面倒に・・・
ちいたんくらい使っておけばよかったか
フレームワークで構築したサイト久しぶりに見たら見通し悪すぎワロタ
フレームワークの構造そのものを忘れたら何使っても大抵は見通し悪いわな
>>944
PHPのリファレンスは、C++由来の参照だよ。
オーバーロードがPerlのオートロードだとか意味不明だが、おそらくマニュアルに
> __call, __get そして __set メソッドを通してオーバーロードすることができます。
と書いてあるのを読み違えてるんじゃないか？
>>949
MVC的な発想で作ってれば、多少は構造を忘れても、けっこう簡単に把握できると思う。
PHPのリファレンスは、C++由来の参照だよ。
オーバーロードがPerlのオートロードだとか意味不明だが、おそらくマニュアルに
> __call, __get そして __set メソッドを通してオーバーロードすることができます。
と書いてあるのを読み違えてるんじゃないか？
>>949
MVC的な発想で作ってれば、多少は構造を忘れても、けっこう簡単に把握できると思う。
>>950
>>944じゃないけど、PHPのリファレンスは他言語でいう
「参照」の意味合いより「別名」に近いよ、っていうかマニュアルにそう書いてある
http://jp.php.net/manual/ja/language.references.php
実際使われる局面の事を考えると「参照」のような使い方になるだろうけど
PerlのAUTOLOADはPHPでいうautoloadと全然違って
>>944の言うとおりPHPのオーバーロード相当に近いと思う
まあこの辺りは各言語で単語の使い方が違うのでどうこう言ってもあれだが
それと、俺も「オーバーロード」と聞くと普通はJavaやC++の
operator overloadやmethod overloadの「多重定義」の方をイメージすると思う
http://jp.php.net/manual/ja/language.oop5.overloading.php
PHPの「オーバーロード」はそういうのじゃなく
「該当するメンバやメソッドが無かった時にフックされる
いくつかのメソッドを定義すること」に「オーバーロード」という単語を使ってるので
PHPから入った人は別として他言語からPHPに来た人は
マニュアルを読んで単語の使い方に混乱する人が居てもおかしくはないと思う
>>944じゃないけど、PHPのリファレンスは他言語でいう
「参照」の意味合いより「別名」に近いよ、っていうかマニュアルにそう書いてある
http://jp.php.net/manual/ja/language.references.php
実際使われる局面の事を考えると「参照」のような使い方になるだろうけど
PerlのAUTOLOADはPHPでいうautoloadと全然違って
>>944の言うとおりPHPのオーバーロード相当に近いと思う
まあこの辺りは各言語で単語の使い方が違うのでどうこう言ってもあれだが
それと、俺も「オーバーロード」と聞くと普通はJavaやC++の
operator overloadやmethod overloadの「多重定義」の方をイメージすると思う
http://jp.php.net/manual/ja/language.oop5.overloading.php
PHPの「オーバーロード」はそういうのじゃなく
「該当するメンバやメソッドが無かった時にフックされる
いくつかのメソッドを定義すること」に「オーバーロード」という単語を使ってるので
PHPから入った人は別として他言語からPHPに来た人は
マニュアルを読んで単語の使い方に混乱する人が居てもおかしくはないと思う
オーバーロードを何故実装しないのかな
>>952
弱い型付けの言語で実装してるの知らないけどあるの？
弱い型付けの言語で実装してるの知らないけどあるの？
普通の言語
一般的な言語
の定義が曖昧です。
一般的な言語
の定義が曖昧です。
ペチパーはこれだから。
agavi 0.11RC6リリース
http://www.agavi.org/
http://www.agavi.org/
>>952
> オーバーロードを何故実装しないのかな
(C++風の）オーバーロードを実装しないのは
実装するまでもないからじゃね？
オーバーロードをなぜ使いたいかというと、
一つの関数をいろんな型、個数の引数で呼び出したいからなわけだけど、
PHPでは普通にいろんな型、個数で呼び出せるでしょ？
> オーバーロードを何故実装しないのかな
(C++風の）オーバーロードを実装しないのは
実装するまでもないからじゃね？
オーバーロードをなぜ使いたいかというと、
一つの関数をいろんな型、個数の引数で呼び出したいからなわけだけど、
PHPでは普通にいろんな型、個数で呼び出せるでしょ？
Perlは演算子オーバーロードできる。
演算子オーバロードは邪悪。必要ない。
演算子オーバーロードにせよ、メソッドオーバーロードにせよ、実装しないのは実装が大変なのが理由だろうな。
特に演算子オーバーロードできれば言語仕様のコアな部分をユーザが修正できるわけだけど、この実装はかなり難しいだろう。
特に演算子オーバーロードできれば言語仕様のコアな部分をユーザが修正できるわけだけど、この実装はかなり難しいだろう。
Perlの場合、メソッドオーバーライドはやりようがない。そもそも仮引数を明示しないから。
間違えた。↑メソッドオーバーロードだ。
phpの場合も引数というのは、
最低保障引数であってそれ以上の引数をつけても
呼び出せるし、もちろん関数からその引数を操作できるわけで。
(つまりfoo($value)というメソッドをfoo(1,2,3)という引数で
呼び出せてfunc_get_args()で2,3の引数にアクセスできる）
メソッドオーバーロードを実装するまでもなく、
それ相当のことができるわけさ。
メソッドオーバーロードは型あり言語では必須の機能かもしれないが、
型なし言語なら無くても同じことができるから必要なし。
演算子オーバーロードはねぇ。
あれ、Javaでも可読性が悪くなるという理由でサポートしないと明言されたような機能だし。
最低保障引数であってそれ以上の引数をつけても
呼び出せるし、もちろん関数からその引数を操作できるわけで。
(つまりfoo($value)というメソッドをfoo(1,2,3)という引数で
呼び出せてfunc_get_args()で2,3の引数にアクセスできる）
メソッドオーバーロードを実装するまでもなく、
それ相当のことができるわけさ。
メソッドオーバーロードは型あり言語では必須の機能かもしれないが、
型なし言語なら無くても同じことができるから必要なし。
演算子オーバーロードはねぇ。
あれ、Javaでも可読性が悪くなるという理由でサポートしないと明言されたような機能だし。
PHPでメソッドオーバーロード的なことをしようと思うと、メソッド内部で引数を数えてIFで切り分けて他のメソッドに委譲するだとかの汚いコードを書かないといけない。
そういう泥臭いコードを書かないで済むようにメソッドオーバーロードがある。
演算子オーバーロードは黒魔術的で、乱発すれば可読性が落ちるのは確か。
スクリプト言語の場合、厳密さより効率を優先する場合が多く、ライブラリのソース自体を目で追えるわけだから、演算子オーバーロードがあって困ることはない。
実際、RubyやPtyhonも演算子オーバーロードできる。
スクリプト言語の場合、厳密さより効率を優先する場合が多く、ライブラリのソース自体を目で追えるわけだから、演算子オーバーロードがあって困ることはない。
実際、RubyやPtyhonも演算子オーバーロードできる。
Ptyhonじゃなくって、Pythonだったな。
そもそもPHPの実装って非常に未熟な感じがする。3項演算子が左結合なのも実装技術が低いから以外に理由が浮かばないし。
そもそもPHPの実装って非常に未熟な感じがする。3項演算子が左結合なのも実装技術が低いから以外に理由が浮かばないし。
>>951以外の、リファレンスとオーバーロードについての指摘はずっと俺が書き込んでたんだが。
最近はPHPからプログラミングを始めて、PHPしかやったことがない人が多すぎる。
だから、PHPのリファレンスやオーバーロードが世間からずれてることに気づかない。
だから、PHPのリファレンスやオーバーロードが世間からずれてることに気づかない。
PHP言語について語るなアホども
>>964
> PHPでメソッドオーバーロード的なことをしようと思うと、
> メソッド内部で引数を数えてIFで切り分けて他のメソッドに委譲するだとかの汚いコードを書かないといけない。
おいおい。オーバーロードする場合、名前は同じなんだぞ。
同じ名前でまったく違う処理をすることなんて、ほぼないんだから、
結局は他のメソッドに委譲することになるだろ。
あと引数を数える必要も、普通は無いな。
そういう場合は、表略可能な引数で対応する。
つまり、型無し言語でオーバーロードなんていらないってわけだ。
> PHPでメソッドオーバーロード的なことをしようと思うと、
> メソッド内部で引数を数えてIFで切り分けて他のメソッドに委譲するだとかの汚いコードを書かないといけない。
おいおい。オーバーロードする場合、名前は同じなんだぞ。
同じ名前でまったく違う処理をすることなんて、ほぼないんだから、
結局は他のメソッドに委譲することになるだろ。
あと引数を数える必要も、普通は無いな。
そういう場合は、表略可能な引数で対応する。
つまり、型無し言語でオーバーロードなんていらないってわけだ。
convet($scalar)とconvret($array)で使い分けるとか。引数を調べないといけないケースはいくらでもある。
↑convert()だった
>>973
それでも、調べた後の処理は共通だろ？
その例だと、スカラーなら要素数1の配列に変換するだけ。
C++のオーバーロードであっても、一般的には同じように要素数１の配列に変換した後、
配列版の関数に委譲するだろ？（もしくは逆に配列を一個一個取り出して非配列版の関数に委譲する）
オーバーロードってのは、違う処理だけど名前は同じにしたい！
じゃあ引数で区別できれば便利じゃね？ という発想から生まれたものじゃなく、
処理はほとんど同じだけど、違う型でも扱えるようにしたい。
でも宣言は一つの型しか受け付けられない。別の名前は作りたくない。
という問題から生まれたものさ。
ゆえに、もとから違う型でも扱える、型なし言語ではほとんど無意味。
それでも、調べた後の処理は共通だろ？
その例だと、スカラーなら要素数1の配列に変換するだけ。
C++のオーバーロードであっても、一般的には同じように要素数１の配列に変換した後、
配列版の関数に委譲するだろ？（もしくは逆に配列を一個一個取り出して非配列版の関数に委譲する）
オーバーロードってのは、違う処理だけど名前は同じにしたい！
じゃあ引数で区別できれば便利じゃね？ という発想から生まれたものじゃなく、
処理はほとんど同じだけど、違う型でも扱えるようにしたい。
でも宣言は一つの型しか受け付けられない。別の名前は作りたくない。
という問題から生まれたものさ。
ゆえに、もとから違う型でも扱える、型なし言語ではほとんど無意味。
おまいらスレタイ完全無視してるよな
いいかげんにしろ
いいかげんにしろ
まずオーバーロードってメソッドオーバーロードのことな。
PHPのオーバーロードと混同するからな。PHPがオーバーロードなんて混乱しやすい名前付けたのがアホなんだけど。
現実にはメソッドオーバーロードが有効なケースは多くある。convert()というメソッドがスカラー変数を引数にとって、コンバートされたスカラー変数を返すようなAPIだったとして、
後から一括でコンバートするようなメソッドを追加するとき、convert()の仮引数を配列に、返り値を配列に変えないといけない。
もちろんis_array()で引数や返り値を調べて処理を分岐することは可能だけど、それじゃあ美しくないという感覚。この感覚がないなら、前提がまるで違うわけで話にならない。
それとPHP（に限らず大抵の言語）は型はあるから。PHPは動的に変化するだけで。is_array()やis_int()で仮引数を調べることはよくあること。
PHPのオーバーロードと混同するからな。PHPがオーバーロードなんて混乱しやすい名前付けたのがアホなんだけど。
現実にはメソッドオーバーロードが有効なケースは多くある。convert()というメソッドがスカラー変数を引数にとって、コンバートされたスカラー変数を返すようなAPIだったとして、
後から一括でコンバートするようなメソッドを追加するとき、convert()の仮引数を配列に、返り値を配列に変えないといけない。
もちろんis_array()で引数や返り値を調べて処理を分岐することは可能だけど、それじゃあ美しくないという感覚。この感覚がないなら、前提がまるで違うわけで話にならない。
それとPHP（に限らず大抵の言語）は型はあるから。PHPは動的に変化するだけで。is_array()やis_int()で仮引数を調べることはよくあること。
異なる処理に同じメソッド名を使う時点で美しいとは思えないがな
オーバーロードの話してるやつは他に行けと言ってるのが分からんのか？
2chでスレ違いスレ違い言う奴もうざい
そんなこと言っても何も変わりゃしねーから何も言わないでいい
そんなこと言っても何も変わりゃしねーから何も言わないでいい
Zendがフレームワークの本命って言われるのかが気になってしょうがない。
pearの再開発にMVCくっつけたライブラリ集にしかなってなくね？
pearの再開発にMVCくっつけたライブラリ集にしかなってなくね？
PHPフレームワークの作成は、サードパーティが頑張ってくれているから、Zendは早くPHP6をリリースした方がええんとちゃうの？
>978
>>982
に賛成
に賛成
日本のZendはただの代理店だからな。
提灯記事をあちこちに載せてマーケティングをがんばってるんだろうけど、
ド素人じゃあるまいし、それに乗せられる奴もいないわな(www
提灯記事をあちこちに載せてマーケティングをがんばってるんだろうけど、
ド素人じゃあるまいし、それに乗せられる奴もいないわな(www
そろそろ次スレの季節
あと1ヶ月は持つべ
oppaiとかの方がかわいい
コントローラとビューって
本当にファイルとして分ける必要あんのかな？
大抵のFWはディレクトリが根本から分かれてるから、
対応関係の確認が微妙にもたついたりする。
同じファイルの前半はコントローラ、後半がビューでもいい場合も
多いんじゃないか。
本当にファイルとして分ける必要あんのかな？
大抵のFWはディレクトリが根本から分かれてるから、
対応関係の確認が微妙にもたついたりする。
同じファイルの前半はコントローラ、後半がビューでもいい場合も
多いんじゃないか。
>>990
MVCを理解してくれ
MVCを理解してくれ
mvcは名前つけただけだからどうでもいいが、mvcが表す概念の価値が理解できないならいまの主流のフレームワークは使えないな。
993 ：nobodyさん：2007/10/17(水) 15:10:03 ID:deo3V8qx
>>990ではないんだが、俺もmvcあまりよくわかってないと思うんだ
相乗りさせてくれまいか
mが独立してるべきってのは納得なんだが、
c１にv１のとき１ファイルでもいいんじゃまいか？
とかおもっちまうんだが、１ファイルにしちゃだめな理由って何なのかな？
smartyとか使ってる＝なし崩し的にvをsmartyで独立実装
って感じになってるだけで、本当の意味でcとvを独立させる理由
ってのを理解してない気がするんだ＞俺
といいつつ、cとvが独立してれば、vを他のテンプレートシステム
での置き換えが用意なんだろうな。とは思うんだが、
cとv分けることのメリットってこんなもん？
経験豊富な人教えてくれまいか？
相乗りさせてくれまいか
mが独立してるべきってのは納得なんだが、
c１にv１のとき１ファイルでもいいんじゃまいか？
とかおもっちまうんだが、１ファイルにしちゃだめな理由って何なのかな？
smartyとか使ってる＝なし崩し的にvをsmartyで独立実装
って感じになってるだけで、本当の意味でcとvを独立させる理由
ってのを理解してない気がするんだ＞俺
といいつつ、cとvが独立してれば、vを他のテンプレートシステム
での置き換えが用意なんだろうな。とは思うんだが、
cとv分けることのメリットってこんなもん？
経験豊富な人教えてくれまいか？
vにロジック書くと共有しにくいとか。
たとえばロジックは同じだけど状態によってviewが変わるケース
たとえばロジックは同じだけど状態によってviewが変わるケース
ｖとｃを１ファイルにするくらいならｖとｍじゃね？
ロジック（プログラム）とデザインの分離で、C+MとVは分かれる。
ロジックは、データと処理に分離すると、MとCに分かれる。
だから、全体としてMとVとCに分かれると。
大雑把にはこんなかんじになるのでしょうか？
ロジックは、データと処理に分離すると、MとCに分かれる。
だから、全体としてMとVとCに分かれると。
大雑把にはこんなかんじになるのでしょうか？
おまいらギリギリまで会話かｗ
次スレを早くぅ
次スレを早くぅ
おれが1000ゲット
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。