2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【PHP】フレームワークについて語るスレ7【総合】

1 :nobodyさん:2007/06/09(土) 09:48:36 ID:6f8TWb7Z
前スレ
【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]フレームワークについて語るスレ3[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/
[PHP]フレームワークについて語るスレ2[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/

2 :nobodyさん:2007/06/09(土) 10:11:32 ID:???
>>1


3 :nobodyさん:2007/06/09(土) 10:39:24 ID:???
↓以下Rubyを崇めるレス↓

4 :nobodyさん:2007/06/09(土) 10:49:27 ID:???
>>1


5 :nobodyさん:2007/06/09(土) 15:12:01 ID:???
そろそろまともなフレームワーク整ってくれ。
php6まで無理かな?

6 :nobodyさん:2007/06/09(土) 20:51:22 ID:???
乙!

7 :nobodyさん:2007/06/10(日) 00:40:05 ID:???
おつ

8 :nobodyさん:2007/06/10(日) 02:33:44 ID:???
agaviのこと、おまえら忘れてない?
agaviのこと、おまえら忘れてない?

9 :nobodyさん:2007/06/10(日) 02:34:47 ID:???
phpspotとかで今頃「Mojavi復活!」って書いてるけど
ずっと前からあんな状態だっつの

10 :nobodyさん:2007/06/10(日) 04:16:03 ID:???
PHPってPapparapa Hentai Pugyaの略って本当ですか?

       m9
        ノ
プギャー!  (^Д^)
      ( ( 9m
       < \

11 :nobodyさん:2007/06/10(日) 06:45:40 ID:???
“犯罪者のための言語”Rubyの作者が
作りの悪いウェブアプリの心配をするのが解せません
犯罪者がウェブアプリ作る方が危険じゃないでしょうか?
常識で考えて

12 :nobodyさん:2007/06/10(日) 08:22:43 ID:???
PHP on Rails

13 :nobodyさん:2007/06/10(日) 09:12:06 ID:???
DHHをもう一度PHPに振り向かせるにはどうしたらいいですか?
若い娘に乗り換えられて悔しいっ ビクビク

14 :nobodyさん:2007/06/10(日) 11:20:45 ID:g9vmzoll
>>9
だよな。何を今さら・・って思った。

15 :nobodyさん:2007/06/10(日) 11:59:43 ID:???
てかさぁ、テンプレでフレームワーク一覧くらい書けよ。

16 :nobodyさん:2007/06/10(日) 12:04:21 ID:g9vmzoll
>>15
どこまで入れるの?

17 :nobodyさん:2007/06/10(日) 12:22:11 ID:???
フレームワークの使い方がわかんないんだけど><

18 :nobodyさん:2007/06/10(日) 15:11:38 ID:???
Railsはオンラインで読めるドキュメントが少ないのが
ちょっとね。紙の本だとどうしても翻訳が遅くなってしまうし、
APIのリファレンスも見づらい。
とりあえず今すぐ何かフレームワーク使いたいなら
やっぱりPHPかなって気もする。

19 :nobodyさん:2007/06/10(日) 19:44:27 ID:???
若い娘っていうか、PHPの方が若いけどな。年齢的には。

20 :nobodyさん:2007/06/10(日) 20:42:13 ID:???
PHPは誰にでも股開くイメージ

21 :nobodyさん:2007/06/10(日) 21:12:48 ID:???
童貞を捨てるには丁度いいじゃないか。
つまりは、入門者には最適。

22 :nobodyさん:2007/06/10(日) 23:48:11 ID:g9vmzoll
おまけに中田氏自由

23 :nobodyさん:2007/06/11(月) 00:08:43 ID:???
>>18
RailsのAPIのリファレンスは結構というか超使えると思うが...
あのレベルのリファレンスマニュアルがPHPのフレームワークにも欲しい。

24 :nobodyさん:2007/06/11(月) 00:13:00 ID:???
ZFのドキュメントは判りやすいと思うよ

25 :nobodyさん:2007/06/11(月) 02:00:08 ID:???
やっぱ日本男児なら日本で開発されたRubyを一度はやっておくべきだろう


26 :nobodyさん:2007/06/11(月) 03:08:20 ID:???
awkが最強

27 :nobodyさん:2007/06/11(月) 04:03:42 ID:???
Matzがアメリカナイズされているから日本男児ではない。よってRubyも所詮は異国のものだ

28 :nobodyさん:2007/06/11(月) 05:28:18 ID:???
日本男児を標榜するなら
なでしことか言う奴使えや

29 :nobodyさん:2007/06/11(月) 08:42:41 ID:???
やっぱ日本男児なら日本で開発されたなでしこを一度はやっておくべきだろう

30 :nobodyさん:2007/06/11(月) 08:45:13 ID:???
やっぱ日本女児なら日本で開発されたなでしこを一度はやっておくべきだろう

31 :nobodyさん:2007/06/11(月) 08:48:35 ID:???
日本男児ならますらおをやるべき

32 :nobodyさん:2007/06/11(月) 09:07:19 ID:???
PHP on Rails

33 :nobodyさん:2007/06/12(火) 00:35:26 ID:???
http://classic.guesswork.jp/

これってどうなん?
規模の小さい開発をPHPでって時は
こういうののほうが便利かな

34 :nobodyさん:2007/06/12(火) 00:41:44 ID:???
php4かつ小規模ならいいのでは

35 :nobodyさん:2007/06/12(火) 02:30:23 ID:???
PHP嫌いのヒゲはブログで紹介してる本本当に全部読んでんのか?
どんな速読法マスターだよ

36 :nobodyさん:2007/06/12(火) 04:19:12 ID:???
>>35
>どんな速読法マスターだよ
http://netafull.net/diary/019223.html
これみとけ

37 :nobodyさん:2007/06/12(火) 06:42:39 ID:???
>>36
それはもともと10分で理解できる程度の内容の本だっただけでは・・・

38 :nobodyさん:2007/06/12(火) 09:05:51 ID:???
10分で読めって言われれば、実用情報程度の新書なら
本読みなら読めるでしょ。速読法とか関係ない。

39 :nobodyさん:2007/06/12(火) 11:29:45 ID:???
ダニー?

・・・ダニ?

・・・・・・キモス

40 :nobodyさん:2007/06/12(火) 17:32:02 ID:???
髭とかどうでもいいよ。
オブジェクト脳のないやつはほっとけ。

41 :nobodyさん:2007/06/13(水) 00:02:56 ID:???
           ,, -──- 、._
        .-"´         \.
        :/   _ノ    ヽ、_ ヽ.:  PHPerがオブジェクト脳て・・・
        :/   o゚((●)) ((●))゚oヽ:
      :|       (__人__)    |:
      :l        )  (      l:
      :` 、       `ー'     /:
       :, -‐ (_).        /
       :l_j_j_j と)丶─‐┬.''´
          :ヽ   :i |:
             :/  :⊂ノ|:

42 :nobodyさん:2007/06/13(水) 00:26:36 ID:???
子飼はIQが高いらしいし、速読とかも出来るのかモナ。
しかし、>>40-41の流れがツボに入った。

43 :nobodyさん:2007/06/13(水) 01:56:37 ID:???
ここで本人が一言

↓↓↓ドゾー

44 :nobodyさん:2007/06/13(水) 02:04:10 ID:???
Perl>>>>>>>>>>>>>c>>Ruby>>Python>>PHP

m9(^Д^)プギャーーーッ

45 :nobodyさん:2007/06/13(水) 02:43:43 ID:???
>>44
お前程度の認識の奴はPHPのHTML埋め込み部分以外は全部挫折。
Cはかじっただけ。Javaすら知らず、すでに30過ぎ。
何も出来ないからRubyやPython先取りしようと
手をだすけれど全部中途半端。

出来るのはPerlで掲示板レベルで止まってる。
向いてないから転職先探せよm9(^Д^)

46 :nobodyさん:2007/06/13(水) 06:23:08 ID:???
選択肢多すぎて、知識が陳腐かするのが早すぎる

47 :nobodyさん:2007/06/13(水) 08:45:54 ID:???
Cはこの先10年くらい最低安泰だろ。

48 :nobodyさん:2007/06/13(水) 08:49:12 ID:???
>>47 Cは今後も安泰だと思うが、Cの使い道をおしえてくれ

49 :nobodyさん:2007/06/13(水) 08:57:22 ID:???
他言語を学ぶ上で確実な土台になる。
これからどんな新しい技術が出てきても、Cで得た知識や経験は無駄にならないだろ。
PerlもPHPもCから来てる品。

50 :nobodyさん:2007/06/13(水) 11:42:00 ID:???
>>48
画像処理とかハードに近い部分とかではまだまだ一般的だと思うが。

51 :nobodyさん:2007/06/13(水) 12:36:17 ID:???
組み込み系もほぼC言語だな。Javaもあるけど

52 :nobodyさん:2007/06/13(水) 12:53:45 ID:???
素朴な疑問なんだが
なんでc++で作らないの?
遅くなるの?

53 :nobodyさん:2007/06/13(水) 13:07:42 ID:???
ソフトウェア作るときはC++じゃないのか?
組み込みはそこまで複雑ではないからCでいけるのでは?

54 :nobodyさん:2007/06/13(水) 14:47:12 ID:???
C++はウンコ

55 :nobodyさん:2007/06/14(木) 04:50:17 ID:???
PHP5で書かれた軽量のフレームワークって何があるかな?
ちいたんくらいがベストなんだが、PHP4だしな。
ZENDはちょっと重過ぎる。

56 :nobodyさん:2007/06/14(木) 05:22:44 ID:???
zendが重いとなると、他のフレームワークは難しいんじゃないかな。

だいぶ前に触ったときは「必要になった時に必要なものを使う」という感じだったから、コード量は少し多くても随分速かった。
他のPHPフレームワークと比べてね。

といっても最近のzendはいじってないから分かんないけど。

57 :nobodyさん:2007/06/14(木) 05:22:52 ID:???
CIはPHP4/5でわりと軽いけど
PHP5専用ってのはないね

58 :nobodyさん:2007/06/14(木) 06:14:56 ID:???
>>54
どのへんが?

59 :nobodyさん:2007/06/14(木) 08:06:43 ID:???
>>56
ごめん、書き方が悪かった。
重いってのは動作というより、ライブラリの分量って意味で言ったんだ。
確かにZENDは好きなとこだけ使えるから、軽いって言えるのかもね。

>>57
CIはいいね。

60 :nobodyさん:2007/06/14(木) 12:52:54 ID:???
ちいたんは、PHP4/5 割と高速ですよ。

61 :nobodyさん:2007/06/14(木) 13:43:56 ID:???
>>60
俺は>>55>>59なんだ。>>55も読んでから教えてくれ。

62 :nobodyさん:2007/06/14(木) 14:01:41 ID:???
単なる疑問なんだけど,4 で動くように書かれてても,
5 でも動くなら 5 で使えばいい気がするんだけど,ちいたんを 5 で使うと何かデメリットがあるの?
フレームワークは 4 用で,自分で書くコードは 5 で書けばいい,ってわけにはいかないのかな?

フレームワークレベルで例外とかの仕組みがサポートされていない,とかはデメリットになるかもな……

63 :nobodyさん:2007/06/14(木) 15:18:34 ID:???
>>61 まずは試すことだよ

64 :nobodyさん:2007/06/14(木) 19:47:08 ID:???
おまいら、
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

65 :nobodyさん:2007/06/14(木) 21:54:12 ID:???
効率化の方法か?

66 :nobodyさん:2007/06/14(木) 22:32:10 ID:???
CodeIgniter使い方が分りやすくていいね。
名前って大事だよね

67 :nobodyさん:2007/06/14(木) 22:49:54 ID:???
>>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のベンチ結果ひとつで比べんなっつーのwww
あのな、FWにおいて速さは一番大事な話じゃねーんだよ、
Hello worldベンチが遅いからsymfonyはダメってやつはバカ」

by フランチョス

68 :nobodyさん:2007/06/14(木) 23:47:27 ID:???
Symfonyは速度以外の面で
特にどういうところにメリットが大きいとお考えで?

69 :nobodyさん:2007/06/15(金) 10:37:29 ID:???
たかがHalloWorld程度の処理で遅さを露呈するSymfonyがダメダメなのは当たり前じゃないか。

フランチョスは馬鹿だな。

70 :nobodyさん:2007/06/15(金) 11:05:04 ID:???
>>67
すっげー重いビジネスロジックが
FWの違いだけで軽くなるならいくらでも使うさ。

所詮、大差なしwww


71 :nobodyさん:2007/06/15(金) 11:06:08 ID:???
HelloWorld最速のC最強!!
PHPなんてゴミカス

72 :nobodyさん:2007/06/15(金) 11:47:45 ID:???
http://userguide.cilab.info/toc.html
CodeIgniter ユーザガイド 日本語版 Version 1.5.3

和訳してくれた方どうもありがとうです。
CIの説明を読んだら俺でも理解できました。
これでやっとフレームワークデビューできそうですw\(^o^)/

73 :nobodyさん:2007/06/16(土) 17:57:10 ID:???
cakeかCIかZendか・・・

74 :nobodyさん:2007/06/16(土) 18:47:45 ID:???
翻訳されないと読めないって、英語できないと大変だな。
一応義務教育で英語習ってなかったのか?

C++で作られたOSってまだ無いしな。



75 :nobodyさん:2007/06/16(土) 20:01:32 ID:???
>>74
WindowsやClassic Mac OSは無視ですかそうですか。

76 :nobodyさん:2007/06/16(土) 20:43:48 ID:???
どっちもソース読んだことないし

77 :nobodyさん:2007/06/16(土) 20:56:55 ID:Zcz+cnSv
>>75
Linuxも無視だなw

78 :nobodyさん:2007/06/16(土) 21:20:48 ID:???
処理の最適化が必要なOSの下層レイヤーは普通Cでかくわな

79 :nobodyさん:2007/06/16(土) 22:39:29 ID:???
>>74
MonaOSは?

80 :nobodyさん:2007/06/17(日) 13:49:53 ID:???
PHPもCで書かれてるの?
なんでC++で書かないの?

81 :nobodyさん:2007/06/17(日) 15:30:20 ID:???
symfony言うほど遅い気はしないけどな。
前は確かに言うほど遅かった気がするが。

フレームワークとしてしっかり出来ているとは思う。

別に擁護するわけではないです。


82 :nobodyさん:2007/06/17(日) 16:12:12 ID:???
>>81
あれっ、俺すげー前のバージョン試してクソ遅かったから使うのやめたんだが、
いつのまにか速くなってたんだ。
どのあたりのバージョンから実行速度改善したんだろ・・

83 :nobodyさん:2007/06/17(日) 21:13:31 ID:???
C と C++ って,単純に「新しいしオブジェクト指向だから後者の方が良い言語」って話ではないからな……
Objective C だったらそう言えたんだろうか。知らんけど。

84 :nobodyさん:2007/06/17(日) 21:18:15 ID:???
>>83
Objective Cは動的型付け言語

85 :nobodyさん:2007/06/18(月) 05:07:11 ID:???
>>82
development環境は今でもクソ遅い。
production環境ならそれなりの速度は出てる。キャッシュしまくりだから。

でも俺はそのキャッシュしまくりなのがちょっと嫌い。


86 :nobodyさん:2007/06/19(火) 00:38:56 ID:???
agavi 0.11RC5リリース

87 :nobodyさん:2007/06/19(火) 02:14:58 ID:???
>>86
うほ!!まだ更新してたんだw

88 :nobodyさん:2007/06/19(火) 02:17:32 ID:???
>>81
symfonyは初期設定が面倒だな。
自分は慣れてるからさっさとできるが、
よくヒーヒー言う初心者の声を耳にする。
それを乗り越えた後のadmin generatorに感動しまくる声もね。

89 :nobodyさん:2007/06/19(火) 19:24:28 ID:???
frontend_devってそんなに遅いか!?



90 :nobodyさん:2007/06/19(火) 23:12:36 ID:vt1ydhWm
xdebug有効にしてるとか

91 :nobodyさん:2007/06/20(水) 05:54:33 ID:???
フランチョスが「symfony遅いって言う奴は馬鹿」ってわざわざ言うくらいだから
遅いって批判は結構あるんだろう

92 :nobodyさん:2007/06/22(金) 10:24:23 ID:58srRoch
おまえら、Ethnaの本もうすぐだぞ!
表紙かっこいい。オレ買うかもしんない。
http://www.cbook24.com/bm_detail.asp?sku=9784774131399

93 :nobodyさん:2007/06/22(金) 11:05:13 ID:???
こんな本書いてる暇があったらDBレイヤ周りもっと完成度上げろや

94 :nobodyさん:2007/06/22(金) 13:02:35 ID:58srRoch
>>93
PDO使えばいいじゃん

95 :nobodyさん:2007/06/22(金) 13:38:23 ID:???
俺Ethna+Syrupだけど
結構いいかんじ

96 :nobodyさん:2007/06/22(金) 21:24:49 ID:???
普通にcakeが出て欲しい

97 :nobodyさん:2007/06/22(金) 21:46:26 ID:???
本なんて無くても使ってれば分かるだろw

98 :nobodyさん:2007/06/23(土) 00:10:00 ID:nbx08fep
ZF希望

99 :nobodyさん:2007/06/23(土) 03:07:18 ID:???
いや本にまとまると安心すんだよ、情報の漏れがないかとか。
あとやっぱ本が手に持てて見やすい。

100 :nobodyさん:2007/06/23(土) 03:48:23 ID:???
うん、本があるほうがはかどることもあるよね。

101 :nobodyさん:2007/06/24(日) 03:07:17 ID:???
wikiにまとまってた方がいいな。
本じゃキーワード検索できん

102 :nobodyさん:2007/06/24(日) 15:43:19 ID:???
そもそも、Ethna本、宣伝してる奴って、誰なんだ? 

103 :nobodyさん:2007/06/24(日) 15:59:47 ID:???
著者 出版関係者 狂信者

104 :nobodyさん:2007/06/24(日) 16:11:56 ID:???
作者 書籍小売店 アフィリエイター

105 :nobodyさん:2007/06/24(日) 17:30:26 ID:SHnW2+KS
>>102
俺だよ俺

106 :nobodyさん:2007/06/24(日) 17:48:52 ID:???
>>105
胸がスッとしたぜ

107 :nobodyさん:2007/06/24(日) 17:52:54 ID:???
やるじゃねえか

108 :105:2007/06/24(日) 18:17:04 ID:SHnW2+KS
あぁ、、宣伝と取られたか。
俺自身、Ethnaってまだ使った事ないんだよね。
でも、本が発売されるって事で、ちょっとテンション上がって
ついつい貼っちゃったんだ。今後とも、自重するよ。

ちなみに俺はZendFrameworkに期待してる。

みんなごめんよ。本当にごめんにょ。


109 :105:2007/06/24(日) 18:18:51 ID:SHnW2+KS
うわ・・・ひどい日本語

110 :nobodyさん:2007/06/24(日) 20:30:29 ID:???
Ethnaとか終わってます。

111 :nobodyさん:2007/06/24(日) 21:33:47 ID:???
その本のvol.1がTurboGears X Pythonで、
vol.2がEthna x PHPという理由も良く分からん。
なんかのムックを単行本したのか?
ちなみになぜか俺vol.1買った。
内容は、まあページ数とサイズを考えれば
しゃーねーべ、、という感じ
Ethnaのほうは知らないが、そのページ数でPEAR , Smarty
PHPのインスコからMVCとは何か、認証まで言及してると
駆け足になりそうな予感。
でも本屋にあったら見てみるわ

112 :nobodyさん:2007/06/24(日) 22:15:46 ID:???
>>92
いいなー、買おうかな。

113 :nobodyさん:2007/06/25(月) 12:08:35 ID:2mWhEXtz
vol.2って何の事だと思ったら、vol.1はPythonだったのね。
需要あんのかな?

114 :nobodyさん:2007/06/25(月) 18:05:23 ID:???
「需要なさそうな所を突く解説書シリーズ Vol.2」なんじゃね

115 :nobodyさん:2007/06/25(月) 18:41:08 ID:2mWhEXtz
>>114
な〜るへそ。
じゃあ、第3弾はCatalystだな。
でも、Catalystの方が重要あるか。

116 :nobodyさん:2007/06/25(月) 19:25:32 ID:???
CatalystならまだしもEthnaはないよな。
まぁ日本発で一番使われてるFWだからかな。


117 :nobodyさん:2007/06/25(月) 19:41:49 ID:???
出版社同じだし、
http://7andy.yahoo.co.jp/books/detail?accd=31738344
のムックの売上見て単行本化決めたのではと思われ

なのでCatalystはありうる。そして次はMaple で最後にRoRだ。
わけわからん

118 :nobodyさん:2007/06/25(月) 19:46:22 ID:???
Mapleとか。。

119 :nobodyさん:2007/06/25(月) 21:42:04 ID:???
DjangoとPieceも...

120 :nobodyさん:2007/06/25(月) 22:52:32 ID:2mWhEXtz
Mapleって開発譲渡したんじゃないの?

121 :nobodyさん:2007/06/26(火) 01:27:55 ID:???
Mapleは開発放棄じゃないの?
てか開発者が行方不明とか?
違う人間がMapleのコードで違うプロジェクト始めたんじゃ?

どっちにしろ、終わってるな。

122 :nobodyさん:2007/06/26(火) 02:43:19 ID:???
作者に放棄→それを引き継ごうとした開発者も放棄
って流れだったと思う
二度捨てられた不憫な子=Mapleたん

123 :nobodyさん:2007/06/26(火) 12:41:14 ID:+m1wrnTY
・・・かわうそう

124 :nobodyさん:2007/06/26(火) 13:03:43 ID:PKXMvhY5
フレームワーク使ったことない俺が言うのもなんだげど
PEARってフレームワークだよな?

125 :nobodyさん:2007/06/26(火) 14:32:57 ID:???
zendは1.0なのにRC1,2,3とか
このままRC99まで行くつもりなのか!?

126 :nobodyさん:2007/06/26(火) 14:34:55 ID:+m1wrnTY
>>124
lib

127 :nobodyさん:2007/06/26(火) 18:16:12 ID:???
>>124
PEAR は PHP のクラスライブラリを統合して統一的に扱うためのフレームワークだけど,
ここのスレでいうフレームワークって
「Web アプリケーション フレームワーク」に狭義に絞ってる気がするので
そういう意味では違うかもしれん.

128 :nobodyさん:2007/06/27(水) 02:16:36 ID:???
>>124
HTML_QuickFormはプチフレームワークかもしれん。

実装が腐ってるから、もういまから新規で覚えてもしゃーないけどね。

129 :nobodyさん:2007/06/27(水) 14:51:55 ID:54iUTIH0
Ethnaの本買ってきたぞ。
まだ、中身読んでないけど、今後のフレームワーク本の出版予定が書いてあったので、
一応知らせておく。gihyoから「Symfony×PHP」「Django×Python」が出る予定だそうだ。

Symfonyはいいにしても・・・Djangoって。

130 :nobodyさん:2007/06/27(水) 15:15:36 ID:???
RailsやったことあるやつはCakeがおすすめ。


131 :nobodyさん:2007/06/27(水) 15:19:45 ID:???
>>129
ジャンゴは檄速だっつの
ドジでのろまな亀のPHPフレームワーク乙

132 :nobodyさん:2007/06/27(水) 16:20:56 ID:???
>ドジでのろまな亀
歳がばれるぞw

133 :nobodyさん:2007/06/27(水) 16:52:00 ID:???
>>132
実の息子かもしれんぞ

134 :nobodyさん:2007/06/27(水) 20:46:21 ID:???
Cake使うならRails使ったほうがよいと思われ

135 :nobodyさん:2007/06/27(水) 21:08:37 ID:???
>>134
その通りかもしれないがスレ違いによるループが確実

136 :nobodyさん:2007/06/27(水) 21:58:01 ID:???
Ethna本読んだが、結論から言うと買う必要なし。
ネットであれ以上の情報がすぐに手に入る。
本で読みたい人にはいいかも。
500円くらいの価値はある。

137 :nobodyさん:2007/06/28(木) 16:57:01 ID:b86P8EwS
>>134
Railsは本番環境への移行がめんどすぎる。
それに加えてシェアRuby<PHPを考慮するとCakeの大勝利。

138 :nobodyさん:2007/06/28(木) 17:01:05 ID:???
漏れもいろいろ理由付けてRails使わないでいたけど、
1回使ったら陥落しますた。

今はお客さんの希望に合わせてRails > Symfony > Cake
という感じで、やってます。

139 :nobodyさん:2007/06/28(木) 17:41:26 ID:???
>>137
>Railsは本番環境への移行がめんどすぎる。

それって具体的にどういうこと?

140 :nobodyさん:2007/06/28(木) 18:10:36 ID:b86P8EwS
>>139
Cakeみたいにフォルダコピーするだけでほとんど完了。ってわけにはいかない。
Railsのサーバ使うわけにはいかないし、cgiじゃ遅いし、fastcgiはめんどくさい。

141 :nobodyさん:2007/06/28(木) 18:13:59 ID:???
たいしてめんどくさくもねえし。

142 :nobodyさん:2007/06/28(木) 18:17:08 ID:???
Railsってrsyncでデプロイする機能があったような。

143 :nobodyさん:2007/06/28(木) 18:59:49 ID:???
>>141
初級〜中級者には敷居高いと思うよ

144 :nobodyさん:2007/06/28(木) 21:59:56 ID:???
まぁたしかにPHP環境ほど簡単というわけじゃないですね。
サーバが全てDebianってわけじゃないですから。

145 :nobodyさん:2007/06/28(木) 22:50:03 ID:???
>初級〜中級者
の範囲がわからんけど、そういうのはFWを使うのがそもそも間違いでしょ

146 :nobodyさん:2007/06/28(木) 23:41:53 ID:???
上級者にしか使えないならほとんど使われてねぇよ

147 :nobodyさん:2007/06/29(金) 00:04:14 ID:???
そんなこたーない

148 :nobodyさん:2007/06/29(金) 01:24:39 ID:???
んなこたーないなんて言ってしまうと、世の中上級者ばかりになってしまう。

149 :nobodyさん:2007/06/29(金) 01:38:41 ID:???
フレームワークは中級程度が一番使うべき。
初級者は使えないと思うが。

150 :nobodyさん:2007/06/29(金) 10:08:02 ID:???
フレームワークこそ初心者のもんだろ。
何やってるんだかわからないアホでも、それなりに組めてしまうんだから。

151 :nobodyさん:2007/06/29(金) 11:05:43 ID:???
組めるレベルは中級っていうんじゃないのか。
個人の感覚の違いだから、それ以上はつっこまないが、言葉の表面じゃなく意味するとこを読み取ってほしいな。

152 :nobodyさん:2007/06/29(金) 14:00:33 ID:???
初級とか中級とか絶対指標がないから掲示板の議論には向かない表現だなと思った


本心では「中級こそ使うべき」と思ってても
その中級を初級呼ばわりすることで
「そういう自分=上級」感を味わいたい奴とかもいると思うんだ

153 :nobodyさん:2007/06/29(金) 14:17:38 ID:???
>>151
俺の基準だと
初級者:ちょっとだけできる(仕事でやるのはしんどいレベル。)
中級者:普通にできる(普通に仕事でやっていけるレベル。真ん中のグレード。)
上級者:何でもできる(周りのプログラマからすげーって言われるレベル。)

この基準だと、初級者はフレームワークなしじゃ、まともに動くものは何一つ作れない。

154 :nobodyさん:2007/06/29(金) 15:33:32 ID:???
初級者にはMVCのアーキテクチャは理解できない
 ↓
理解せずに使うと必ずどっか壁にぶち当たる
 ↓
結局使えない

155 :nobodyさん:2007/06/29(金) 18:35:27 ID:???
>>152

まさに、その通りだと思う。

上級なんて・・・世界を見ろよといいたい(日本にも数十人はいると思うが)。
まぁ、152に賛成してこれを言うのもなんだと思うが。すまない。


156 :nobodyさん:2007/06/29(金) 21:02:41 ID:???
WebフレームワークってコントローラーとDB操作する部分とHTML表示する部分とを切り分けてるだけじゃん。
オブジェクト指向の理解なんて必要ない。

157 :nobodyさん:2007/06/29(金) 21:14:22 ID:???
オブジェクト指向の話なんか出てない



158 :nobodyさん:2007/06/29(金) 22:10:29 ID:u0ng+pVR
>>156
おまえこそ、オブジェクト指向わかってのかw

159 :nobodyさん:2007/06/30(土) 03:42:49 ID:???
>>158
156の言ってることは深いぞ。


160 :nobodyさん:2007/07/01(日) 05:07:50 ID:???
確かにな。純粋なオブジェクトで出来てないJAVAやPHPなどでオブジェクト指向は出来ないかも知れない。少なくともWebフレームワークはオブジェクト指向の理解はいらんな。
やはりRubyあたりがオブジェクト指向が語れる(実現できる)言語かな。

161 :nobodyさん:2007/07/01(日) 09:54:22 ID:???
いやべつにそんな話題は出てないのにレス書いたバカがいるというだけの話だが

162 :nobodyさん:2007/07/01(日) 11:46:11 ID:???
このスレはオブジェクト指向を語るスレになりました

163 :nobodyさん:2007/07/01(日) 20:44:17 ID:???
俺のちんこは素敵なオブジェ

164 :nobodyさん:2007/07/01(日) 22:26:55 ID:???
オブジェクト指向分からずしてフレームワークは使えない品

165 :nobodyさん:2007/07/01(日) 22:58:59 ID:???
まあオレオレFW作ってるひとは当然OOPしてるんだろうな

既製のFW使うのに、クラスが何なのかくらいは知らんとムリだが
GoFだのなんだのって話になるわけでもあるまい

166 :nobodyさん:2007/07/01(日) 23:51:37 ID:KBDlHz5H
オレオレFW作れるだけまだ上等だろう

167 :nobodyさん:2007/07/02(月) 01:38:45 ID:???
PHPでFWなんてそのうち時代遅れになるよ。

MyPHPAdminより高機能なDBオーサリングツールがついて
Flashみたいにオブジェクトをクリックして、プロパティの種類と名前追加して
自分でprotectedとかextendsとか何度も書かなくて良いようになる。
親クラスやインターフェースなんかを図でつなぐだけ。

FWみたいに実行環境でそのまま使われるモノではなくて
最適化したモノが書き出されるようになる。
編集するときはプロジェクトファイルで行うようになる。

フォームもドラッグアンドドロップでnameやaction指定して
typeを選ぶだけ。勿論DBと連動させられる。
マニュアルで記述もできる。

オブジェクトは、ECMAスクリプトと連動する事もできて、自由自在に
デスクトップGUIアプリのようにデザインすることも出来る。

来春発売で10万。
楽しみにしててくれ。

168 :nobodyさん:2007/07/02(月) 03:58:47 ID:???
Delphyか。

169 :nobodyさん:2007/07/02(月) 05:09:34 ID:???
Java系のIDEでもFlex BuilderでもVS.NETでも既にやってるし、いまさら自慢気に言うほどのものでもないよね。

170 :nobodyさん:2007/07/02(月) 09:59:36 ID:???
>>167 もうでてるじゃん。 Delphi for PHP

171 :nobodyさん:2007/07/03(火) 01:57:35 ID:???
先生質問!
いつも1人でオレオレFW使ってるんだが、ちょっと人と並行して作業する事になって、
さすがにオレのじゃ申し訳ないって思ってるところ。
初見ではCakePHPかCodeIgniterが良さそうな印象なんだけど、
実際の使用感とか感想とかあったら参考にさせて欲しい〜、お願いします。

172 :nobodyさん:2007/07/03(火) 03:28:50 ID:???
オマイが決めていいんならオレオレでもいいんじゃね?

173 :nobodyさん:2007/07/03(火) 06:30:50 ID:???
怠惰なやつにただで情報与えるのは気が進まないが、他の人の参考にもなるかもしれないから俺の使用感をメモっておく。
Cakeはデータベースとのアソシエーションが覚えるとやはり便利。外部ライブラリと併用すれば十分使える。実績も出てきた。
CIは、そのアソシエーションを削ることでよりシンプルにした感じ。Cake同様に他の機能も十分なので、FWとして合格点。

174 :nobodyさん:2007/07/03(火) 18:38:43 ID:???
>>173
そんな情報いらないよ(w

175 :nobodyさん:2007/07/03(火) 19:01:16 ID:???
>>173
俺FWはSymfonyしか使ったことないんだけど、DBからデータ持ってくるのは
やっぱりSQL文直書きしちゃうなぁ・・・。
SQL書かないと、後で見たときすごい解りにくくない?
でも、SQL文がPHP内に混じるとやっぱり汚いね。
PHP版S2Daoの、2way SQLが良さそうなんだけど、時間ないのでまだ見れてない。
includeするファイルが多くなり過ぎて、Symfonyと併せるとすっごい遅くなりそうな気もする。
そうなると、CIと組み合わせた方が良いのかな?

176 :nobodyさん:2007/07/03(火) 23:05:23 ID:???
ちょっとややこしくなると、結局同じようにややこしかったりするし、
SQL自体がそもそも簡便に抽象化されたものとしてあるんだから、
プレースホルダを使ったりするくらいでも別にいいよな。

177 :nobodyさん:2007/07/03(火) 23:33:46 ID:???
同意。
無駄にプァイル多くなるし。
あとから参照しずらい。

178 :nobodyさん:2007/07/04(水) 00:02:35 ID:???
まあCIのactive recordは使い物にならんから、SQLガチガチ書きたい奴はある意味お勧め。

179 :nobodyさん:2007/07/04(水) 00:15:23 ID:???
>>178のカキコも使いもんにならんから目を汚したいヤツには違う意味でお勧め。

180 :nobodyさん:2007/07/04(水) 03:43:53 ID:???
情報出さないで文句ばっかいってる生産性のないやつがいるな。

>>175
Symfonyは使ったことないけど、Cakeの方がシンプルだということだからもっとみやすいんじゃない?
Cakeは慣れれば、一目見ただけでどんなデータとってきてるか分かるよ。
SQL文書くならRailsを模倣してるSymfonyとかCakeとか使わないで違うFW使うべきなんじゃないかと思うけど。

181 :nobodyさん:2007/07/04(水) 09:20:11 ID:???
Cakeとsymfonyやったらどっちのほうが覚えやすい?

182 :nobodyさん:2007/07/04(水) 13:18:56 ID:???
railsはDB操作レイヤーといえばORMというような、間違った風潮を作ったね。

183 :nobodyさん:2007/07/04(水) 13:20:14 ID:???
一見コード量から言えばCakeの方が「覚えやす」そうだけど、
symfonyの方が業務にすぐ使えるだろうね。
「覚える」ことは必要ないし。マニュアルにしたがってサクサクという感じで進むよ。
それと引き換えに「退屈さ」に耐えなければならない、という感じ。
横道にそれながらも楽しんで仕事したいならCake。


184 :nobodyさん:2007/07/04(水) 14:51:32 ID:???
>>181 業務ならCake 趣味ならSymfony (Cakeは4,5対応ということだけで、別に悪意はないから) 

185 :nobodyさん:2007/07/04(水) 17:50:11 ID:PWYSy+4p
退屈な方がいいよね

186 :nobodyさん:2007/07/04(水) 19:11:13 ID:???
ああ、そう思う。仕事はそういうもんだな。

187 :nobodyさん:2007/07/06(金) 02:47:18 ID:???
>>184
逆だな。
今更4なんて実用に耐えないから、両対応にして精度落としてるcakeは趣味にしか使えん。

188 :nobodyさん:2007/07/06(金) 04:09:17 ID:???
精度なんか落ちてないぞ。4と5に対応できるようにコードを裏側で切り替えてるだけ。
普通に優れてる

189 :nobodyさん:2007/07/06(金) 09:49:02 ID:???
>>187
精度って何の精度?

190 :nobodyさん:2007/07/06(金) 09:59:30 ID:???
業務でSymfony使えばいいじゃない。   使いたい人は・・・。

191 :nobodyさん:2007/07/06(金) 10:00:04 ID:???
むしろsymfonyが趣味にしか使えないというところに、突っ込むべきかと。
ありえんだろ。

192 :nobodyさん:2007/07/06(金) 10:17:04 ID:???
symfonyは趣味にはキツいな。どんなマゾやねん

193 :nobodyさん:2007/07/06(金) 20:14:10 ID:???
〉189
性能といいたいのだと思われ

194 :nobodyさん:2007/07/06(金) 22:44:53 ID:???
趣味でやるなら、cakeかEthna。
仕事はsymfony。

仕事ならサーバー構築からできるからphp5を選択できるけど、趣味だと安いサーバーを借りたりするので
php4で動くやつの方がいい。


195 :nobodyさん:2007/07/06(金) 23:27:00 ID:???
>>194 のような趣味のような仕事をしてみたい。

196 :nobodyさん:2007/07/07(土) 05:07:04 ID:1nTQ87n9
まず趣味で色々使ってみる。
そして自分なりのFAを出す。
それを仕事の現場で推薦する。
通らないこともあるが自分はこうしてる。

「2chで支持されてたので、これ使います。」
じゃまずいだろ。w



197 :nobodyさん:2007/07/07(土) 06:05:50 ID:???
http://www.symfony-project.com/weblog/2007/07/06/php4-is-dead-long-live-php5.html

フランチョス「PHP4 is dead! いまどきPHP4にも対応してる中途半端なCakeはプギャーものだ」

198 :nobodyさん:2007/07/07(土) 08:49:30 ID:???
正直、symfonyは機能をあれこれ盛り込んでるから
そこそこ利用出来るようになるまで時間が掛かりすぎる & ソースが見難い。


199 :nobodyさん:2007/07/07(土) 10:08:07 ID:???
>>198
よくそういう意見を聞くけど、まずは自分が使いたいと思う機能だけ
使っていけば、複雑でも何でもないんじゃないかと思うんだが、どう?
ソースについても、Cakeの方が汚いと聞いた事はあるが、確認はしてないなぁ。
あ、見難いと汚いは違うか?

200 :nobodyさん:2007/07/07(土) 10:13:33 ID:???
うん、むしろ、なにも考えずに使えてしまうよ。

symfonyに実装されてる機能を「そこそこ利用できる」学習する時間
<Cake(とかCIとかライトウエイトのFW)を使って自作点検する時間

って感じだから、symfonyは「退屈」なのよ。でもそれくらいならsymfony
よりは今後はZF使いたい気がする。

201 :nobodyさん:2007/07/07(土) 11:01:17 ID:???
ZFはあんだけ時間かけてあのザマだからなあ

202 :nobodyさん:2007/07/07(土) 11:10:13 ID:???
ん、ZFわるくないじゃん。機能もそろってるし。
どこが「あのザマ」なの?

203 :nobodyさん:2007/07/07(土) 11:30:41 ID:???
ZFがJAVAライクなフレームワークになってるのも分からず、叩きたがってる中二病なので、ご勘弁ください。

204 :nobodyさん:2007/07/07(土) 11:32:56 ID:???
ZFはフレームワークって言うより
ライブラリ感が強いから
自前で用意しなきゃいけないことが多い
ソースは読みやすい

205 :nobodyさん:2007/07/07(土) 11:45:21 ID:???
symfonyあたりからZF見て足らないっていう部分が、
本当にFWの必須要素なのかが疑問だけどね。

206 :nobodyさん:2007/07/07(土) 12:53:56 ID:???
別にsymfonyを叩きたいわけじゃないがsymfony信者多いな

207 :nobodyさん:2007/07/07(土) 13:00:32 ID:???
PHP4って今でも多くのサイトで使われてるだろ。
PHP5はメモリを食いすぎるからね。
シンフォニーみたいな高機能なフレームワークはエクステンション化しないと実用的でないね。

208 :nobodyさん:2007/07/07(土) 14:28:41 ID:???
> PHP5はメモリを食いすぎるからね。
具体的な数字希望



209 :nobodyさん:2007/07/07(土) 15:16:07 ID:???
海外国内問わずPHP4互換のFW未だにアップデートし続ける
FWの作者に告ぐ、はっきり言って老害だ、とっとと辞めてくれ
少しでもPHPの未来を考える気があるなら
そのサポート対象から4を切れ、今すぐに

そしてその4互換FWで未だに4のコードを書きつづけるユーザの人達、
4のコードでそのFWの使い方やサンプルをブログに書きつづける人達、
5のサポートをしないレンタルサーバ管理者の人達、
どうか心改めこれから5をインストールして5のコードを書くか
PHPを捨て去るかどちらかを選択して欲しい

これ以上4のコードを生産するべきではない
これ以上4のコードを書く人間を生産するべきではない
これ以上4のコードを書く人間を放置していてはいけない

PHPユーザは尊厳の意をもって4を葬り去るべき

210 :nobodyさん:2007/07/07(土) 15:51:51 ID:???
>>209
4のコードはたいがい5でも動くだろ・・。
5を普及させたいなら、レンサバ屋に5を入れるように頼んどけ。
そして君は自分の愚かさを自覚してもっと謙虚になりなさい。

211 :nobodyさん:2007/07/07(土) 15:57:10 ID:???
仕事であの中途半端なオブジェクト指向をさわりたくない。

212 :nobodyさん:2007/07/07(土) 16:45:01 ID:ORHn68Tc
PHP5は最近レンサバでも入ってるよ。
ってか、最近は最悪でもVPS以上を使わせることにしてる。

213 :nobodyさん:2007/07/07(土) 22:00:26 ID:9N+o65yz
 最近symfony使い始めて、掲示板なんか試しにつくってみたけどさ、
設定ファイルでだいたいの調整ができるから、実際のビジネスに使う
には、結構いいんでは?
 ビジネスでは、スピードよりも保守性が重んじられることも多いから…。

214 :nobodyさん:2007/07/07(土) 22:12:49 ID:???
そうね。
何年も保守していくことを考えると、今さらphp4 てどうだろう。。
ていうか数年先にphpはどうなっているんだろうか。


215 :nobodyさん:2007/07/07(土) 23:46:32 ID:???
php6でまた仕様が変わってうんざりしてrubyに

216 :nobodyさん:2007/07/08(日) 01:50:14 ID:???
ruby 2 で仕様が変わってうんざりして pythonに


217 :nobodyさん:2007/07/08(日) 01:55:49 ID:???
一方perlはのんびりと静かに暮らしていた

218 :nobodyさん:2007/07/08(日) 03:09:35 ID:???
>>214
そもそもweb業界なんてリアルタイムで変わるものなんで
数年先なんて考えるだけ無駄。

219 :nobodyさん:2007/07/08(日) 05:34:20 ID:???
209の駄文にワラタ(笑)

220 :nobodyさん:2007/07/08(日) 12:19:25 ID:???
PHP4 is dead, long live PHP5!

221 :nobodyさん:2007/07/08(日) 12:22:42 ID:???
次のPHPにレキシカル変数、パッケージが導入されない限り、軽いPHP4で十分だな。

222 :nobodyさん:2007/07/08(日) 13:46:19 ID:???
php4が軽いとか思ってる奴まだ居たんだ…

223 :nobodyさん:2007/07/08(日) 15:11:30 ID:???
軽いPHP4で十分だよ!

224 :nobodyさん:2007/07/08(日) 15:53:46 ID:???
>>222
php4が軽いとか思ってるのではなく、軽いPHP4で十分なのではないか?

225 :nobodyさん:2007/07/08(日) 16:23:47 ID:???
じゃあ軽いPHP5でいいじゃん

226 :nobodyさん:2007/07/08(日) 19:31:40 ID:???
>>208
ペチパーは自分で調べることが出来ないのかねえ。
↓これでPHP4と5で計ってみろ。
ps -eo vsz,command | grep httpd | awk '{sum+=$1}END{print sum}'
PHP5はこのでっぷり太ったプロセスでHTMLも画像も処理しないといけないんだ。
もっともYahooみたいにモジュールを全部外してコンパイルすれば4も5もそんなに違わないのかも。
が、ビジネスロジックをエクステンションに任せるというのは極めて例外的なPHPの使い方だから参考にならないな。

227 :nobodyさん:2007/07/08(日) 20:40:27 ID:???
おまえら4と5の負荷の差がボトルネックに感じる程の
WEBアプリを作ってんのかと小一時間問い詰めたい

例外処理とマジックメソッド使えるだけでも
どれだけ開発が楽になって生産性上がると思ってんだよ
微々たるPHPのバージョン差の負荷とか考える前に
自分が開発するためのフットワークを
軽くすることを先に考えるのがプログラマだろうが

228 :nobodyさん:2007/07/08(日) 21:12:47 ID:???
富豪的発想が主流になるのはまだまだ先ってことだね。

目の前の負荷を軽くすることが優先されて、
それに割く労力を別の改良に振れるのに気づけない。

229 :nobodyさん:2007/07/08(日) 21:20:14 ID:???
>>226

バージョンで要求される標準モジュールがコンパイル時に違うのにあれこれ言うお前こそばかだろ

230 :nobodyさん:2007/07/08(日) 22:37:30 ID:???
ウェブアプリが複雑であるかそうでないかは関係ないよ。静的なHTMLでも画像でも同じこと。同じApacheを使うんだから。
むろんJavaのコンテナやfastcgiのように独立したアプリケーションサーバを用意して、ウェブサーバと分離できればいいんだが、そのコストがPHP5導入のメリットに見合わないつーこと。
バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。
それは、確かにVistaには目新しい機能があるが、重くてバギーだし、XPは安定していて困ることはないよ。っていうのと似たような話。

231 :nobodyさん:2007/07/08(日) 22:45:45 ID:???
パーソナルユースのOS話しと業務ベースのPHP導入の話しとを一緒にしてるってのが輪をかけてバカ



232 :nobodyさん:2007/07/08(日) 23:22:56 ID:???
> バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。

すごーーく単純な理由で、
ひとつのapacheで共存できないから。

重いから5にしないって話はほとんど(皆無ではない)聞かないね……

233 :nobodyさん:2007/07/08(日) 23:33:37 ID:???
PHP4 is dead = PHP is dead

      オ、オ、オワターオワオワオワター♪
      \    PHP is 全部 dead♪/
         ♪\(^o^) ♪
          _  )  > _ キュッキュ♪
        /.◎。/◎。/|
  \(^o^)/.| ̄ ̄ ̄ ̄ ̄|  |  \(^o^)/
    )  )  .|        |/   ノ ノ
((((  > ̄ > )))) \(^o^)/ ((( < ̄< ))))
              )  )
         (((  > ̄ > ))))

234 :nobodyさん:2007/07/08(日) 23:39:25 ID:???
>PHP5への移行が進まない
そもそも、これがどれだけ説得力を持つはなしなのかね。
個人レベルのPHPサイトとかが多いからそうなってるだけだろ。
業務ベースなら、新規は5が当然。既にあるやつもそれなりにリニューアルするなら5で
動かすようにリファクタかけるよ。

235 :nobodyさん:2007/07/09(月) 00:20:13 ID:???
PHP4脂肪→
オブジェクト指向が理解できない大多数のプログラマ(PHPerの80%)の離脱→
PHP脂肪

236 :nobodyさん:2007/07/09(月) 07:09:04 ID:???
drupal使ってるやついねーのかな
結構色々できると思うんだけど

237 :nobodyさん:2007/07/09(月) 08:16:21 ID:???
drupalはフレームワークなわけ?
何が魅力なの?
Webページつくるだけなら違うcmsあるし、Webサービスつくるなら足りないだろ?

238 :nobodyさん:2007/07/09(月) 09:11:54 ID:???
http://en.wikipedia.org/wiki/Drupal
にweb application frameworkって書かれてるよ
魅力はより少ない手間で作れたり、
高負荷のサイトで使われてたり、他のCMSより拡張性が高かったり。
cckとか色々モジュールがあるし、足りなければモジュールを作って拡張できるから
よっぽど複雑なことをするのでない限り、
大抵のことはdrupalでもできると思うんだが

Webサービスとかはできるかどうかわからないから、「結構」って表現にしたんだけど。
完璧じゃなくても、ほとんどの場合に十分使えればいいんじゃないかと

239 :nobodyさん:2007/07/09(月) 09:14:01 ID:???
すれ違い、それいっちゃ、XOOPSだって、フレームワークだろ。

240 :nobodyさん:2007/07/09(月) 09:25:18 ID:???
>>239
やっぱそっか。スマソ
でもフレームワークとの境界線って曖昧な感じになってきてるよね

241 :nobodyさん:2007/07/09(月) 09:55:48 ID:???
CMSがMVC意識せずにどんどん肥大化していく中で、今で言うフレーム
ワークが展開していったっていう時間の流れだよ。自分はDrupalはその
最中に出てきた「スマート」なCMS奴で、XOOPSは一時代前のカオスCMS
っていう押さえをしてる。

242 :nobodyさん:2007/07/09(月) 10:11:55 ID:???
もうカエリ
http://pc11.2ch.net/test/read.cgi/php/1166547036/

243 :nobodyさん:2007/07/09(月) 20:20:17 ID:sJXKqrgb
>>232
それあるなぁ。そこを簡単に共存できるようにしてれば、
余裕でPHP5が使えるようになったし、PHP4のコードもそのままにできた。

244 :nobodyさん:2007/07/09(月) 21:22:09 ID:???
共存なんか大した手間じゃない。

245 :nobodyさん:2007/07/10(火) 21:53:08 ID:???
まあriverse proxyとか含めればいくらでも出来るからなあ。

246 :nobodyさん:2007/07/10(火) 22:30:17 ID:???
大した手間かけずに共存環境に移行できるサービスばかりだったらそれでよかったんだろうさ

247 :nobodyさん:2007/07/10(火) 22:58:26 ID:???
?言ってる意味がわからん


248 :nobodyさん:2007/07/12(木) 22:09:49 ID:???
>>241
Drupalは何が「スマート」なの?
XOOPSはコード的に古いから乗り換えるか
ZFあたりで出てきそうなCMSを探すか考えているところ



249 :nobodyさん:2007/07/12(木) 22:47:39 ID:???
CMSなんか使ってるやつはくず。
コード気にする価値なし。

250 :nobodyさん:2007/07/12(木) 22:49:58 ID:???
249はよくいるような「皆が使ってるものを否定する自分カコイイ」なお子様に見えなくもないが
重厚長大なフルセットCMSって今もうそういう対象でもないよな

251 :nobodyさん:2007/07/12(木) 22:51:34 ID:???
どのFWもプレゼンテーション層がお粗末なのがどうもなぁ。
Smartyとかデザイナにしてみたらえらい負担だろうし。
もっと連携のしやすいものがあればいいんだけど。

252 :nobodyさん:2007/07/12(木) 23:00:41 ID:???
>>249
頭堅いなあ
出来上がるもんが結局同じなら、車輪の再発明しなくてもいいのに

253 :nobodyさん:2007/07/12(木) 23:18:40 ID:???
今日びPHPもできないデザイナーは死滅したらいいよ

254 :nobodyさん:2007/07/12(木) 23:30:31 ID:???
>>253
お前がな

255 :nobodyさん:2007/07/12(木) 23:36:15 ID:???
うむ。今更感の漂う話題ではあるが
俺もついでに今更感の漂う話を投下しとくか
 
 
 
 
おまいら、CMSが好きならZope + Ploneが最強じゃね?

256 :nobodyさん:2007/07/14(土) 16:14:49 ID:???
PHP4サポート打ち切りって影響甚大じゃね?
稼動してるサイトは膨大で
そのうちPHP5に移行できるのはどれだけあるのか?
サイバーテロが吹き荒れそう

257 :nobodyさん:2007/07/14(土) 16:36:57 ID:???
正直遅いぐらい
ようやく4排除への大義名分を得られるわけだ

258 :nobodyさん:2007/07/14(土) 17:44:07 ID:???
これで4しか入ってなかったレンサバも5に切り替わるといいな。

259 :nobodyさん:2007/07/14(土) 18:32:17 ID:???
今PHP3で走ってるサイトってどのくらいあるのかな

260 :nobodyさん:2007/07/14(土) 18:36:19 ID:???
4から5のリプレースがうまくいかなかったのを教訓に
6は5と共存できるような仕組みが欲しいところだな

261 :nobodyさん:2007/07/14(土) 18:48:36 ID:???
「仕様が完全上位互換」とかじゃダメなんだよな
共存させたい環境のひとは新環境での再テストとかもしたくないだろうし

262 :nobodyさん:2007/07/15(日) 00:13:42 ID:???
そもそもそのテスト費用が出して貰えないから困るわけで。

263 :nobodyさん:2007/07/16(月) 23:55:55 ID:jJDluNIm
皆さん地震大丈夫ですか?
NTTの災害用ブロードバンド伝言板(web171)はPHPなんだね。
不謹慎かもしれないけど、ちょっと嬉しい…。

264 :nobodyさん:2007/07/17(火) 11:54:09 ID:???
そうかな? PHPだと大規模災害時とかでロードが大きくなったときに
ホイホイとスケールできるのかちょっと心配な気が...


265 :nobodyさん:2007/07/17(火) 12:08:08 ID:???
スケールできるよPHP

266 :nobodyさん:2007/07/17(火) 14:31:06 ID:???
サーバ、ネットワーク周りの改善でなんとでもなる。

267 :nobodyさん:2007/07/17(火) 17:20:35 ID:???
>>251
連携のしやすいものって例えばどんなもの?
php直書きとsmarty以外の簡単な方法って浮かばないんだけど



268 :nobodyさん:2007/07/17(火) 17:32:55 ID:???
もっと直感的に使える高機能な独自タグってことだろ。MTみたいな感じじゃないか?

269 :nobodyさん:2007/07/17(火) 19:53:06 ID:???
>>251が曖昧で分からないが
連携に関しては基本デザイナに埋め込みさせなきゃいいと思うんだが

270 :nobodyさん:2007/07/18(水) 00:09:10 ID:???
そんな事いってるから日本のPHPサイトは手抜きデザインばっかりなんだが

271 :nobodyさん:2007/07/18(水) 00:32:13 ID:???
>>270
なんでそうなるんだよw
デザイン→HTMLコーディングまでデザイナ側で落とし込んで
PHPの埋め込みだけプログラマがやればって話なのに
「そんな事いってるから」の後になんで手抜きデザイン?

272 :nobodyさん:2007/07/18(水) 03:49:36 ID:???
あとで修正はいったらどうすんの?

273 :nobodyさん:2007/07/18(水) 09:01:06 ID:???
適時対応
静的部分だけの修正でデザイナだけで
修正できるようであればデザイナが修正
修正箇所に動的な部分を含んで
埋め込みコードの修正も伴うのであればプログラマが修正
で、なんか困ることある?

274 :nobodyさん:2007/07/18(水) 11:00:52 ID:???
結局デザイナーっていらないね

275 :nobodyさん:2007/07/18(水) 11:14:27 ID:???
状況から真っ当な結論を導き出すのが極端に下手な奴がいるな

276 :nobodyさん:2007/07/18(水) 11:31:24 ID:???
まともにデザイナと連携して仕事したことないんだろうな

277 :nobodyさん:2007/07/18(水) 16:25:07 ID:3R7D5ath
SmartyのかわりにPHPTALとかじゃだめなの?

278 :nobodyさん:2007/07/18(水) 17:49:45 ID:???
デザイナーと仕事するのが偉いと勘違いしてるやつがぽつぽつ

279 :nobodyさん:2007/07/18(水) 18:40:20 ID:???
自分が一番偉いんだと勘違いしてるやつが・・・

280 :nobodyさん:2007/07/18(水) 18:43:56 ID:???
コーダーでPGもこなす俺が真の勝ち組。
デザイナにはデザイン画像だけ描いてもらえばおk。
HTML起こすのは自分でできるもん♪

281 :nobodyさん:2007/07/18(水) 18:45:26 ID:sJyKZns/
全部一人でやれる奴が最強な訳で・・・

282 :nobodyさん:2007/07/18(水) 18:49:11 ID:???
実際ヘタな紙デザイナに変なHTML書かせるより
画像だけ描いてもらってHTMLに起こすのはプログラマがやった方が
結果としてキレイなものが出来上がる気がする

283 :nobodyさん:2007/07/18(水) 19:17:22 ID:???
ズレてきてるな
どう役割分担して連携するかって話だろ
誰が偉いとかおまえらのHTMLコーダー自慢とかはどうでもいいよ

284 :nobodyさん:2007/07/19(木) 10:09:35 ID:???
読みこみファイル数がすごい数になってるんだけど
アクセラレータつこうたら大丈夫?
お前らどうしてますか?

285 :nobodyさん:2007/07/19(木) 12:33:42 ID:???
>>284
まずコードを見直す

286 :nobodyさん:2007/07/19(木) 14:46:00 ID:Qs6wUD6U
>>284
主要フレームワークってeaダメだよね?

287 :nobodyさん:2007/07/19(木) 15:12:56 ID:???
cakeはいけてますが

288 :nobodyさん:2007/07/19(木) 21:29:14 ID:???
なんでeaってダメなの?
xcacheならOK?

289 :nobodyさん:2007/07/19(木) 21:44:14 ID:???
異常動作することがあるらしいね>ea
アクセラレータのスレにあったはず
別にフレームワークは関係ないと思うが

290 :nobodyさん:2007/07/20(金) 04:21:50 ID:???
>>285
フレームワーク自体がファイル読みこみまくりだからコード見直しても意味ない
hello,worldですらファイルが数十個読まれる
つまりフレームワーク使うのは阿呆
ついでにいえばウェブプログラムごときでオブジェクト指向使うやつも阿呆

291 :nobodyさん:2007/07/20(金) 04:56:45 ID:???
とオブジェクト指向が理解できない阿呆が申しております。

292 :nobodyさん:2007/07/20(金) 09:49:57 ID:xk3U0lu8
protectedな変数持ってるとEA動きません。

293 :nobodyさん:2007/07/20(金) 10:14:17 ID:???
まじで?
俺オワタ\(^o^)/

294 :nobodyさん:2007/07/20(金) 10:19:26 ID:???
本当に必要なファイル読み込みなのかどうかコードを見直せ。
FW側で不要なインスタンスを発行しまくっているようなら、
それをコロすように継承自前クラスで上書き。
FWって結局汎用だから、MVCの過程で、余分な処理をしてることが往々にしてある。
次に、ページキャッシュを考えろ。キャッシュ処理可能ページとそうでないページの
振り分けをちゃんとできるようにコードを見直す。
アクセとかハードウエア性能向上という手がつかえないなら、それしかないだろう。

295 :nobodyさん:2007/07/20(金) 10:35:03 ID:???
気にしないのが一番

296 :nobodyさん:2007/07/20(金) 12:42:12 ID:???
inodeは上限あるけど
オープンできるファイルに上限てあんの?

297 :nobodyさん:2007/07/20(金) 12:59:27 ID:???
少なくともlinux, bsdにはある
windowsは知らん

298 :nobodyさん:2007/07/20(金) 14:44:44 ID:???
>>292
いつの話よ? 0.9.5.1 では直ってる。

299 :nobodyさん:2007/07/20(金) 21:35:41 ID:g4/DmFJL
>>298
protectedの件は直ったらしい。
でも、例外キャッチできないんだって。
http://d.hatena.ne.jp/shimooka/20070507/1178504848

300 :nobodyさん:2007/07/20(金) 21:40:09 ID:???
>>299
オプティマイザのバグということは、オフにすれば (eaccelerator.optimizer = 0) おk?
キャッシュの恩恵は受けられるし。

301 :nobodyさん:2007/07/20(金) 21:53:04 ID:???
だいたいPHPはバギーすぎるんだよ。何、PHP5は安定しているので、PHP4は開発中止?こっちはキムチパッチ当ててる所だ。

302 :nobodyさん:2007/07/20(金) 22:17:02 ID:???
>>299
それは使い物にならんな・・・

303 :nobodyさん:2007/07/21(土) 02:40:16 ID:???
オプチマイザなんてたいした効果もないんだからオフでおk

304 :nobodyさん:2007/07/21(土) 05:04:00 ID:???
ポン入れでまもとに使えない時点でアウト。
たまに案件でphp.iniをグチャグチャいじってさらにPHP_VALUEまでいじってるあるのに遭遇するが、
開発サーバで再現しきれん設定とかがあってむかつく。

305 :nobodyさん:2007/07/21(土) 10:31:30 ID:???
アウトならこんなところまで来てネガってないで他の言語使えばいいじゃん……
何がしたいんだ?
再現しきれんってのは「設定できる場所を自分が把握できてない」って意味なだけだろ?

306 :nobodyさん:2007/07/22(日) 08:29:26 ID:???
O/Rマッパって何のためにあるんだ?
返り値がオブジェクトの配列である必要性がねーだろ
普通の連想配列で何の問題もない

307 :nobodyさん:2007/07/22(日) 11:19:49 ID:???
>>306
OOP的にかっこいいから、とかそういうことなんじゃない?
たぶんOOP的なものと非OOP的なものが混在するのを嫌ってるんだろう。

308 :nobodyさん:2007/07/22(日) 11:31:11 ID:???
OOPのためにマッパが作られてるんだけどね。

309 :nobodyさん:2007/07/22(日) 12:26:09 ID:???
何の問題もないなら使わなきゃいい
まあそれをわざわざここに書いてる事自体
「なんでO/Rマッパがいいのかわかりません」
って書いてるようなもんなんだけどねw

310 :nobodyさん:2007/07/22(日) 12:41:59 ID:???
>>309
お前も分からないんだろ
強がるなよ

311 :nobodyさん:2007/07/22(日) 13:03:41 ID:???
>>310
普通に使ってるよ
てかO/Rマッパのメリットが分からないとか
O/Rマッパ使う理由がかっこいいからとか
そんなレベルでFWのスレに来る奴ってなんなのwww

312 :nobodyさん:2007/07/22(日) 13:05:08 ID:???
>>311
メリットが分からないまま使ってるんだろ
やせ我慢乙wwww

313 :nobodyさん:2007/07/22(日) 13:28:44 ID:???
Oは、おぶじぇくとのおー

314 :307:2007/07/22(日) 13:30:46 ID:???
そういやFWのスレだったw

315 :nobodyさん:2007/07/22(日) 17:05:31 ID:???
ヘルパーってかっこつけて言ってるけど単なる関数なんだな
本来viewのものなのに
グローバルスコープにあるのもダサいことこの上なし

316 :nobodyさん:2007/07/22(日) 17:07:10 ID:???
オーバーライドできないのもまたビッチなり

317 :nobodyさん:2007/07/22(日) 17:22:22 ID:???
それはおれも思った
ただのグローバルスコープにある関数がいつのまにヘルパなんて呼ばれて美化されてんだ,ってw

変数は view 展開時のみグローバルスコープに登録されるものが多いようだから
関数もそうするようになってるフレームワークがあってもいいように思うが
パフォーマンスとか色々の面で現実的じゃなさそうかな……

318 :nobodyさん:2007/07/22(日) 17:32:02 ID:???
CakePHPとかsymfonyのヘルパーってクラスじゃなかったっけ

319 :nobodyさん:2007/07/22(日) 17:34:57 ID:???
rubyみたいにレシーバが省略できないから
railsのviewライクに使えるよう突き詰めた結果がああなったと思われる
まあ早い話が$this書きたくないっていうことだな

俺もview helperとはいえ単なるfunctionにするのは好みじゃないな
ZFのview helperはクラス(オブジェクト)になっている
view helperがfunctionになってるのはsymfonyだっけ?他にもあるかな

320 :nobodyさん:2007/07/22(日) 17:36:07 ID:???
>>318
cakeは見たことないけどsymfonyは関数だった

321 :318:2007/07/22(日) 17:39:28 ID:???
あ、symfonyはfunctionか。ごめん

322 :nobodyさん:2007/07/22(日) 17:40:35 ID:???
cakeはクラス。CIは関数

323 :nobodyさん:2007/07/22(日) 17:45:28 ID:???
関数使うFWでも
読むファイル指定してるだけだからstaticなクラス書いてもいいけどね

324 :nobodyさん:2007/07/22(日) 17:47:58 ID:???
staticなクラスにしちゃうと今度は使う時名前が長くなるんだよ
phpのどうしようもないところw

325 :nobodyさん:2007/07/22(日) 17:50:08 ID:???
でも俺はstaticなクラス作って書いてる。
後から一括置換なんかも便利だし。

326 :nobodyさん:2007/07/22(日) 17:59:50 ID:???
俺は関数でもいいと思う派だけど、
関数の場合、初めから用意されてるヘルパーがFW側に置いてあるのはどうかと思う。
コマンドでアプリケーションのディレクトリ構造を展開したときに、アプリ側に展開して欲しい。

クラスにした方がいいと思ったらクラスを作る。libなイメージ。

327 :nobodyさん:2007/07/22(日) 18:03:24 ID:???
staticクラスで、ヘルパー関数を一旦ラップするのをお勧めする

328 :nobodyさん:2007/07/22(日) 18:10:22 ID:???
viewにview helperがmixinされるような形のが一番いいよ
$thisを書くのは必要経費で

329 :nobodyさん:2007/07/22(日) 18:19:34 ID:???
うーんmixinかー
メソッド名が元のviewと被ったら?

330 :nobodyさん:2007/07/22(日) 18:33:50 ID:???
unit test時にわかるでしょ

331 :nobodyさん:2007/07/22(日) 18:56:57 ID:???
>>327
意図は?

staticクラスというのはstaticメソッド群からなるクラスのことだと思うが、
staticメソッドでラップしても関数を関数でラップするのと変わらない。

クラスの(static)プロパティも使用しいくつかのヘルパー関数群を
関連するものとして扱うなら、それはstaticよりもインスタンスにして
投げるインスタンスで振る舞いを変えられるようにしたほうが意味があると思うのだが。

332 :nobodyさん:2007/07/22(日) 19:04:54 ID:???
そこまでやるなら、既存のヘルパ関数なんかそもそも使わん。ヘルパー用クラスを
書くよ。保守を考えてstaticにするのは同一関数(メソッド)名で、とりあえずヘルパ使ってるってことを
明示しつつ拡張するため。関数を同一関数名でラップすることは出来ないからね。

333 :nobodyさん:2007/07/22(日) 19:18:21 ID:3PPkob3E
単にネームスペースの代わりだね。俺もやるよ。

334 :nobodyさん:2007/07/22(日) 19:28:48 ID:???
まあFW側で直接定義されてるfunctionじゃな
オーバーライドすらできんしな、FWのソースを書き換えとか御免だ
ラッパーがstatic/dynamicどっちがいいとかは抜きにして
ラップして使う事自体に意味はちゃんとある

335 :nobodyさん:2007/07/22(日) 19:34:02 ID:???
関数だとどこで定義されているか、わかりにくいしねえ。

336 :nobodyさん:2007/07/22(日) 19:37:03 ID:???
うん、grepすりゃいいからそれは別に困らないがw

337 :nobodyさん:2007/07/22(日) 19:50:04 ID:???
関数ヘルパでも接頭辞付けたらラップできるな

338 :nobodyさん:2007/07/22(日) 20:44:06 ID:???
〜〜すれば〜〜が無くてもおk
って発想を減らしていかないと「誰でも使えるフレームワーク」にならないんだろうね
わかってる人だけでいじるならこの思想の方が楽でいいんだがw

>>319
CodeIgniterも関数じゃなかったかな?

339 :nobodyさん:2007/07/22(日) 20:56:10 ID:???
「誰でも使えるフレームワーク」とか要らん

340 :nobodyさん:2007/07/22(日) 22:16:39 ID:???
誰でも使えないフレームワーク誕生の瞬間である

341 :nobodyさん:2007/07/23(月) 00:56:07 ID:???
>>317
変数はグローバルスコープに登録されてるわけじゃないよ
メソッド中のローカルスコープにテンプレートを読み込んでるだけ。
テンプレートを基準にして見るとグローバルスコープかと思えるけど。

342 :nobodyさん:2007/07/23(月) 07:09:56 ID:???
>>338
FWが機能を実装してなくてもいいんじゃないのかね。
外部ライブラリの導入やユーザ拡張がしやすい設計(MVCが可能な限り疎結合的)
であることが、いいFWの第一条件だと思うよ。
その上で個別に、XXのルータクラスは使いやすいとか、モデルが書きやすいとか、
そういう評価が出てくると思う。

343 :nobodyさん:2007/07/23(月) 12:45:58 ID:???
>>342
FWとは何か?を理解してないやつが語ってるんだからしょうがあるまい。

こう書くと誤解を招く恐れもあるんだが、「仕様こそがFWである」とでも書いておくかな。
じゃないと、いつまで経ってもFWとライブラリの違いも判らん奴が妙な書込みを続けるし。

344 :nobodyさん:2007/07/23(月) 20:12:12 ID:???
>仕様こそがFW
ワケワカラン

345 :nobodyさん:2007/07/23(月) 21:56:37 ID:???
こう書くと誤解を招く恐れもあるんだが、
「『仕様こそがFWである』こそ妙な書込み」とでも書いておくかな。
じゃないと、いつまで経っても妙な書込みとそうでない書込みの
違いも判らん奴が妙な書込みを続けるし。

346 :nobodyさん:2007/07/23(月) 22:58:29 ID:???
フレームワークこそがFWである。

347 :nobodyさん:2007/07/24(火) 01:46:05 ID:???
最近出てきてるとかを見ると、バッドノウハウの温床だな。


348 :nobodyさん:2007/07/24(火) 02:52:11 ID:Wl3XMVYJ
Fireworks

349 :nobodyさん:2007/07/24(火) 09:36:30 ID:???
Firewall

350 :nobodyさん:2007/07/24(火) 11:38:30 ID:???
Frank Williams

351 :nobodyさん:2007/07/24(火) 11:45:34 ID:???
>>347
たとえば?典型例は?

352 :nobodyさん:2007/07/24(火) 12:58:42 ID:???
for ( $i=0,$count=count($contents); $i<$count; $i++ ){

}
ループ中のカウントを減らすためにこういう書き方すんのって
バッドノウハウですか?普通にあり?

353 :nobodyさん:2007/07/24(火) 13:07:30 ID:???
>>352
アリじゃね?

354 :nobodyさん:2007/07/24(火) 13:35:50 ID:???
「for文の条件内でcount()を使うな」はバッドノウハウではないと思うけど
その書き方はどうかと……

$count=count($contents);
for ( $i=0; $i<$count; $i++ ){

}

の方が見る人が理解しやすいと思うなぁ

355 :nobodyさん:2007/07/24(火) 14:12:03 ID:???
激しくどっちでも良過ぎて溜息が漏れる

356 :nobodyさん:2007/07/24(火) 14:12:23 ID:???
なにが「どうかと……」だよ。いたって普通だろうが。

357 :nobodyさん:2007/07/24(火) 14:33:10 ID:???
ワンライナーで書けるものは書けばいいじゃんっていう空気が
phpはあんまりないよな言語仕様による要因が大きいけれども
rubyとかは仕様も使う側もそういう空気に満ち溢れてるから
コードは短いけど行単位の情報量が必然的に多くなる

358 :nobodyさん:2007/07/24(火) 14:44:56 ID:???
forの式1はカンマ区切りで複数とれるのね。しらんかったよ。

359 :nobodyさん:2007/07/24(火) 14:49:19 ID:???
>>352
forループで関数呼び出しを避けたほうがいい
http://lint.s1.x-beat.com/up/img/up12059.jpg


360 :nobodyさん:2007/07/24(火) 15:02:17 ID:???
>>359
せっかくだから環境も分かるようにしてくれよ。
いつのベンチかわからん。


361 :nobodyさん:2007/07/24(火) 15:04:45 ID:???
>>359
>>352 の関数呼び出しは、評価部分ではなくて、初期代入部分だから、
そのベンチはあてはまらんだろ?

362 :nobodyさん:2007/07/24(火) 15:19:32 ID:???
>>359
よく読め

それを避けたいから
for ( $i=0; $i<count($contents); $i++ ){
でなく
for ( $i=0,$count=count($contents); $i<$count; $i++ ){
なんだろ

363 :359:2007/07/24(火) 15:22:22 ID:???
>>361
>>352の書き方でいいよといいたかった

364 :nobodyさん:2007/07/24(火) 19:12:05 ID:???
たしかに、自分がPHPで書くときは出来るだけワンライナーは避けてるなぁ。
他者が関わる場合は、極端に言えば本当の初心者が見ても解るように書いてる。
コードの「格好良さ」より、「解りやすさ」重視って感じかな。

365 :nobodyさん:2007/07/24(火) 19:56:24 ID:???
俺もそう。
なんかワンライナーの方がかっこよくみられるけどね。
わかりやすい方がいい。

Rubyみたいに . で右につないでいけると、
ワンライナーも使いやすくなるんだけど。

366 :nobodyさん ◆wSaCDPDEl2 :2007/07/24(火) 20:10:07 ID:???
ワンライナーでなんか書いて

367 :nobodyさん:2007/07/24(火) 21:03:40 ID:???
おとこわりだ!

368 :nobodyさん:2007/07/24(火) 21:07:06 ID:???
どう考えても>>354のほうが視認性があるだろ。


369 :nobodyさん:2007/07/24(火) 21:31:29 ID:???
for文のループに関する議論は、確かsymfonyで話題になったことが
あったみたいだけど、コレすなわち「FWを利用することによるバッドノウハウ」
とはならんよね。

370 :nobodyさん:2007/07/24(火) 22:02:50 ID:???
一方ロシアは
foreach ($contents as $i => $content) { }
を使った

371 :nobodyさん:2007/07/24(火) 22:32:45 ID:???
>>370
なるほど
それいいな
パフォーマンスも問題ない?

372 :nobodyさん:2007/07/24(火) 22:38:28 ID:???
それは、パフォ的にありまくり。使っちゃいけないだろうな。


373 :nobodyさん:2007/07/24(火) 22:44:17 ID:???
えええええ
ロシア駄目じゃん

374 :nobodyさん:2007/07/24(火) 22:46:08 ID:???
手元のテストループで言えば、ロシアは1.5倍増の時間がかかってる。
ロシアの負け。

375 :nobodyさん:2007/07/24(火) 22:51:50 ID:???
つーかPHPならforeachふつうに使うだろ。。
おまえら本当にPHP使ってるのか。

376 :nobodyさん:2007/07/24(火) 22:55:11 ID:???
連想配列なら使うけど普通の配列なら使わない

377 :nobodyさん:2007/07/24(火) 22:55:26 ID:???
for使う事自体が少ないしな

378 :nobodyさん:2007/07/24(火) 22:59:14 ID:???
連想配列の話してるわけじゃないんだけどね。

379 :nobodyさん:2007/07/24(火) 23:06:02 ID:???
・中身だけ使う
foreach ($array as $value) { }
・キーだけ使う
foreach (array_keys($array) as $key) { }
・両方使う
foreach ($array as $key => $value) { }

for使うってのは滅多にないな
しかしFWのスレなのに重隅論議だな

380 :nobodyさん:2007/07/24(火) 23:12:00 ID:???
前にも出た結論な気がするけど
FW使うってだけでそんな重隅最適化なんてぜんぶチャラだよなw

381 :nobodyさん:2007/07/24(火) 23:19:46 ID:???
最適化っていう視点じゃなくて綺麗で視認性がある書き方したい
ってことで見れば別に重箱でもない。

382 :nobodyさん:2007/07/25(水) 00:38:21 ID:???
>綺麗で視認性がある書き方したい
そんなもんPHP使ってる時点で(

383 :nobodyさん:2007/07/25(水) 00:46:56 ID:???
お前みたいな思考停止はイラネ

384 :nobodyさん:2007/07/25(水) 01:11:06 ID:???
ブロックスコープのある言語の使用者にとっては、ブロック内での使い捨ての変数は初期化式で宣言するのが当たり前なんだけどな。
この辺にペチパーの底力を感じる。

385 :nobodyさん:2007/07/25(水) 01:34:40 ID:???
つーか>>370では>>352と挙動が別物なんだがな

386 :nobodyさん:2007/07/25(水) 02:26:41 ID:???
人を見下さずに普通に発言できんものですかねおまいら

387 :nobodyさん:2007/07/25(水) 18:00:18 ID:???
仕様です

388 :nobodyさん:2007/07/26(木) 01:09:42 ID:???
>>351
ページごとにいちいちサブコントローラ(Action)を書かないと動かないような、
無駄にStrutsの汚点を継承しているEthnaとか。

処理系の実装してる組織のくせに言語仕様じゃなくて
コーディングルールでゴリゴリ縛ってるZendとか

しょうもない所でPEAR::DBに依存してるくせにDB::getAll()がラップされてなくて、
結局メンバのPEAR::DBインスタンスに直接アクセスするしか解決方法が無かったりとか

どうせ作業の流れなんて機能単位でしかやらないのに
ファイル構成でモデルとビューのディレクトリががロンドン・パリなみに離れてるわ
さらにそれぞれアクション命名規則に縛られてかなりディープなディレクトリ構成になるわで
Eclipseの画面からはみでてしまって小さい修正のたびに
スクロールバーいじらんなんハメになってたりとか

PHPなんて標準でフォームバリデータとモデル仕様がないから面倒なだけなのに
FWなんて大げさなもんにして一生使いもしないクラスを多重に内包して無駄なメモリ・CPU時間食ってる
PHP用FWの存在意義とか。



389 :nobodyさん:2007/07/26(木) 01:14:46 ID:???
今度は>>388が素晴らしいFWを教えてくれるそうです。

390 :nobodyさん:2007/07/26(木) 01:23:09 ID:???
ページごとにサブコントローラを書かずに動くとしたらどんなの?

391 :nobodyさん:2007/07/26(木) 02:59:01 ID:???
簡単さでいうと、
ちいたん>CodeIgniter>CakePHP>Symfony
ですか?

392 :nobodyさん:2007/07/26(木) 09:27:58 ID:???
>>388
最近の、って言っときながらほとんどEthnaの話だけかよw
Ethnaみたいな旧態依然なFW使ってりゃそりゃBKだらけになるわなw

393 :nobodyさん:2007/07/26(木) 11:28:09 ID:???
BKって何?

394 :nobodyさん:2007/07/26(木) 11:33:52 ID:???
>>モデルとビューのディレクトリががロンドン・パリなみに離れてる
こんなん自分で変えたらいいだけじゃね

395 :nobodyさん:2007/07/26(木) 11:47:08 ID:???
ディレクトリ構成自体がFWの設計であるということも
わからない奴はFWを触るなよ


396 :nobodyさん:2007/07/26(木) 11:50:57 ID:???
こう書くと誤解を招く恐れもあるんだが、「ディレクトリ構成こそがFWである」とでも書いておくかな。

397 :nobodyさん:2007/07/26(木) 11:53:52 ID:???
>>393
http://ja.wikipedia.org/wiki/BK
好みのものを選んでくれ

398 :nobodyさん:2007/07/26(木) 14:20:46 ID:???
>>388
> 処理系の実装してる組織のくせに言語仕様じゃなくて
> コーディングルールでゴリゴリ縛ってるZendとか
これはまさにその通りだな。
つーか、PHPの開発チームってどういう構成になってるんだ?

399 :nobodyさん:2007/07/26(木) 14:36:21 ID:???
>>397
俺はBerryz工房だな

400 :nobodyさん:2007/07/26(木) 14:37:54 ID:???
FW(的なもの)ありきなものがいいんなら
勝手にcoldfusionなりwebobjectsなりやってくれ

401 :nobodyさん:2007/07/26(木) 16:45:14 ID:???
>>398
コーディングルールでゴリゴリ縛ってるって具体的にどういう所?
クラスの命名規則ってこと?

402 :nobodyさん:2007/07/26(木) 22:00:26 ID:???
>>399
俺は美少女教育が気になる

403 :nobodyさん:2007/07/26(木) 22:03:45 ID:???
>>401
これらね↓
ttp://framework.zend.com/manual/ja/coding-standard.html

?>書かないのも気持ち悪い〜とか思ってたけど、
自然と書かなくなったな。なんかめんどうだから。

404 :nobodyさん:2007/07/26(木) 22:31:48 ID:???
へー。
?>省略は糞だろうなあ。
単にヘッダの空文字列送出防ぐためにやってるんでしょ?
本末転倒だ

405 :nobodyさん:2007/07/26(木) 22:59:42 ID:???
さっさと <?php を省略できるようにしろよ、糞Zend

406 :nobodyさん:2007/07/27(金) 00:16:54 ID:???
sigilは好みもあるからどっちでもいいけど、つけるんだったらコレくらいはパースしてほしい。

<?php
$a = array('a'=>1);
print "$a['a']\n";
?>
↑エラー

#!/usr/bin/perl
%a = ('a'=>1);
print "$a{'a'}\n";
↑「1」。当然の勝利。

407 :nobodyさん:2007/07/27(金) 00:32:26 ID:???
片方を文法に従わず書いて他方を文法に従って書いて何が勝利なのか全然わからんがw
既存の文法が気に食わないならソースにパッチ当ててオリジナルのPHP作って使ったら?

408 :nobodyさん:2007/07/27(金) 00:57:19 ID:???
要するにPHPのパーサーがヘボってこと。

409 :nobodyさん:2007/07/27(金) 01:36:06 ID:???
要してねーだろ
ヘボいのはPHPの文字列解釈仕様であってパーサはその仕様の通りに正常に動いてるんだろーが
自分が何を気に入らないのかすら理解できてないアフォですか?

410 :nobodyさん:2007/07/27(金) 01:47:46 ID:???
仕様って…w。
まあ、PHPはprint $a['a']."\n";とやるしかないわな。
$a = 0 || 100;とか3項演算子の左結合とか、たいそうな仕様だわ。
こういうのが積み重なって、PHPのヘボソースが出来上がる。

411 :nobodyさん:2007/07/27(金) 02:17:30 ID:???
print "{$a['a']}\n";
何もそんなに自信満々で無知をひけらかすことはないと思うんだ。

412 :nobodyさん:2007/07/27(金) 02:19:41 ID:???
print "$a[a]\n"; もしくは print "{$a[a]}\n";

PHPの糞仕様を擁護する気はさらさらねーが
悪口言いたい一心で研究不足を自慢されてもバカじゃね?としか思えん

413 :nobodyさん:2007/07/27(金) 02:49:11 ID:???
>>411
その{}を面倒と思わないなら、それでいいよ。俺はノーサンキュー。

414 :nobodyさん:2007/07/27(金) 02:51:10 ID:???
>>412残念
配列ですべきこととしてはならないこと
なぜ、$foo[bar] は使用できないのか?
http://www.php.net/manual/ja/language.types.array.php

415 :nobodyさん:2007/07/27(金) 09:26:41 ID:???
>>412は釣りだろ?でなきゃ考え付かない


416 :nobodyさん:2007/07/27(金) 15:20:29 ID:???
codeigniterのリンクヘルパの仕様おかしくね?
引数の順序はfunc(label,uri…)だろ、感覚的に考えて。
anchor(uri,label)ってなめてんのかこの野郎

417 :nobodyさん:2007/07/27(金) 15:44:12 ID:???
<a href="url">label</a> の順序に従ってるんじゃないか?
感覚の問題だから一概には言えないが俺もlabelが前の方が自然だと思う

418 :nobodyさん:2007/07/27(金) 15:57:50 ID:???
<a href="url">label</a>において
href…属性
label…内容
重要度から言えば内容>属性だから、
第一引数は内容=labelがふさわしい

419 :nobodyさん:2007/07/27(金) 15:59:34 ID:???
>>416 のanchor(uri,label) しか見てないけど、
labelは省略可能な気がするから(urlで代替できる)、
それでいいんじゃない。
省略可能かどうかは知らんが。

420 :nobodyさん:2007/07/27(金) 16:00:16 ID:???
フレームワークでは標準的な、
「mod_rewriteを使ってindex.phpを隠す方式」の正式な名称って何ですか?

421 :nobodyさん:2007/07/27(金) 16:01:22 ID:???
>>419
symfony様に喧嘩売ってんのか

422 :419:2007/07/27(金) 16:05:30 ID:???
マニュアル見たらurlで代替すると書いてるじゃん。
http://userguide.cilab.info/helpers/url_helper.html
だからこれでいい。

423 :nobodyさん:2007/07/27(金) 16:15:18 ID:???
>>420
正確に指し示すこれっていう名前はないなそう言われてみれば
WEBFWのほぼ標準的な仕様なのにな

424 :nobodyさん:2007/07/27(金) 16:33:38 ID:???
PATH_INFO方式とはまた別なの?

425 :nobodyさん:2007/07/27(金) 16:51:30 ID:???
>>424
PATH_INFOの場合は、..../index.php/foo/barが機能するから直接の関係性はない。

426 :nobodyさん:2007/07/27(金) 16:58:19 ID:???
隠れディスパッチャ方式でok

427 :nobodyさん:2007/07/27(金) 18:39:49 ID:???
indexの話でもなくて
リライトルータ、URLマッパーの話でもない?


428 :nobodyさん:2007/07/27(金) 20:18:55 ID:???
mod_rewriteを使ったフロントコントローラ、かなあ


429 :nobodyさん:2007/07/27(金) 20:38:49 ID:???
>>428
機能そのまま説明してるだけじゃんw

430 :nobodyさん:2007/07/27(金) 20:42:59 ID:???
>>422
ラベルをURL自体にするケースがどれだけあるのかと。
そんなレアケースのために引数の順序が決定されるのは納得いかない
あー納得いかないね

431 :nobodyさん:2007/07/27(金) 20:54:43 ID:???
>>427
ゼンブ違う

432 :nobodyさん:2007/07/27(金) 21:14:22 ID:???
いってる意味ワカランなあ。
URLが先、ラベルが後のほうが直感的にOKだろ

433 :nobodyさん:2007/07/27(金) 21:34:14 ID:???
まあ、感覚だから個人差はあるな
symfonyはlabel,url
ciはurl,label
他は?

434 :nobodyさん:2007/07/27(金) 21:38:41 ID:???
そもそも中に入るテキストを
「ラベル」って呼ぶ事に何の疑問を感じてないおまえらにイライラする

435 :nobodyさん:2007/07/27(金) 21:42:39 ID:???
呼んでいる奴に付き合ってあげてるだけだからそこでイライラするな
そんなこといえば「中に入るテキスト」なんてW3C定義と全然違うだろ。


436 :nobodyさん:2007/07/27(金) 21:42:42 ID:???
話題を振った416の用語に合わせてるだけだと思うが
そういう434は何と呼ぶのが良いと思う?

個人的には「アンカ」「アンカ文」あたりかと思うが
「ラベル」の方がより多くの人に意味が伝わりそうな気がするな

437 :nobodyさん:2007/07/27(金) 21:45:46 ID:???
どうでもいい定義に拘ってる434の方にイライラする
普通に伝わればいいだろ
テーマの中核じゃないんだから

438 :nobodyさん:2007/07/27(金) 21:55:14 ID:???
434の人気に、嫉妬はしない

439 :434:2007/07/27(金) 22:04:29 ID:???
リアル涙目なんで
引き続き 【PHP】フレームワークについて語るスレ7【総合】 でお楽しみください

「中に入るテキスト」はねーよ俺、反論できない

440 :nobodyさん:2007/07/27(金) 22:21:40 ID:???
泣いてるの?

441 :nobodyさん:2007/07/27(金) 23:06:40 ID:???
>>433
cakeのバヤイ
link (label,url)

442 :nobodyさん:2007/07/27(金) 23:21:22 ID:???
ZFの場合

リンクのヘルパ自体無い

443 :nobodyさん:2007/07/27(金) 23:27:43 ID:???
二大人気FWのsymfonyとcakeが
label,urlを採用しているということは
ciは異端
ZFはなめすぎワロタ

444 :nobodyさん:2007/07/27(金) 23:29:50 ID:???
>>416
ヒント:イニシャルは姓と名が逆

445 :nobodyさん:2007/07/28(土) 02:19:59 ID:???
CIって規模小さいけど作ってるヤツ頭いいな〜。
label,urlは前々から疑問感じてた。

446 :nobodyさん:2007/07/28(土) 02:55:44 ID:???
擁護みたいな形になるが、俺も「ラベル」の意味がわからず読んでたが、
434を読んでやっと<a href=url>この部分</a>のことだとわかった
もちろんlink(label, url)ってペアで書いてあればすぐわかることだけど

447 :nobodyさん:2007/07/28(土) 03:32:53 ID:???
ciのヘルパが気持ち悪いから
my_anchor作りました(`Д´)

448 :nobodyさん:2007/07/28(土) 03:36:13 ID:???
ラベルって呼ぶのは
GUIのプログラミングの文化

449 :nobodyさん:2007/07/28(土) 09:13:03 ID:???
>>446
>>417も読まないわけですか?

450 :nobodyさん:2007/07/28(土) 10:14:49 ID:???
>>430
そんなにレアケースとも思わないけど。
入力されたURLを<a>タグに置き換える時とかに使わない?

ま、どっちが先だろうがどーでも良いけど、
>>447みたいな事するくらいなら他のFW使えば良いのに。


451 :nobodyさん:2007/07/28(土) 10:19:23 ID:???
>>449
そりゃ気付かなかった

452 :nobodyさん:2007/07/28(土) 10:51:50 ID:???
>>450
いやいやいや
他のFW使うくらいならヘルパ作る方が断然楽だろ
リンクヘルパの引数の順番の好みのために、学習曲線を登る苦労とか実装されてるユーティリティ機能とかを完全に無視できる奴はそうそういないだろw

453 :nobodyさん:2007/07/28(土) 14:27:44 ID:???
そのうち誰かがどっちでもいい関数作って、それが後々
セキュリティホールになったりするのがぺちぱークオリティ、
とか言ってみる。まぁ、冗談だけど。

454 :nobodyさん:2007/07/28(土) 15:02:30 ID:???
いや、あるあるw

455 :nobodyさん:2007/07/31(火) 03:39:25 ID:???
俺俺フレームワーク作ってるが
複数DBの抽象化面倒くせえええ
取得できるカラム情報のデータ形式がDBによってかなり違うし

456 :nobodyさん:2007/07/31(火) 09:11:20 ID:???
>>455
DBのアダプタみたいな面白くない割に大変で
クリティカルな部分はライブラリ使った方が楽だぜ
俺もO/Rマッパは自分で書いてるけど
DBの抽象化はZend_Db_Adapterでやってる

457 :nobodyさん:2007/07/31(火) 14:24:55 ID:???
>>456
ZFはいまいちな印象があったんだが
そんなのがあったのかー
見てみるわ。ありがとう。

458 :nobodyさん:2007/08/03(金) 00:36:40 ID:???
>>455
http://journal.mycom.co.jp/articles/2007/07/28/rubyphp/index.html
PHP版Ruby on Rails? - DB操作クラスを自動生成する"PHP Object Generator

こんなので手間を省けませんか?

459 :nobodyさん:2007/08/03(金) 00:54:56 ID:???
>>458
結構良さそうだね
既に100万オブジェクト以上発行してるのか
てか字ちっさ!

460 :nobodyさん:2007/08/03(金) 00:56:38 ID:???
PHP版Ruby on Railsっていう呼び方は全然違くない?
ジャンルが違う感じだ

461 :nobodyさん:2007/08/03(金) 00:58:26 ID:???
なんかもうちょっとでもrailsと被ってたら
タイトルにrailsって書いとけみたいなノリで書いてるな

462 :nobodyさん:2007/08/03(金) 01:01:07 ID:???
たしかにw

463 :nobodyさん:2007/08/03(金) 01:26:34 ID:???
そのうち「生鮮食品版 rails!?」とかもう何でもrails付けときゃ売れるだろ的な

しかしまぁDBの抽象化だのDAOだのってのは
それこそもういっそ言語仕様に取り込んじゃってくれよって話だなぁ……

464 :nobodyさん:2007/08/03(金) 02:50:28 ID:???
http://www.tsujita.jp/blojsom/blog/default/PHP/2007/07/13/PHPベンチマーク

code igniter以外遅すぎwww

      オ、オ、オワターオワオワオワター♪
      \ CodeIgniter以外オワターオワオオワオワタ/
         ♪\(^o^) ♪
          _  )  > _ キュッキュ♪
        /.◎。/◎。/|
  \(^o^)/.| ̄ ̄ ̄ ̄ ̄|  |  \(^o^)/
    )  )  .|        |/   ノ ノ
((((  > ̄ > )))) \(^o^)/ ((( < ̄< ))))
              )  )
         (((  > ̄ > ))))

465 :nobodyさん:2007/08/03(金) 06:23:12 ID:???
>>458
The BSD Licenseって…
普通ライセンスに"The"なんて付けないだろ

466 :nobodyさん:2007/08/03(金) 09:53:47 ID:???
>>465
釣りネタを探す目の付け所は悪くないが表現がやや幼稚すぎる
さらなる精進を望む

467 :nobodyさん:2007/08/03(金) 09:58:12 ID:???
表現の問題でなくて、Theをつけないと思ってる頭が幼稚

468 :nobodyさん:2007/08/03(金) 10:07:16 ID:???
日本語を話してるのにtheとかつけたら
The PHP frameworkみたいな滑稽さになるね

469 :nobodyさん:2007/08/03(金) 11:10:03 ID:???
へーPHP frameworkって固有名詞なんだ

470 :nobodyさん:2007/08/03(金) 11:17:57 ID:???
新しいバンドの名前

471 :nobodyさん:2007/08/03(金) 11:20:35 ID:???
なぜPHP frameworkが固有名詞?

472 :nobodyさん:2007/08/03(金) 12:42:33 ID:???
冠詞(The)を付けるからって勘違いしてんじゃね?

473 :nobodyさん:2007/08/03(金) 15:03:22 ID:???
BSD licenseのTheは固有名詞のTheだろ。

474 :nobodyさん:2007/08/03(金) 15:43:51 ID:???
Theで固有名詞って、いったいいつの時代の教育を受けたんだ?
固有名詞かどうかなんて考えて話すやつなんていないっつーの。
対象物を知ってるやつ相手ならThe、知らないやつならa、ってだけ。

The PHP frameworkのTheは、PHPはみんな知ってるからついてる。
The BSD licenseもBSDをみんなが知ってるからついてる。

475 :nobodyさん:2007/08/03(金) 15:54:37 ID:???
(゚д゚)ポカーン

476 :nobodyさん:2007/08/03(金) 15:56:26 ID:???
ザ・ガマン

477 :nobodyさん:2007/08/03(金) 16:13:23 ID:???
PHP frameworkもBSD licenseも一般名詞であって、固有名詞じゃない。
定冠詞theは、他の一般名詞同様、文脈と英文法に従って付けられる。
しかし日本語で話している時に、そのような文脈的なtheは普通つけない。
「俺、そのフレームワーク知ってる!」という意味で「俺、the framework知ってる!」
なんて言うのは明らかにおかしい。

もちろんThe PHP Frameworkという「名称」のフレームワークを作れば固有名詞にもなるがな。
そうでない限り、日本語の文脈でtheをつけるのはおかしい。

478 :nobodyさん:2007/08/03(金) 17:03:16 ID:???
なにをいっているのかわからない

479 :nobodyさん:2007/08/03(金) 17:17:06 ID:???
the PHP frameworkもthe BSD licenseもおかしいってことだろ

480 :nobodyさん:2007/08/03(金) 17:46:39 ID:???
えーっと
「The BSD Licence」というライセンス名なんだけどー……
「BSD Licence」に the を付けるかどうかなんて話はそもそも無関係なのよ
そもそも英語の名称の話をしてるのに「日本語で話してる時」って前提が既におかしいし

「ビーエスディーライセンス」という日本語名詞の話だと言い張りたいならそれでもいいけど
だとしたら皆と前提が違いすぎて会話になってないのは自分でもわからないかね?

481 :nobodyさん:2007/08/03(金) 17:58:54 ID:???
theの話とかどうでもいいよ
ほんとしねばいいのに

482 :nobodyさん:2007/08/03(金) 19:20:34 ID:???
BSD licenceでググると57,200件見つかるが
"The BSD licence"でググると7件しか見つからない
つまりそういうことだ

483 :nobodyさん:2007/08/03(金) 19:55:20 ID:???
しゃれにならんほどどうでも良い話題に萎え

484 :nobodyさん:2007/08/03(金) 19:57:35 ID:???
THE END

485 :nobodyさん:2007/08/03(金) 20:55:04 ID:???
> The BSD Licence の検索結果 約 1,260,000 件中 1 - 50 件目 (0.14 秒)

……?('A`)

http://www.opensource.org/licenses/bsd-license.php
とか見たことあるか?

486 :nobodyさん:2007/08/03(金) 21:15:20 ID:???
BSDライセンスのことを「The BSD Licence」って書く奴を
きもいと思うか思わないかだけの話だから、正解はないな

487 :nobodyさん:2007/08/03(金) 22:52:50 ID:???
中一レベルの英語で揉めてんじゃねーよww

488 :nobodyさん:2007/08/04(土) 00:07:31 ID:???
でもまあそのendにあたって、 licence には突っ込んでおきたい。




489 :nobodyさん:2007/08/04(土) 00:56:44 ID:???
私は yu を fackします

490 :nobodyさん:2007/08/04(土) 02:58:01 ID:???
ファイルのキャッシュ付いてるFW多いけど
ファイル数あほほど増えるな。
しかもディレクトリ掘りまくりでduでトータルサイズ計算するのにも
やたら時間かかる。
DBに入れた方がいいだろこれ。

491 :nobodyさん:2007/08/04(土) 03:37:25 ID:???
古いキャッシュファイルを定期的に捨てるようにしたよ
これって常識?

492 :nobodyさん:2007/08/04(土) 09:36:44 ID:???
普通はcronで削除する

493 :nobodyさん:2007/08/04(土) 09:45:54 ID:???
お好みで。場合によるし一般論はない。



494 :nobodyさん:2007/08/04(土) 17:23:21 ID:???
結局、FW実装のCacheじゃなくて、PEARのCache/Cache Liteを使っちゃうな。

495 :nobodyさん:2007/08/04(土) 18:37:45 ID:???
使い勝手いいの?
ってか使い勝手悪い糞キャッシュしか実装してないのに
「キャッシュ実装!軽い!」とか宣伝するFW作者反省しろ

496 :nobodyさん:2007/08/04(土) 22:27:45 ID:???
FW実装のCacheが、処理プロセスと不可分になっちゃってるから柔軟性に
欠けるという面と、ファイルキャッシュ以外のサーバーAPI系(たとえばyoutube)の
PEAR実装が結局PEARのcache使ってるからね。どうせ導入しなきゃならないなら
最初から使わないって感じ


497 :nobodyさん:2007/08/06(月) 18:54:30 ID:HUsmqTvF
興味深い話題age

498 :nobodyさん:2007/08/08(水) 09:20:09 ID:???
EthnaといいPieceといいMapleといい
国産フレームワークって何でマニュアルがええ加減なやつばっかなんだ?w

499 :nobodyさん:2007/08/08(水) 10:23:09 ID:???
ドキュメント整備ってめんどくさいから

500 :nobodyさん:2007/08/08(水) 15:50:49 ID:???
どの分野でもテクノロジーを文章して伝達・教育する技術や能力は英語圏は他のついづいを許さんよね。


501 :nobodyさん:2007/08/08(水) 16:27:51 ID:???
釣り針が太すぎます

502 :nobodyさん:2007/08/08(水) 17:29:25 ID:???
>>499
ドキュメントの書き方を教わらないからだよ。
日本の国語教育の問題が大きい

503 :nobodyさん:2007/08/08(水) 19:16:09 ID:???
仕様が固まりきってないからドキュメントにしにくいんじゃね?
ドキュメント化すると実態と乖離していきかねないから、
ちょっと曖昧なままにしておきたいっていうか。
すくなくとも俺はそういうのあるね。

504 :nobodyさん:2007/08/08(水) 21:34:38 ID:???
つまり面倒だと

505 :nobodyさん:2007/08/08(水) 21:38:33 ID:???
日本には「見て技術を盗め」という文化がある・・・のか?

506 :nobodyさん:2007/08/08(水) 21:58:32 ID:???
>>503
アウトラインを作っておくという文章技術上の発想がないからそうなる。


507 :nobodyさん:2007/08/08(水) 22:00:49 ID:???
>>506みたいに何もしないくせにしたり顔で文句言う奴ばかりいるので
真面目にやる気がしなくなるという事情もある

508 :nobodyさん:2007/08/08(水) 22:06:35 ID:???
>>507
まあいいんじゃね。お前のような人のせいにする奴のプログラムは誰も使わないから。

509 :nobodyさん:2007/08/08(水) 22:08:01 ID:???
なんでアウトラインが関係あるのかよく分からないな
ソース改変
だけの労力が、
ソースを改変+ドキュメント改変
になるのがしんどいんだよ
まあ、ドキュメントを書くことでインターフェイスが簡素になるという
いい作用もあるけど…

510 :nobodyさん:2007/08/08(水) 22:08:55 ID:???
testを載せるだけでも違うけどね。

511 :nobodyさん:2007/08/08(水) 22:24:39 ID:???
ちいたん使ってみた。けっこう扱い易くていい感じなんだが、
MojaviやSymfonyに慣れてるとフロントコントローラが欲しくなるな。
アクションの遷移が従来通りだからなあ。よくもわるくも。

アクションといえば、action()がクラスじゃなくて関数での実装なのは、
ソースコピペする時に

クラス名変エルノモマンドクセ

なんだと気付いた。Mojviじゃけっこうそんなクラスないぞって怒られたからな。

512 :nobodyさん:2007/08/09(木) 00:05:10 ID:???
>>511  さあ、つくろ

513 :nobodyさん:2007/08/09(木) 00:12:52 ID:???
PHPの分際でaf->getとかアホじゃね?って思う。
$_REQUEST上書きで十分。
てかPHP自体にバリデータがない時点でそこから発展する事になるFWなんてウンコ化は既定路線なんだがな。

514 :nobodyさん:2007/08/09(木) 00:41:52 ID:???
>>513 ウンコ!

515 :nobodyさん:2007/08/11(土) 01:37:44 ID:???
いよいよ政治的に大成功してきたRuby
貧民言語PHPm9 (^Д^)プギャー

516 :nobodyさん:2007/08/11(土) 06:53:19 ID:???
他言語をわざわざ貶す理由が分からない。
自分が好きな言語使ってればいいだろw

517 :nobodyさん:2007/08/11(土) 19:22:45 ID:???
cakeとかMapleとか、まぁPHP用に現存するフレームワークって
MVCを実現するため「だけ」のライブラリ?

518 :nobodyさん:2007/08/11(土) 20:51:28 ID:???
>MVCを実現するため「だけ」のライブラリ
が何を示しているのか理解しかねるが、
MVCの分離構造を実現するだけという意味であれば、
そのほかにもActiveRecordだのORMだのDIだの実現すんじゃね

MVCの分離構造を実現するだけでよければちいたん超おすすめwww

519 :nobodyさん:2007/08/11(土) 22:48:35 ID:???
漏れんとこ、開発チームごとにレベル差があってさ、
ずっと生PHPだけで力任せに案件こなしてきていて、
生PHPじゃないっていうだけでなかなか受け付けないような
DQNぎみの連中対策がそろそろ必要なんだよね。

でもいきなり本格的なフレームワークだと学習コストが云々、
兵隊にはメンテさせられん云々……
とかなんとか管理職に言われてしまうよな。

それを避ける意味でも、
ちいたんに限らなくってもいいんだけど、
あのくらいの規模でコードの見通しの効くフレームワークで小さい案件やらせて
段階的にMVC開発に慣れさせるといいかもしれんと思ってる。

もちろん悩み易いconfig類のカスタマイズは先に片付けておいて、
あとはアクションとコンポーネントとテンプレート作るだけとなるように
兵隊向け作業手順のマニュアル書くんだけどな。

520 :nobodyさん:2007/08/12(日) 00:15:54 ID:???
>>518

ちいたん初耳だった。調べてみる。

> >MVCを実現するため「だけ」のライブラリ
> が何を示しているのか理解しかねるが、

ごめん、質問の意図と質問文が乖離してた。

まぁFWによるんだろうけど、
PHP用のFWを使う = MVCサイト構築
ってことになるのかな。
つまり。そのFWでサイト構築するには、MVC方式を余儀なくされてしまうとか。
もしそうだったら、なんかそれって「縛り」だよなぁってふと思っただけ。

>>519

DQN環境乙。

何でもかんでもMVCってのもどうかと思うけど、
とりあえずそういうときはMVCとかOOPとか、
開発手法の素晴らしさをアピールするといいかもしれん。
もうしたのかもだけど。

うちは、「一時の痛みを我慢して、その後が楽になるなら」
ってことで学習コストとか割いてくれた。

521 :nobodyさん:2007/08/12(日) 00:33:30 ID:???
>>520
MVCサイトというのもいまいちよくわからん表現だが
そもそもフレームワークっていうのは縛りでしょ
フレームワークの提供する枠組み=制約というのが一定のルールになって
同じフレームワークを使っている人間のコンセンサス取りやすくなったり
問題点の発見が早くなったり
そもそも問題が発生しづらくなるわけで

522 :519:2007/08/12(日) 00:45:01 ID:???
>>520
なるほど。言う通りですよ。一部DQNなのをなんとかしたい。
ときどき手法の説明をしたり改善策として提案してるんだけど、
従来の流れと違うといまいちピンと来ないらしい。
既存案件におわれて勉強する時間もとれてないようだし。

漏れのところでいちばん効果的だったのは、
10ページくらいの小規模な案件をあっというまに片付けて、
目の前で速度差を見せつけた時かな。
慣れれば効果あるっていうのは分かったみたいだった。

規模によってはMVCでさえ大袈裟すぎる場合や、
ビューの要らないバッチ処理やインタフェース物ももちろんあるわけで。
そこは適材適所。

本格的なフレームワークで大き目の案件だと、
開発速度以上に分業しやすさとメンテ性のためにMVC開発をするんだと思ってるんだけど、
開発速度ほど有利さを披露しにくいのが難点だよね。

523 :nobodyさん:2007/08/12(日) 04:41:54 ID:???
>>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

ということらしいよ。

524 :nobodyさん:2007/08/12(日) 04:46:34 ID:???
ピースFWもイベントドリブンらしいね

525 :nobodyさん:2007/08/12(日) 11:25:05 ID:???
そのpradoのページを何枚か眺めただけだけど、MVC的に実装していくんじゃないの結局は。
View部分はこうだ、って言ってるだけで、そのイベントに対応するクラスはコントローラを基底に
持つと思うぜ。


526 :nobodyさん:2007/08/12(日) 12:16:16 ID:???
viewにガシガシロジック書いてく時点でMVC分離じゃねーべ

527 :nobodyさん:2007/08/12(日) 12:19:57 ID:???
普通にやれば、結局そのview用コントローラー実装することになるんだよ。


528 :nobodyさん:2007/08/12(日) 15:38:41 ID:???
なるほど理解しました。おもろそうだなprado。でもコンポーネント溜まるまではちときついか

529 :nobodyさん:2007/08/12(日) 16:38:41 ID:???
ウェブアプリにイベントドリブンもへったくれもねーよ。

530 :nobodyさん:2007/08/12(日) 17:09:33 ID:???
出たな半生野郎

531 :nobodyさん:2007/08/14(火) 11:16:41 ID:???
んじゃこっちに
Akelos
http://www.akelos.org/

532 :nobodyさん:2007/08/15(水) 10:43:19 ID:???
>>531
このようにあえてRoRクローン風って明言した(影響を受けているとかいうんじゃなくて)FWとしては、
他にどんなのがあるの?

533 :nobodyさん:2007/08/15(水) 14:34:24 ID:???
建てたお
【PHP】PHP on Rails
http://pc11.2ch.net/test/read.cgi/php/1187142925/

534 :nobodyさん:2007/08/15(水) 14:41:17 ID:???
533は何勘違いしてるんだ?
削除依頼だしてこいよ。

535 :nobodyさん:2007/08/15(水) 14:57:18 ID:???
PHP on Rails って PHP on Trax の旧名だよな

536 :nobodyさん:2007/08/18(土) 16:49:31 ID:XeatXWbb
はーいはい。みなさん。こんな本出ますよ。
神本ですよっと。
http://www.cbook24.com/bm_detail.asp?sku=9784896273564

537 :nobodyさん:2007/08/18(土) 18:23:53 ID:???
こいつも佐久間と一緒で本出しすぎだな。

538 :nobodyさん:2007/08/18(土) 20:21:23 ID:???
>>536
発売したら立ち読みしてこよっと

539 :nobodyさん:2007/08/18(土) 20:41:35 ID:???
そしたらレポして3行で総括よろしく

540 :nobodyさん:2007/08/18(土) 21:57:37 ID:???
なんかドキュメント印刷しただけっぽい内容だな。

541 :nobodyさん:2007/08/19(日) 23:13:36 ID:???
携帯サイトに相性がいいフレームワークってある?

542 :nobodyさん:2007/08/20(月) 00:12:15 ID:???
>>541
何を求めてフレームワーク使おうとしているかがわからんから答えようがない

543 :nobodyさん:2007/08/20(月) 19:52:44 ID:???
ttp://ke-tai.org/

544 :nobodyさん:2007/08/22(水) 01:33:27 ID:???
フレームワーク本は予想通り、マニュアルコピペ&彼女の他作の流用でした

545 :nobodyさん:2007/08/22(水) 08:04:04 ID:4atvg3yr
>>544
Zend_Smartyの部分なんかがっかりしたよ。
あれじゃ、Smartyの良さ死んどる

546 :nobodyさん:2007/08/22(水) 13:40:39 ID:???
掲示板の投稿で
フォーム記入→確認顔面→投稿

この流れを簡単にしやすいFWないかな?

547 :nobodyさん:2007/08/22(水) 14:22:32 ID:???
PEARのQuickFormだか何だかは?

548 :nobodyさん:2007/08/22(水) 15:33:07 ID:???
一瞬いい本が出ると思ったが
マニュアルをネットからダウンロードすればいいだけの話か

549 :nobodyさん:2007/08/23(木) 15:37:34 ID:gq3i3Qc4
>>546
確認顔面というのは、投稿者の顔が不細工だとフィルタかける
っていうことですか?。FWレベルでは、そういう実装はないと思います。

550 :nobodyさん:2007/08/24(金) 00:12:40 ID:???
>>546
顔面はともかくethnaかな?

551 :nobodyさん:2007/08/24(金) 00:42:54 ID:YoTG53/u
なぜethnaが優位性を持つのか説明してくれ

552 :nobodyさん:2007/08/24(金) 00:47:43 ID:???
ふじもと神の顔面が優位(=イケメン)なのかと思った。

553 :nobodyさん:2007/08/24(金) 03:46:39 ID:???
>>547
QFCは死んでる。
やるだけ時間の無駄。

554 :nobodyさん:2007/08/25(土) 15:41:51 ID:m12CHPqL
QFがダメな子とは良く聞くけど、
ダメさを今一理解していない俺に、QFの機能でダメな点を教えてくれ。

QF無しだと確認画面尽きデータ更新画面作るの超面倒臭くない?
入力値のバリデートもフィルタも。

そういう時は皆QF以外の何使ってるんでしょう。


555 :nobodyさん:2007/08/25(土) 15:55:04 ID:???
> そういう時は皆QF以外の何使ってるんでしょう。
CakePHPなどのフレームワーク。

556 :nobodyさん:2007/08/25(土) 16:40:10 ID:???
QFはフォームの組み立てから入力のバリデートにHTML出力まで全部こなそうとするんで
特に入力値のバリデーションとかで
Mojaviとかのフルスタックのフレームワークに組み込みにくいという事情があった

でも今でもSymfonyとかCakeとかCIとかが持つフォームシステムで
QFほど何から何まできちんとやってくれるものはないと思う
特にバリデーションJavaScript自動生成とfreeze()あたりは
今風のフレームワークでも何らかで実装してほしいものだなー

あとQFCは死んでるしやるだけ時間の無駄だと思うw

557 :nobodyさん:2007/08/25(土) 16:54:28 ID:???
>>554
2年前の記事だけど
http://hatotech.org/kumatch/archives/000475.html

一時期QFが取り上げられて流行ったけど
QFだとフォームのエレメント主導の作りになっちゃうんだな
フォームにvalidationがぶら下がっちゃうっていうか
コントローラにエレメント生成のコードが入っちゃうし
あと複雑なフォームの構成になるとトリッキーなコードになりやすかった

現状のFWなら大体フォームエレメントの生成はViewHelper、
入力値のvalidationはValidatorでやる形が主流だな

歴史的にそういう経緯があって、今こうなっているということは
結局今の形がよりベターな構成だということなんじゃないかな

558 :nobodyさん:2007/08/25(土) 16:55:36 ID:???
>>555
>>556
自社製FWしか使った事が無くて、
それはQFを組み込んだものでして。

CIとかCakeのマニュアルを流し読み程度はしてみたものの、
面倒臭い確認画面尽きの時の画面遷移コントロールなんかがカバーされてるようには見えなくて、不思議に思ってました。

海の向こうでは確認画面あまり出さないからなのかな、とか。
フォーム要素をPHPオブジェクトと対応させるQFの発想は悪くないと思うのになぁ、とか。

まぁ、とりあえず実際にCI、Cake辺り触ってみるのが早そうですね。


559 :nobodyさん:2007/08/25(土) 17:09:11 ID:???
>>557
確かにフォーム要素をQFでごにゃごにゃ書くのは面倒ですね。
書き方覚えるのも。個人的にはjsと同じ書き方でやらせてくれればいいのにと思います。


560 :nobodyさん:2007/08/25(土) 17:36:07 ID:???
JavaScriptによるクライアントサイドバリデーションはUI的には良いかもしれないけど
信頼性は皆無なので、結局サーバサイドでのバリデーションが必要になるよね。
だからバリデーションJavaScript自動生成を好んで実装したがるFW作者は少ないと思う。

フォーム要素とPHPオブジェクトのバインディングとは少し違うけど、
HTML_Template_Flexyでのフォーム要素の扱いは知っておいて損はないかも。

561 :nobodyさん:2007/08/25(土) 18:24:06 ID:???
>>560
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
自分もそう思う。

564 :nobodyさん:2007/08/25(土) 20:34:11 ID:???
QF2なんてのも出てきてる。。。
なんだこりゃ。

565 :nobodyさん:2007/08/25(土) 21:31:26 ID:???
>>562
フォームがDBのテーブルへの操作窓であるような概念のアプリの場合は
クラスがバリデータとかを提供する方がむしろ自然になるような設計もあると思う
QFでそれをやろうとすると、HTMLとか$_POSTとかまでQFが面倒みちゃうんで
その辺が激しく気持ち悪いことになるのが難点だけど……

HTMLについてはベタ書きよりもきちんと生成されたものの方が正確って考え方もできると思うよ
あとデザイナはフォームがどうなろうと周囲の枠だけ書けば良いような場合もあるし。

結局いつもの「適材適所で」みたいな結論になっちゃうのが残念だがなぁ

566 :nobodyさん:2007/08/25(土) 21:37:02 ID:S/G680iY
POST値に対するvalidataだけなら、既存FWのクラスで十分だよ
>>556の言う「QFほど何から何まできちんとやってくれるものはないと思う」って
具体的になにをさしてるのかわからんわ。JSとか言ってるところ見ると
仔細なチェックまでFWに背負わせようとしてるんじゃないの。そんなの
スクラッチでやったほうが確実だっての。

567 :nobodyさん:2007/08/25(土) 21:38:40 ID:???
手書きは不確実です。絶対にミスが出ます。

568 :nobodyさん:2007/08/25(土) 21:40:44 ID:???
>>566
スクラッチでやるよりも、
何もしないほうが確実ですよ?

JavaScriptはほぼ自動生成です。

仔細なチェックは当然、phpコードで書きます。
それだけで自動でJavaScriptコードが生成されるのです。

569 :nobodyさん:2007/08/25(土) 21:43:58 ID:???
連続で真っ赤になって書かなくてもいいのにw

570 :nobodyさん:2007/08/25(土) 21:45:52 ID:???
反論できないなら書かなくていいのにwwww

571 :nobodyさん:2007/08/25(土) 21:47:01 ID:???
>>569
二人に即効で反論されたからって泣くなよ。
2ちゃんねる初心者か?w

572 :nobodyさん:2007/08/25(土) 21:48:56 ID:???
w多い人ですね

573 :nobodyさん:2007/08/25(土) 21:50:24 ID:???
二人の証明すべきだな。>>571

574 :nobodyさん:2007/08/25(土) 21:56:04 ID:???
俺じゃないやつが書き込んだから二人というだけのことですが?

>>569は荒らすのが目的なのか?
違うのなら黙ってろ。

575 :565:2007/08/25(土) 22:10:37 ID:???
なんかいきなり荒れたなぁ……
べつに相手を言い負かそうとかどっちが勝ちとか考えずに
フレームワークとかフォーム処理とかの良い実装について語り合えるって程度でいいんだけどー

>>566
FWのクラスでも充分だしQFでも充分なバリデートが出来るって話でしょ。
FWの意義のひとつにはなるけどQFが不要になる理由にはならないよね。
あとQFでJSを自動生成できるのはサーバ側でできるチェックより劣るので
完全にUI利便性(POSTする前にすぐにエラーを見つけられるとかその程度)だけの問題。

576 :nobodyさん:2007/08/26(日) 00:35:40 ID:???
使いたいなら使えばいいと思うけど結局メンテしにくいのよQFで書いてると
フォームちょこっと変えたいだけなのに
ViewじゃなくてControllerにあるエレメント設定をいじらないといけないとか
ちょっと入力必須にしたいだけなのにエレメント設定しないといけないとか

でQFでやってるとフォームに関する全ての処理を
QFでやらないといけない感が漂ってきて
FWでMVCに沿ってるはずがだんだんQF主導のコードになっちゃうわけ

RequestもValidationもViewHelperも兼ねてるからそうならざるを得ない
多機能なライブラリが故にそれが仇となってFWに組み込みづらくなる
だからといってそれらの処理をFWによる機能とQFの機能で
中途半端に混ぜて使ってしまうともう最悪のパターンになる
だから、使わない

577 :nobodyさん:2007/08/26(日) 01:05:13 ID:???
QFを使うと氏ぬ

578 :nobodyさん:2007/08/26(日) 01:52:27 ID:???
いっそQFに合わせたFWというのはどうだろう。

webベースのエディタ画面でフォームを作成すると、
それに合わせたコードが吐き出されて、
ついでにDBのテーブルも作ってくれる。

これで名実共にWeb版VBの名を欲しいままに・・。


579 :nobodyさん:2007/08/26(日) 02:03:09 ID:???
フォームからDBスキーマを予想するのは無理ぽ

580 :nobodyさん:2007/08/26(日) 04:06:26 ID:???
>>579
マスタ系テーブルだけ先に手動で作らせておいて、
セレクトボックス、チェックボックス、ラジオボタンはそれを使わせる。

連関エンティティが必要になるようなフォームは自動生成からは切り捨てる。

idはサロゲートキー。

text=varchar
textarea=text


581 :nobodyさん:2007/08/26(日) 04:53:39 ID:???
すみません、恥を忍んで言いますと、私JSが全く書けないんです。

なので、JS付きのValidateしてくれるQFを見た瞬間!!!これだ!!と。

それだけなんです。JS覚えればQFなんていらないです。
でも覚えられないんです。すみませんでした。

582 :nobodyさん:2007/08/26(日) 05:09:13 ID:???
入力チェックのjsなんて難しくねーだろ
HTMLにjsが入るのも気に食わん

583 :nobodyさん:2007/08/26(日) 05:59:51 ID:???
JSでチェックするメリットはあんまりないよな
ajaxでやるならともかく
QFみたいなダサダサチェックは素人くさいよ
まだあるっちゃあるけど

584 :nobodyさん:2007/08/26(日) 07:58:43 ID:???
>>580
それはフォームからスキーマじゃなくて、スキーマからフォームでしょう?
579と逆なんだけど。

585 :nobodyさん:2007/08/26(日) 08:56:04 ID:???
まさかとは思うが、JSのみでValidateしてる人っていないよね。

586 :nobodyさん:2007/08/26(日) 09:52:19 ID:???
あくまでUIの快適さをあげるために存在する
追加の機能であるJavaScriptでの検証。
それもサーバー側でのチェックと同じ機能を
二回も書くなんて面倒。
DRYの原則に反する。
自動で生成されたら楽。

587 :nobodyさん:2007/08/26(日) 10:08:32 ID:???
自動生成だから使うってのはどうかと思うが。サーバチェックだけでいいし
でなきゃ、「UI」改善のための実装ならajax使うでしょ。
今時html埋め込みの単なるjs使う意味は?

588 :nobodyさん:2007/08/26(日) 10:15:11 ID:???
できる限り無駄な通信を避けたい時。
そんなことも想定できないほど脳が腐ってますか?

589 :nobodyさん:2007/08/26(日) 10:19:05 ID:???
JSチェックで削減できる通信量がどれだけあるのかって話だよな
貧者の発想という気がする

590 :nobodyさん:2007/08/26(日) 11:03:26 ID:???
結局サーバー側でもチェックするんだから
通信量なんか関係ないんじゃね?

591 :nobodyさん:2007/08/26(日) 11:06:18 ID:???
JSでチェックしてNGならsubmit止める(=通信させない)とかじゃね?

592 :nobodyさん:2007/08/26(日) 11:13:50 ID:???
>>591
当たり前すぎなんだが、そんなこも知らずに話してたんか。
だから通信が発生するAjaxは論外。
結局、否定しているやつはなんもわかってないじゃねーかw

593 :nobodyさん:2007/08/26(日) 11:19:30 ID:???
>>589
> JSチェックで削減できる通信量がどれだけあるのかって話だよな
> 貧者の発想という気がする

どうやっても、JavaScriptによるレスポンスの速さを
サーバー通信が必要な方法で超えることはできんよ。

問題は通信量ではなく、すばやい反応。
そこを勘違いしていたお前の負けだ。

594 :nobodyさん:2007/08/26(日) 11:42:52 ID:???
なんか「AJAX=新しい=あらゆる最強」みたいな都市伝説を信奉してる人がいる気がする……

郵便番号から住所への変換とかはAJAXで利便性も上がる一例だけど
項目のrequiredチェックなんぞにいちいちAJAX使ったら利便性下がる一方じゃないかな。

httpdの受け口が増えまくるのはサーバ負荷管理的にもおいしくない。
それが問題にならない程度のアクセス数/サーバ数の予算が取れるなら
負荷の点は問題にしなくてもいい場合もあるが。

595 :nobodyさん:2007/08/26(日) 12:30:21 ID:???
JSチェック支持派はJSでだっさいalert出したりしてんの?
動的にDOMいじってサーバと通信した場合と同じ画面にするなら
まあありとも思うが
そこまで手間をかけるならもういいわってなるな。

596 :nobodyさん:2007/08/26(日) 12:35:30 ID:???
>>594
ajaxで転送量減らすこともできるよ
別にリアルタイム性だけがajaxの利点でもない

597 :nobodyさん:2007/08/26(日) 13:20:43 ID:???
>>595
お前言っていることが極端だぞ。

動的にDOMいじってきれいな画面を作る手間をかけるのなら
もういいやと思うんだろ?
そこで普通はもういいやってことでJavaScriptのalertを出すだろ。

1.DOMいじる
2.JavaScriptのalert(コードを別に書く必要は無い)
3.なにもしない

1番がいやだからっていきなり3番の案に飛ぶなよw

それに、俺ならalert(msg)の代わりにdocument.getElementById("msg") = msg;に
置き換えるだけだが? これがそんなに手間がかかることかよw

598 :nobodyさん:2007/08/26(日) 13:23:47 ID:???
>>596
> ajaxで転送量減らすこともできるよ
転送を伴わないAjaxってJavaScriptと同じことだろw

> 別にリアルタイム性だけがajaxの利点でもない
操作性向上に必要なのはリアルタイム性です。

いまはリアルタイム性の高さが(通信をしない)
JavaScriptのエラーチェックの利点だねって話をしているのです。

599 :nobodyさん:2007/08/26(日) 13:58:16 ID:???
        *'``・* 。
        |     `*。
       ,。∩      *    もうどうにでもな〜れ
      + (´・ω・`) *。+゚
      `*。 ヽ、  つ *゚*
       `・+。*・' ゚⊃ +゚
       ☆   ∪~ 。*゚
        `・+。*・ ゚


600 :nobodyさん:2007/08/26(日) 14:12:18 ID:???
頑なにJSでのヴァリデートを否定してるヤツは単に書けないだけじゃねーのか。
別に俺は使わないが「利点がわからない」とか言ってる奴は本当に脳が爛れてるとしか思えんw

601 :nobodyさん:2007/08/26(日) 14:38:46 ID:???
最初の問題設定を改竄しちゃいけねーよ。
FWにQFを乗っけて使う煩瑣さの指摘があって、
それを打ち消すだけのメリットとしてjsエラーチェックの自動生成なるもの
が持ち上げられてるから、突っ込みが入ってるだけだろ。

602 :nobodyさん:2007/08/26(日) 14:57:50 ID:???
普通に>>585のあたりからJSのヴァリデートの利点そのものに疑問を抱いてるヤツいるじゃん。
そういう人に対して言ってるんですがw

603 :nobodyさん:2007/08/26(日) 14:59:19 ID:???
あぁ、ここは卑屈な捕らえ方する人ばっかだからやっぱ気にしなくていいや。
>>600>>602は気にしないで楽しいお話を続けておくれ

604 :nobodyさん:2007/08/26(日) 15:08:20 ID:???
だったらはげしくスレ違い

605 :nobodyさん:2007/08/26(日) 17:29:57 ID:???
>>601
ちょっと誤解があるようだ。

おれが>>556で書いたのは
「打ち消すだけのメリットがjsエラーチェックにある」ではなく
「打ち消すほどのメリットではないが今のFWにも実装してほしい機能としてjsエラーチェックなどがある」なので
jsエラーチェックがなきゃヤダヤダ!と言ってるわけじゃない。

で「jsエラーチェックなんてそもそも不要じゃん」という意見が出てきたのだが
まぁそういう仕事もあるかもしれないけど、あれば便利だとおれは思うし、必要になる案件もある。
AJAX云々は完全に話がすれ違ってると思うが。

606 :nobodyさん:2007/08/26(日) 18:07:32 ID:???
話は変わるが俺のアイデアを聞いてくれ。

QFの利点はPHPでコードを書くだけでJavaScriptの
エラーチェックに変換してくれる。つまりエラーチェックコードを二度書かなくていいことにあるわけだが、
そのためにはaddRuleメソッドでrequiredを設定するというコードを書く必要がある。

そう、PHPのエラーチェックコードではなく、
フォームに、requiredなどの属性を設定するわけだ。

だから複雑なエラーチェックがやりにくい。
そこでだ、PHPコードそのものでエラーチェックできたら良いとは思わないか?
たとえば、if ( $value == "") {return false;} こういう感じだ。
しかしこのコードをよく見てほしい。なんとそのままでJavaScriptコードとしても通用してしまうのだ!

これを応用すれば、一つのコードでPHPでもJavaScriptでも通用するコードを作れるではないか。
つまり書くのは一度ですむんだ! ちなみに互換性が無い部分は関数を使用することで対処できる。

607 :nobodyさん:2007/08/26(日) 21:58:18 ID:???
>>598
画面を書き換えずにxmlなりjsonなりのデータだけをやりとりすることで
転送量を減らすことができる
それもまたajax。
まあJSチェックをサーバプログラムと別に書くのは基本的にダサい方法だが
十分に抽象化して自動生成するならクリーンにもなりうるな。
書くのは面倒くさそうだが。

608 :nobodyさん:2007/08/26(日) 22:32:58 ID:???
> 画面を書き換えずにxmlなりjsonなりのデータだけをサーバーとデータを転送してやりとりすることで
> 転送量を減らすことができる

あふぉか?w

609 :nobodyさん:2007/08/26(日) 23:08:32 ID:???
なんか文脈なしに非ajax的js過剰に擁護してんの一人だろ
もういいからどっかへ行けよ。スレ違いすぎる

610 :nobodyさん:2007/08/26(日) 23:10:51 ID:???
>>607
xmlやjsonってサーバーと通信するだろ普通。
そりゃサーバーと通信しないで使えないことも無いだろうけどさ、
何のためにxmlやjsonに変換するのかって話。
JavaScriptのオブジェクトそのままでいいじゃんか。

611 :nobodyさん:2007/08/26(日) 23:23:21 ID:???
必死です

612 :nobodyさん:2007/08/26(日) 23:23:47 ID:???
>>609
AjaxもJavaScriptも同じもんだろ・・・

613 :nobodyさん:2007/08/26(日) 23:25:08 ID:???
更に必死です

614 :nobodyさん:2007/08/26(日) 23:25:37 ID:???
みなさん。反論できないのがどっちかはいわなくてもわかるよね?

615 :nobodyさん:2007/08/26(日) 23:28:32 ID:???
互いに話が食い違ってるように見える

616 :nobodyさん:2007/08/26(日) 23:30:45 ID:???
そりゃ、「AjaxとかXMLとかJSONとかとりあえず関係ありそうな言葉を並べてみました。
でも意味はよくわかっていません。なにが間違っているというのですか?」な
素人が混じっているんだから無理ないなw

617 :nobodyさん:2007/08/27(月) 00:07:28 ID:???
いや、一人でやってるように見える

618 :nobodyさん:2007/08/27(月) 00:25:28 ID:???
>>605
じゃあそういうことでいいんじゃね。
馬鹿ひきつれて帰ってくれ

619 :nobodyさん:2007/08/27(月) 00:34:50 ID:???
レスを見たくないのなら自分が消えるしか方法はありません。

620 :nobodyさん:2007/08/27(月) 01:26:01 ID:???
なーんでそんなに相手を論破しようとがんばっちゃうのかね

621 :nobodyさん:2007/08/27(月) 02:19:50 ID:???
正直自前でやった方がPHPもJSもHTMLもすっきりすると思うんだが。
QF使ったソースって見辛くね?

622 :nobodyさん:2007/08/27(月) 02:37:39 ID:???
>>610
いやだから転送量を「減らす」って言ってるじゃん…
サーバサイドのvalidateもするんだよ、もちろん。
二人くらいのど素人が何を撃っているかも分からず銃乱射してる感じだな。

623 :nobodyさん:2007/08/27(月) 02:49:11 ID:???
通信回数と転送量を一緒にして、区別できていないようだな。
転送量が同じでも、PHPを1回呼ぶのと10回呼ぶのでは、
サーバーの負荷(主にCPU)が異なる。
ajax利用では、転送量よりも通信回数が意識されるところ。

624 :nobodyさん:2007/08/27(月) 02:57:01 ID:???
>>623
なんでそんな当たり前のこと言ったん

625 :nobodyさん:2007/08/27(月) 03:11:56 ID:???
でもそんなの関係ねぇ!

626 :nobodyさん:2007/08/27(月) 03:49:30 ID:???
           ∩___∩
          ノ       ヽ  /⌒) 
         /⌒) (゚)   (゚) |/ / はい
        / /   ( _●_)  ミ/  オッパッピー
       .(  ヽ  |∪|  /
        \    ヽノ /
    ___ /      /
   (_____    /
             \ \
               )  )
              (  \     
               \_)


627 :nobodyさん:2007/08/27(月) 06:53:24 ID:???
oreoreFW作ってるんだが
クラス名の命名規則からファイルの位置が決まるようにするのと
チンポニーのように事前にサーチして
クラスファイル位置のインデックスを作っておくの
どっちがベター?

628 :nobodyさん:2007/08/27(月) 09:01:18 ID:???
>>623
通信回数を減らしたところで、
サーバーにアクセスしたら
サーバーにアクセスしないよりも、
レスポンスは落ちるんだよ。
そのレスポンスの速さが重要だというのに。

629 :nobodyさん:2007/08/27(月) 10:26:17 ID:???
テトリスでも作ってんの?

630 :nobodyさん:2007/08/27(月) 11:13:56 ID:???
作っていませんが何の関係があるんですかねぇ?

631 :nobodyさん:2007/08/27(月) 11:18:52 ID:???
           ∩___∩
          ノ       ヽ  /⌒) 
         /⌒) (゚)   (゚) |/ / はい
        / /   ( _●_)  ミ/  PHP
       .(  ヽ  |∪|  /
        \    ヽノ /
    ___ /      /
   (_____    /
             \ \
               )  )
              (  \     
               \_)

632 :nobodyさん:2007/08/27(月) 22:54:54 ID:???
今まで読んできたけど
少なくとも

>>598
> >>596
> > ajaxで転送量減らすこともできるよ
> 転送を伴わないAjaxってJavaScriptと同じことだろw

こいつは馬鹿な素人だと言うことはわかった

633 :nobodyさん:2007/08/27(月) 22:59:33 ID:???
あと、これもアフォですね
>>623
> 通信回数と転送量を一緒にして、区別できていないようだな。
> 転送量が同じでも、PHPを1回呼ぶのと10回呼ぶのでは、
> サーバーの負荷(主にCPU)が異なる。
> ajax利用では、転送量よりも通信回数が意識されるところ。

多分自分の中のAJAXの利用方法しか思いつかないからこういう発言になっちゃうん
だろうけど

634 :nobodyさん:2007/08/27(月) 23:49:43 ID:???
Ajax = Asynchronous JavaScript + XML だ。
JavaScriptの一種に過ぎないんだよ。 よく覚えとけ。

635 :nobodyさん:2007/08/27(月) 23:56:37 ID:???
ははーん
ずっと当たり前のことを言うという新手の釣りだな

636 :nobodyさん:2007/08/27(月) 23:59:39 ID:???
引用だけして罵倒とか、実のあるレスがほとんどねぇ。
もう2chのレベルは初心者おしえて掲示板と変わらんがな。
それでいて口は悪いんだから最悪というか・・・。

637 :nobodyさん:2007/08/28(火) 00:01:45 ID:???
583 名前:nobodyさん[sage] 投稿日:2007/08/26(日) 05:59:51 ID:???
JSでチェックするメリットはあんまりないよな
ajaxでやるならともかく

こいつもあふぉだな。

AJAXで使われている言語はJavaScriptのだってーの。

638 :nobodyさん:2007/08/28(火) 00:03:55 ID:???
もう釣りなのか馬鹿なのか分からなくなってきた
混沌としすぎ

639 :nobodyさん:2007/08/28(火) 00:10:42 ID:???
ajaxでチェックするってどういう意味だろ?

ajaxならかっこいい画面になる?
否 ajaxだからといってかっこよくなるわけでもないし、
javascriptでもかっこよく作れる。

ajaxならダサい標準のダイアログボックスがでない?
否 ajaxでも基本は標準のダイアログボックスだし
javascriptでも標準のダイアログボックス以外を使える。

たぶん、チェックをクライアントコードじゃなくて、
サーバーに問い合わせてやるといいたいんだろうけどさ、
そんなことしたら、サーバーと通信する分遅くなるじゃん?

640 :nobodyさん:2007/08/28(火) 00:14:15 ID:???
サーバーに通信しないとチェックできない項目もある。
メアドが登録済みかどうかとか。

641 :nobodyさん:2007/08/28(火) 00:23:08 ID:???
俺が少し整理してみる。

1)クライアントサイドのみのJavaScriptチェック
入力不足や間違いを即座に指摘できる。

2)Ajaxでサーバサイドをも巻き込んだチェック
1.の発展版。サーバサイドでしかチェックできないような項目を即座に指摘できる。

3)サーバサイドチェック
最終チェック。これは必須。

1や2は利用者の操作性をうpする。うまく作りこめば確認画面は要らないかも。

642 :nobodyさん:2007/08/28(火) 00:29:17 ID:???
もうみんな閲覧条件としてJavaScript必須前提なのか。

643 :nobodyさん:2007/08/28(火) 00:33:01 ID:???
>>642
両方でチェックするに決まってるじゃん。
QFはサーバー側で書くだけで、自動的にJavaScriptコードを生成してくれる。

644 :nobodyさん:2007/08/28(火) 00:52:05 ID:???
何というwhile(1)な流れ

645 :nobodyさん:2007/08/28(火) 00:56:19 ID:???
はいはい。もうそのQFのJS自動生成の話いいから。
スレ違いだつーのに。

646 :nobodyさん:2007/08/28(火) 00:58:15 ID:???
逃げたw

647 :nobodyさん:2007/08/28(火) 00:59:25 ID:???
フレームワークがjsの自動生成までカバーするべきか否かにも繋がるので、あながちスレ違いというわけでも。

QFもフレームワークと言えばフレームワークだよね。
フォーム処理に特化した。


648 :nobodyさん:2007/08/30(木) 17:06:50 ID:???
symfonyとAkelosを比べた場合お勧めはどっちだろう。
誰か両方使ってみた。な人いる?

649 :nobodyさん:2007/08/31(金) 01:27:24 ID:???
>>648
何をどう比べる?
構成そのものは結構派手に違うと思うから、何について知りたいかによるんじゃない?
概念的な比較なのかな?


650 :nobodyさん:2007/09/01(土) 04:07:45 ID:???
PHP5で完全なMVC構造を維持してるコードが少ないフレームワークが欲しい

651 :nobodyさん:2007/09/01(土) 04:22:30 ID:???
PHP5で完全なMVC構造を維持してるコードがないフレームワークが欲しい

652 :nobodyさん:2007/09/01(土) 05:18:08 ID:???
完璧なMVCというものがそもそも存在しなくね?
インターフェイス間でやりとりするんだから少し混じり合うよ

653 :nobodyさん:2007/09/02(日) 21:01:25 ID:???
>>649
もう好きなだけ自由に比べてくらさい。
概念的な比較から、
各フレームワークのお勧めポイントとか

654 :nobodyさん:2007/09/02(日) 21:26:47 ID:???
さらに、その比較をどこかのwikiにでも書いてくれたら嬉しいかな。

655 :nobodyさん:2007/09/03(月) 16:16:55 ID:???
pieceでsubmitボタンじゃなくて、一般ボタンを使用してonClickイベントで
jsからサブミットさせても動かないんだけどなぜ?


656 :nobodyさん:2007/09/03(月) 18:52:31 ID:???
PEARやってみたんだけど、
フレームワークも似たようなもん?
ほしいクラスのあるスクリプトをインクルードして
それを使うってな感じでおk?

657 :nobodyさん:2007/09/03(月) 19:31:30 ID:???
おまえが呼ぶように書くのはライブラリ
呼ばれる部分を書くのがフレームワーク
まあフレームワークは大体ライブラリの側面も含んでるけど

658 :nobodyさん:2007/09/03(月) 19:45:03 ID:???
>>656
そんなレベルではまだはやい。フレームワークも知る必要もない。

659 :nobodyさん:2007/09/03(月) 23:36:39 ID:???
>>656
いや、もっと簡単。
必要なものは全てそろってる。
まずチュートリアルやってみ。
理解できたら8割習得!

660 :656:2007/09/05(水) 14:29:14 ID:???
チュートリアルが何かわからないので0割習得!

661 :nobodyさん:2007/09/05(水) 16:23:04 ID:???
>>660
http://cakephp.jp/doc/blog_tutorial.html どぞ!

662 :nobodyさん:2007/09/05(水) 22:16:46 ID:???
フレームワークを変更した人とかいるかな
今使っているフレームワークが変えても動くように設計していたりする?

ビジネスモデルはクラスとか作っておけばいいけど、viewは結構移植が難しいかな



663 :nobodyさん:2007/09/05(水) 23:09:46 ID:???
>>662
気持ちはわかるけど、やめておけ。ろくなことにならない。

664 :nobodyさん:2007/09/06(木) 08:42:32 ID:???
>>662
できたら公開してね

665 :nobodyさん:2007/09/06(木) 10:13:24 ID:???
意味あるのかないのか良く分からん。

666 :nobodyさん:2007/09/06(木) 23:08:17 ID:???
ここにいるぺちぱーでセミナーとか勉強会行ってる人いる?

667 :nobodyさん:2007/09/07(金) 00:17:11 ID:???
勉強会とか行きまくってたひとが作ったフレームワークからsymfonyに移す作業を今やってる。

ビジネスロジックは可能な限りフレームワーク依存を避けたんでほとんど手付かずでよかったが
ViewはSmartyから生PHPに変更だーね。
でも逆方向の移植よりは作業は難しくないと思う。より何でもできる側への移植だし。
まぁサイトデザインリニューアルだから今回はそれは大した問題ではないが。

DaoをDB_DataObjectからpropelにする作業がいちばん面倒くさい気がする……
これもあらかじめラッパ1枚挟んでおいてたからまだ楽な方だとは思うけど。

668 :nobodyさん:2007/09/07(金) 02:30:04 ID:???
何の話?

669 :nobodyさん:2007/09/07(金) 03:06:25 ID:???
もはやJavaでいいじゃないかと思えるレベルの手間だな。

670 :nobodyさん:2007/09/07(金) 09:59:12 ID:???
>>667
Maple だな。
あれは、移植しやすい・・・というか、それが主眼のFWだったから。

kunitさんは相変わらず消息不明か。

671 :nobodyさん:2007/09/07(金) 14:40:20 ID:???
DBの操作がし易いFWないかな?
$array['field1'] = "テスト1";
$array['field2'] = "テスト2";
$array['field3'] = "テスト3";

を簡単に

INSERT SET field1,field2,field3 VALUES('テスト1','テスト2','テスト3')
みたいな感じにして実行してくれるのが嬉しいんだが・・・
ってこれくらいならfunctionでいけるかな

672 :nobodyさん:2007/09/07(金) 14:44:15 ID:???
1回でおk

673 :nobodyさん:2007/09/07(金) 16:47:19 ID:???
>>666
railsの勉強会はよく見るけど、PHP系のフレームワークの勉強会ってある?
symfonyかcakeの勉強会があればいきたいけど。

674 :nobodyさん:2007/09/07(金) 17:16:28 ID:???
>>671
DAOでぐぐれとかそういう

675 :nobodyさん:2007/09/07(金) 17:21:33 ID:???
>>673
zendがやってたきがす

676 :nobodyさん:2007/09/07(金) 17:35:52 ID:AJh2IEJ8
フレームワークっぽくはないけどrhacoが気になる

677 :nobodyさん:2007/09/07(金) 18:38:38 ID:???
>>671
MDB2のautoExecute()とか。

678 :nobodyさん:2007/09/07(金) 20:47:47 ID:???
>>667
そうそうDB回りも移植性を考えるとどうなんだろう
結局生のSQLを書いた方が移植性はいい気がするけどどう?

679 :nobodyさん:2007/09/07(金) 21:01:05 ID:???
>>671
どんなFWでも出来ると思うが、それ以前に、

$array = array('field1'=>'テスト1,'field2'=>'テスト2,'field3'=>'テスト3,);

という書き方を知っているか?

680 :nobodyさん:2007/09/07(金) 21:29:31 ID:dCrM/XyG
ブログシステム的なものを作るのに、Django使いには何がお勧めですかね?

681 :nobodyさん:2007/09/07(金) 23:26:18 ID:???
てか、もうフレームワークにしなくても
独自で作った関数・クラスを使いまくるので、よくねぇ?

682 :nobodyさん:2007/09/07(金) 23:30:23 ID:???
それはライブラリじゃね?

683 :nobodyさん:2007/09/08(土) 00:53:21 ID:???
PHP at Yahoo! JAPAN
http://searchblog.yahoo.co.jp/2007/09/php_at_yahoo_japan.html

日本のYahoo!でも使っているようだし、フレームワークの本命は、やはりsymfonyかな。

684 :nobodyさん:2007/09/08(土) 01:05:57 ID:???
php.netってyahooが提供してたのか・・・知らんかった

685 :nobodyさん:2007/09/08(土) 02:00:20 ID:???
てか、GoogleもPHP使ってるし、楽天もPHP+MySQLだったはず。
割と有名な大企業で使っているから、もうPHPだけで良い気がする。

686 :nobodyさん:2007/09/08(土) 02:04:36 ID:???
googleはpythonだろ

687 :nobodyさん:2007/09/08(土) 02:07:31 ID:???
Yahooとか楽天とか、バックエンドのコアな処理はみんなJavaだけどな。
確かにフロントではPHPを使ってるけど。
DBも当然オラクルだよ。MySQLなんかじゃ機能も性能も追いつけるわけないじゃん。

688 :nobodyさん:2007/09/08(土) 02:10:46 ID:???
やっぱり、まだまだ俺たちには勉強が必要ってことか・・・

689 :nobodyさん:2007/09/08(土) 02:16:07 ID:???
googleは数千台のMySQLだろ

690 :nobodyさん:2007/09/08(土) 02:20:34 ID:???
>>680
Django使いにはrhacoがオススメだと親分が言っていた

691 :nobodyさん:2007/09/08(土) 02:40:44 ID:???
>>685
>楽天もPHP+MySQLだったはず。
何年前の話だ。
今はまつもと御大も迎えてRuby一色になろうとしてる。

692 :nobodyさん:2007/09/08(土) 02:46:14 ID:???
>>691
すまん。「楽天 PHP」でググった記事を見たら書いてあったんだが、
日付を見たら、2003年の記事だったw

693 :nobodyさん:2007/09/08(土) 02:54:40 ID:???
>>692
で、それを指導してたのが若き日のふじもとさんなんだな。

694 :nobodyさん:2007/09/08(土) 02:56:09 ID:???
ライブラリーとかフレームワーク使ってると
早く完成品が拝める。

でも正直自分が作った気がしないのは俺だけ?


695 :nobodyさん:2007/09/08(土) 03:18:55 ID:???
作者が楽天に走ってrubyの印象が悪くなったよな

696 :nobodyさん:2007/09/08(土) 04:13:53 ID:???
大手出版社の人が「Ruby on Rails」は一過性のブームで終わったと言ってたな。
たくさん入門書が出たけど、どれも全然売れてないとか。

自分の周りでは、中規模案件を中心に「Beyond Java To PHP」って感じ。

697 :nobodyさん:2007/09/08(土) 05:13:52 ID:???
結構yahooでsymfony使われてることが意外
あれそんなにいいか?
俺もフレームワーク発表してyahooに入社したろか

698 :nobodyさん:2007/09/08(土) 05:24:38 ID:???
>>694
少なくとも仕事はそれでいいんじゃないかとw

>>697
是非がんばってくれ
いろんな実装見たい


699 :nobodyさん:2007/09/08(土) 18:31:05 ID:+ZuhJBWz
>>690
rhacoですか.Djangoに似てるんですかね?
どうもあのサイトのデザインの印象が良くないんだよね….

でも,親分が言うなら使ってみるかな.

700 :nobodyさん:2007/09/08(土) 19:31:56 ID:???
>>699
ってか親分知ってるならブログ見てるって事じゃないのか?w
さんざん親分のブログで持ち上げてるじゃんかw

701 :nobodyさん:2007/09/08(土) 21:33:52 ID:+ZuhJBWz
>>700
ごめんなさい.親分知らないです.
ノリで言ってみただけです.

702 :nobodyさん:2007/09/08(土) 22:32:03 ID:???
rhaco公式のデザインの悪さには同意せざるを得ない。
ダウンロードして欲しくないかのようなデザイン。
もしそっちのセンスがないのなら、いますぐにでも任せられる人を募るべき。
あのサイトのデザインは、フレームワークを使いはじめた人間が、
なんでもかんでもリストで出力してテンプレートで並べたてるのに酷似している。
(そして、そうなるのもよくわかる。すごく簡単にできるから。)

703 :nobodyさん:2007/09/09(日) 02:11:31 ID:???
結局フレームワークはどれがいいのよ
だれかそれぞれの特徴とかまとめて

704 :nobodyさん:2007/09/09(日) 03:23:27 ID:???
どれがいいかわからんやつはフレームワークに使われる落ち

705 :nobodyさん:2007/09/09(日) 06:56:00 ID:???
大手出版社の売り上げで技術選ぶアホが居るよ

706 :nobodyさん:2007/09/09(日) 12:12:06 ID:???
>>697
馬鹿じゃない?

707 :nobodyさん:2007/09/09(日) 12:23:37 ID:???
ttp://www.atmarkit.co.jp/news/200709/07/yarv.html
PHPオワタ

708 :nobodyさん:2007/09/09(日) 12:37:24 ID:???
でも、言語の部分であまり重い処理とかやらないから関係なくね?
大部分がデータベースの処理とそのI/O速度に依存しているんだし。

709 :nobodyさん:2007/09/09(日) 13:30:15 ID:???
そこまで速度にこだわるなら、Yahooがやっているようにextension化すればいい。
PHPとはそういうもの。

710 :nobodyさん:2007/09/09(日) 15:07:33 ID:KH7TY7ET
フレームワークにはいろいろなタイプのものがあるんですね。
MVCパターンというフレームワークと、ステートマシンというフレームワークは、根本的に何か違うんでしょうか?
PHPプロが肩入れしている(?)Piece Frameworkってどうですか?
http://www.phppro.jp/news/415

711 :nobodyさん:2007/09/09(日) 15:14:07 ID:???
MVCとステートマシンを考慮したフレームワークを作る事ができる。
もうちょっとそれぞれを調べてから質問した方が、話が広がって良い。

712 :nobodyさん:2007/09/09(日) 16:01:22 ID:???
>質問が自分の知識レベルの範囲内で回答できる内容だった場合、
>「そんな事も知らないのか」「そんな事も知らないならこのツールを使うべきではない」
>「少しは努力しろ」等と罵倒するだけで、絶対に回答しない。

>質問が高度すぎて自分の知識レベルでは理解できなかった場合、質問を無視する。


713 :nobodyさん:2007/09/09(日) 16:14:31 ID:???
http://www.google.co.jp/search?hl=ja&q=%22%E8%B3%AA%E5%95%8F%E3%81%8C%E8%87%AA%E5%88%86%E3%81%AE%E7%9F%A5%E8%AD%98%E3%83%AC%E3%83%99%E3%83%AB%E3%81%AE%E7%AF%84%E5%9B%B2%E5%86%85%22&lr=

714 :nobodyさん:2007/09/09(日) 16:14:40 ID:T1ZRLBlB
>>707
オワタって。。。
5倍以上遅いだろうがw

715 :nobodyさん:2007/09/09(日) 16:16:16 ID:???
最大で五倍。多くの場合は変わらない。よくある話。

716 :nobodyさん:2007/09/09(日) 17:18:00 ID:???
ちなみにステートマシン・フレームワークがあることを知らなかったのだけど、
これは状態遷移図とそれぞれのアクションを記述するというような理解でいいの?
Javaのフレームワークについて書いた記事しか見てないけど。
まあ、確かにわかりやすそうだし、全ての状態を一目で把握できるというのはよさそう。
MVCでアクションを書いてると際限なく増やせるから、それを管理できなくなるって話はありそうだし。
でも、例えばステートマシンをMVCのコントローラで採用すれば、って話にならないの?

717 :nobodyさん:2007/09/09(日) 20:11:55 ID:???
>>715
すくなくとも記事嫁でから書けよ
最大20倍、平均5倍って書いてあるぞ

あくまでマイクロベンチの結果だから当てにならないって言うのは事実だが

718 :nobodyさん:2007/09/09(日) 20:49:52 ID:???
うーん。
なんかベンチ合戦に巻き込まれてるような気がする。
実装を換えて何倍速くなりましたっていうのは、本来つまらない話のはずなんだけど…。


719 :nobodyさん:2007/09/09(日) 21:13:37 ID:???
Piece Frameworkによるブログアプリケーションの作成
http://gihyo.jp/dev/serial/01/piece

JavaのStrutsみたいなフレームワークなんですかね?
Ruby on Railsもどきとは一味違うタイプなのかな。
煩雑なFWに見えたのは、多分俺が単純な人間だからだと思います。orz


720 :nobodyさん:2007/09/09(日) 22:04:07 ID:???
>>719
フロー定義のyaml見ると眩暈がするな
Java臭い香りがぷんぷんするぜ

721 :nobodyさん:2007/09/09(日) 23:33:35 ID:???
>>720
作者はPoEAA読むのを人にもすすめるほどだから、それは仕方ないだろう。

pearコマンドでインストールというのがまず壁だな。
アーカイブ落として、解凍して、ドキュメントルートにおけば使えるようにして欲しいよ。

722 :親分:2007/09/09(日) 23:46:25 ID:uiImO4wM
>>721
YOU! rhacoやっちゃいなYO!

723 :nobodyさん:2007/09/10(月) 00:43:46 ID:???
というより一昔前の設計なだけ

724 :nobodyさん:2007/09/10(月) 00:53:17 ID:???
Ruby on Railsがでてから、
一気に世代が変わっちゃったよな。

725 :nobodyさん:2007/09/10(月) 02:00:28 ID:???
rails使えない環境も多いわけで自社開発でやる気のあるとこ以外はrailsに移行しないきがす。
うちはrails部隊もあるが。phpでほとんど組んでる

726 :nobodyさん:2007/09/10(月) 02:49:19 ID:???
phpにもRails風のフレームワークがいくつかあるじゃん

727 :nobodyさん:2007/09/10(月) 03:03:48 ID:???
CakePHP楽だよ。本当に楽。

728 :nobodyさん:2007/09/10(月) 04:40:16 ID:???
レンタルサーバーは実際問題PHP5への切り替え断行なんてできるのかな?
4でしか動かないクライアントのスクリプトも相当あるだろうし
それをバッサリ切ると業務に支障をきたして大問題になると思うんだが…
運営各社はいったいどうやって切り抜けるんだろうな

729 :nobodyさん:2007/09/10(月) 05:54:44 ID:???
>>728
XREAみたいに新しく追加された鯖は5系にするとかじゃないのかな
CPIとかは現状でハンドラ書いて選べたよね確か

730 :nobodyさん:2007/09/10(月) 11:45:24 ID:???
PHP5の最新版って毎回セキュリティフィックスが山のようにある。セキュリティを考えるならPHP4の最終版を使い続けた方がまし。

731 :nobodyさん:2007/09/10(月) 11:53:48 ID:???
>>730
他の言語使ってたりして、一度例外処理になれてしまうとtry〜の無いphp4には
戻れなくなるよw

732 :nobodyさん:2007/09/10(月) 11:56:11 ID:???
つ、釣られないぞ

733 :nobodyさん:2007/09/10(月) 13:44:08 ID:???
他の言語使ってたりして、一度例外処理になれてしまうと〜finallyの無いphp5には
戻れなくなるよw

734 :nobodyさん:2007/09/10(月) 13:53:45 ID:???
>>731
>>733
ならおまえらは戻ってこなくていいから、もう黙ってろ。

735 :nobodyさん:2007/09/10(月) 16:08:54 ID:???
4厨必死すぎwwww

736 :nobodyさん:2007/09/10(月) 16:17:21 ID:oeJv3ute
日本発のフレームワークって徐々に開発が滞る気がするのですが間違った認識ですか?

737 :nobodyさん:2007/09/10(月) 16:44:21 ID:???
>>736
大丈夫です、海外の奴も長続きするのは100にひとつもありません。
sf.netへ行って"php framework"してみるとわかります。

単に確率の問題でしょうが、日本初のフレームワークの絶対数がすくないので、
日本だからどうこう、というのを論じるのはまだ早いと思われます。


738 :nobodyさん:2007/09/10(月) 20:05:52 ID:???
>>736
Kaedeを心待ちにしてた俺に対する挑戦状か?

739 :nobodyさん:2007/09/10(月) 20:21:54 ID:???
俺frameworkでやってきたけど、
自分一人で開発することがほとんどなので、間違ってなかった気がする。



740 :nobodyさん:2007/09/10(月) 21:38:42 ID:???
それで済んでるなら間違ってないと思うよ

741 :nobodyさん:2007/09/10(月) 21:41:25 ID:???
失礼、なんか煽ってるみたいな文になってしまった

プログラムそのものの美しさを求める趣味人でもない限り、
正しく目的を達成できるなら俺FWでもSymfonyでも国産FWでも同列だろう、
って意味で。間違ってないと思うよ。

742 :nobodyさん:2007/09/10(月) 21:45:47 ID:???
symfony×PHP
ttp://www.amazon.co.jp/exec/obidos/ASIN/4774132373/doyouphp-22/ref=nosim

743 :nobodyさん:2007/09/11(火) 00:18:16 ID:???
PHP総受け

744 :nobodyさん:2007/09/11(火) 03:26:25 ID:fZWv6wPR
Zend Framework 本
http://www.sotechsha.co.jp/pc/html/593.htm

745 :nobodyさん:2007/09/11(火) 08:25:26 ID:???
>>742
>>744
(・∀・)イイヨイイヨ♪

…アレ?Symfonyは本家の解説本を翻訳したらいいんじゃないの?>出版社

746 :nobodyさん:2007/09/11(火) 10:04:02 ID:???
>>745 昔そう思ったのですがネットで日本語訳が既に入手できる上に
貰える印税が通常よりも少ないのでやらないでしょう。

747 :nobodyさん:2007/09/11(火) 12:48:48 ID:???
中身まで薄そうな本だな

748 :744:2007/09/11(火) 18:56:13 ID:fZWv6wPR
>>745
佐久嶋ひろみのフレームワーク本は内容的にしょっぱかったからな。
今度はZendの監修らしいので、期待したいところではある。

749 :nobodyさん:2007/09/11(火) 19:34:40 ID:???
Zendなんてまだ安定してないのに
よく本なんか出すよなw

750 :nobodyさん:2007/09/12(水) 04:17:24 ID:???
Zend_Pdfは結局正式リリースになってもマルチバイト無視だったしな。
びっくりするほど完成度が低い。


751 :nobodyさん:2007/09/12(水) 05:55:49 ID:???
一人で作ってるから仕方ない

752 :nobodyさん:2007/09/12(水) 11:12:48 ID:???
pdfなんてコアな部分でもないしな

753 :nobodyさん:2007/09/13(木) 01:26:49 ID:???
zendは流行らない気がするよ。

754 :nobodyさん:2007/09/13(木) 02:14:43 ID:???
フレームワークとしてははやらないかもな

755 :nobodyさん:2007/09/13(木) 03:16:12 ID:???
zendは使ってる人も一人

756 :nobodyさん:2007/09/13(木) 12:16:32 ID:???
Zendはライブラリ的に使えるのかなと思ったら、
requireがどこかに飛んでいく・・・

757 :nobodyさん:2007/09/13(木) 12:36:37 ID:???
飛んでるのおまえのZendだけだぞ

758 :nobodyさん:2007/09/13(木) 12:42:08 ID:???
はい オッパッピー(^o^)/

759 :nobodyさん:2007/09/14(金) 00:40:47 ID:???
小島よしろ24時間テレビ事件についていまごろ知った、、

760 :nobodyさん:2007/09/23(日) 05:16:55 ID:???
このスレがこんな寂れるとは何事だ。

761 :nobodyさん:2007/09/23(日) 05:27:39 ID:???
このスレはけっこう浮き沈み激しいからな

762 :nobodyさん:2007/09/23(日) 21:24:35 ID:???
自作MVCフレームワーク作ってみた。
MVC分離だけやってるが、ちょっと勉強になった。

763 :nobodyさん:2007/09/23(日) 22:53:51 ID:gK2i0s5m
>>762
公開しる

764 :うほ:2007/09/23(日) 23:41:59 ID:???
http://www.amazon.co.jp/gp/product/4881665936
↑この本の著者の藤野って元有限会社アームワークス社長の藤野やん。wwwwwwwwwwwwww
しかもコンピュータ総合学園HAL(大阪)の卒業生且つ非常勤講師ってのは皆知ってる?

765 :nobodyさん:2007/09/24(月) 00:17:30 ID:???
宣伝乙

766 :nobodyさん:2007/09/24(月) 16:33:37 ID:???
http://slashdot.jp/articles/07/09/23/2357202.shtml
RoRからPHPへの逆流開始でRuby脂肪www

767 :nobodyさん:2007/09/24(月) 18:20:12 ID:???
>>743
ワロタw

768 :nobodyさん:2007/09/24(月) 22:47:17 ID:JlRJpJ4M
JavaでMVCモデルに慣れてたからSmartyは便利だね。
PHPは何でも気軽に作れて簡単でいい言語だよ。


769 :nobodyさん:2007/09/25(火) 04:40:30 ID:???
>>766 原文をよく読んでみな。自分がしたいことをするために適切なツールを選ぶことの大切さと
Railsを勉強したおかげでPHPできれいなコードを書けるようになったと書いてあるよ。

770 :nobodyさん:2007/09/25(火) 04:58:49 ID:???
そりゃ2年も費やしたらそれくらい学べるだろ・・・Railsがなくても

771 :nobodyさん:2007/09/25(火) 14:57:52 ID:???
rorに限らず、他の言語とかテクニックとか思想とか
しっとくのは幅が広がるわね

772 :nobodyさん:2007/09/25(火) 16:47:04 ID:???
         ,. -‐'''''""¨¨¨ヽ
         (.___,,,... -ァァフ|          あ…ありのまま 今 起こった事を話すぜ!
          |i i|    }! }} //|
         |l、{   j} /,,ィ//|       『おれは30分でアプリが作れると
        i|:!ヾ、_ノ/ u {:}//ヘ        思ったらいつのまにか2年かかってもできてなかった』
        |リ u' }  ,ノ _,!V,ハ |
       /´fト、_{ル{,ィ'eラ , タ人        な… 何を言ってるのか わからねーと思うが
     /'   ヾ|宀| {´,)⌒`/ |<ヽトiゝ        おれも何をされたのかわからなかった…
    ,゙  / )ヽ iLレ  u' | | ヾlトハ〉
     |/_/  ハ !ニ⊇ '/:}  V:::::ヽ        頭がどうにかなりそうだった…
    // 二二二7'T'' /u' __ /:::::::/`ヽ
   /'´r -―一ァ‐゙T´ '"´ /::::/-‐  \    時間の無駄だとか出来る出来る詐欺だとか
   / //   广¨´  /'   /:::::/´ ̄`ヽ ⌒ヽ    そんなチャチなもんじゃあ 断じてねえ
  ノ ' /  ノ:::::`ー-、___/::::://       ヽ  }
_/`丶 /:::::::::::::::::::::::::: ̄`ー-{:::...       イ  もっと恐ろしいものの片鱗を味わったぜ…

773 :nobodyさん:2007/09/25(火) 17:34:53 ID:???
しかし2ヶ月でできるものを2年かかってできなかったなんて、
言語やフレームワークを語る以前にエンジニアとして駄目な気がする・・・

そんなんRubyどころかCでも1年もあればできそうなもんだがw

774 :nobodyさん:2007/09/25(火) 17:37:57 ID:???
レールから脱線して走ろうとしたらそんなことになるんじゃね
ないとは言えないな
賢くあろうとして泥沼にはまることはむしろよくあることかも・・・

775 :nobodyさん:2007/09/25(火) 17:50:32 ID:???
フレームワーク病だな

776 :nobodyさん:2007/09/25(火) 20:09:28 ID:???
         ,. -‐'''''""¨¨¨ヽ
         (.___,,,... -ァァフ|          あ…ありのまま 今 起こった事を話すぜ!
          |i i|    }! }} //|
         |l、{   j} /,,ィ//|       『おれは10分でアプリが作れると聞いたから使った。
        i|:!ヾ、_ノ/ u {:}//ヘ        なのにできたのはアプリとは思えないものだった。』
        |リ u' }  ,ノ _,!V,ハ |
       /´fト、_{ル{,ィ'eラ , タ人        な… 何を言ってるのか わからねーと思うが
     /'   ヾ|宀| {´,)⌒`/ |<ヽトiゝ        おれも何を作ったかわからなかった…
    ,゙  / )ヽ iLレ  u' | | ヾlトハ〉
     |/_/  ハ !ニ⊇ '/:}  V:::::ヽ        頭がどうにかなりそうだった…
    // 二二二7'T'' /u' __ /:::::::/`ヽ
   /'´r -―一ァ‐゙T´ '"´ /::::/-‐  \    デザインに調整が要るとか、インターフェースが使いにくいとか
   / //   广¨´  /'   /:::::/´ ̄`ヽ ⌒ヽ    実用的なアプリはそんなチャチなもんじゃあ 断じてねえ
  ノ ' /  ノ:::::`ー-、___/::::://       ヽ  }
_/`丶 /:::::::::::::::::::::::::: ̄`ー-{:::...       イ  もっと恐ろしいものの片鱗を味わったぜ…


777 :nobodyさん:2007/09/25(火) 22:42:43 ID:???
PHPのフレームワークはどれもDBまわりがヘボいな

778 :nobodyさん:2007/09/25(火) 23:12:48 ID:???
だからフレームワークなんて使う奴が馬鹿だって前から言ってるじゃん
フレームワーク厨プギャー

779 :nobodyさん:2007/09/26(水) 01:46:16 ID:???
んー、まずウェブアプリ作る上で言語は決定的なファクターにはならないんだよな。Cで書こうがRubyで書こうが、出来ることはPHPで書くのと同じなんだから。
まあ、確かにPHPの言語仕様はしょぼいけど、その分開発メンバーを集めやすいというメリットはある。
あとRailsのせいでウェブフレームワークにはORマッパーが当たり前みたいな風潮が出来たけど、別にORマッパーなんてなくてもいい。
手軽で便利ではあるけど、SQLの知識が十分あれば普通にDAOクラスを書く方が効率のよい処理になる。長短あるから、適材適所だな。

780 :nobodyさん:2007/09/26(水) 10:20:21 ID:???
フレームワーク使って作業効率が上がるわけがない

781 :nobodyさん:2007/09/26(水) 10:52:32 ID:???
オブジェクト指向言語で作る場合、O/Rマッパーは必須だよな。
フレームワークは作業効率が上がる。
なぜなら、フレームワークに相当する部分を
自分で作らなくていいからだ。

782 :nobodyさん:2007/09/26(水) 12:31:56 ID:???
なんでそんな今更なところまで話が立ち返っちゃってんの?

783 :nobodyさん:2007/09/26(水) 19:57:23 ID:???
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の知識があるかどうかじゃないんだよね。
くだならいケアミス(こんなの知識と関係ない)が大幅に減ることが重要。

784 :nobodyさん:2007/09/26(水) 20:38:06 ID:???
それO/Rマッパというよりクエリビルダ寄りな話だな
言いたい事はわかるが

785 :nobodyさん:2007/09/26(水) 21:23:52 ID:???
(1) SQL自分で書く

(2) DB抽象化レイヤは現状欠かせない

(3) プレースホルダと自動エスケープ機能が欲しくなる

(4) どうせならクエリビルダ化

(5) だったら実行結果も自動でORM

下に行くほど書くの楽になるけど自由度が減る(特例に対処しにくくなる)ので
ときどき上に登りたくなるが
それでも(3)より上には行く気しないなぁ

786 :nobodyさん:2007/09/26(水) 21:37:05 ID:???
Railsで言ってるみたいに10分でウェブアプリを作りたいならORマッパーがいいだろう。が、現実的にはそんな要求はほとんどない。

787 :nobodyさん:2007/09/26(水) 21:59:39 ID:???
(3) って prepared statement と何が違うの?


788 :nobodyさん:2007/09/26(水) 22:22:29 ID:???
違わないんじゃない?

789 :nobodyさん:2007/09/27(木) 01:22:13 ID:???
>>785あたりについて詳しい解説してる本やサイトってあるかな。

790 :nobodyさん:2007/09/27(木) 01:57:31 ID:???
hibernateのドキュメント読めば?

791 :nobodyさん:2007/09/27(木) 03:15:16 ID:???
>>783
その配列本当?

CakePHPはソース見た程度で使ったこと無いが、その程度の
Criteriaしかないならうんこだな。

ORMにJOINまでの複雑さは求めないけど、その配列じゃすぐ破綻する。

792 :nobodyさん:2007/09/27(木) 04:13:10 ID:???
>>791
CakePHP 使ってないから知らんけど一般論として
そういう配列で使えるって例があったからって
そういう配列でしか使えないと決まったわけでもなかろう

793 :nobodyさん:2007/09/27(木) 07:31:38 ID:???
俺はORマッパー使い辛い派なんだけど、その配列が直感的だとはとても思えない。
ケアレスミスも防げるとは全く思えない。SQLで書けば、別でテストも出来るし。
逆にミスが増えそう。パッと見何やってるのか解りつらい(慣れだろうけど)。
また、JOIN使おうとすると、とたんに面倒になる&解りにくくなる印象がある。
というか、結合を使わないSQL文を発行することって、ほとんどないと思う。
他人に処理を教える時も、SQL文で書いてる方が教えやすいしね。
同じような理由で、SymfonyのJavascript系のHelperも使ってないな。

794 :nobodyさん:2007/09/27(木) 11:17:59 ID:???
>>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も発行できるから問題ない。

795 :nobodyさん:2007/09/27(木) 11:43:57 ID:???
それをせけんじゃORMと呼んでるんだが・・・

796 :nobodyさん:2007/09/27(木) 11:46:18 ID:???
そんなことわかっているが?

797 :nobodyさん:2007/09/27(木) 11:50:42 ID:???
ORMとしてクエリビルダなんてORMとはまったく対極の説明初めて、
Cakeダサいって言われて、ORMの基本の説明始めたから。
わかってるならいいんだ。

798 :nobodyさん:2007/09/27(木) 12:18:19 ID:???
仕方ないだろ。俺は元々(ORMも便利だが)クエリビルダも便利だよって
話をしているのに、JOINというクエリビルダではなく
ORMに関係する話を持ち出してきてダサイ(しかも根拠無し)とか言い出したんだから。

ところで、こういう感じの良く考え抜かれたクエリビルダって
CakePHP特有のものなの? ORMでは一般的なものだと思っていたから持ち出したんだけど。
だとしたらCakePHPってすごいな。

799 :nobodyさん:2007/09/27(木) 12:28:36 ID:???
> ORMとしてクエリビルダなんてORMとはまったく対極の説明初めて、
別に対極の話じゃないと思うけどね。
条件をSQL文字列ではなくオブジェクトで指定できるわけだから。

一旦>>783のオブジェクトから、SQL文字列を生成して
それを基にクエリーするわけじゃないよ。

あれ自体が、検索条件オブジェクト。
クエリーするときにあのオブジェクトを引数にいれて呼び出せばいい。
(当然内部でSQL文字列に変換しているわけだが)

800 :nobodyさん:2007/09/27(木) 13:00:32 ID:???
> ところで、こういう感じの良く考え抜かれたクエリビルダって
> CakePHP特有のものなの? ORMでは一般的なものだと思っていたから持ち出したんだけど。
> だとしたらCakePHPってすごいな。

Railsのパクリ。もちろんそれが悪いわけではない

801 :nobodyさん:2007/09/27(木) 13:42:55 ID:???
>>800
なるほど。ORMとしては一般的というわけじゃないが、
CakePHPが参考にした、Railsのパクリということか。
別にパクリだろうがパクリでなかろうが、それでどういう言うつもりはないw

それはそれとして、Railsは言語ごとよくわからんのだが、
Railsの本、一応二冊持っている。それを見たのだが、どうも
検索条件の所は、SQL+プレースフォルダって感じなんだけど
本当にオブジェクトで指定できるの?
俺が知らないだけって可能性のほうが高いんだけどさ。

802 :nobodyさん:2007/09/27(木) 14:07:01 ID:???
>>801
もうおまえはcakeスレに帰れ

803 :nobodyさん:2007/09/27(木) 15:05:49 ID:???
CakePHPもフレームワークだろw

804 :nobodyさん:2007/09/27(木) 15:32:20 ID:???
なんか変なの湧いてるな

805 :nobodyさん:2007/09/27(木) 15:56:37 ID:???
あぁ、フレームワーク(CakePHP)の話題をしていたら、
スレ違いでもないのに帰れといっちゃうやつのことだな。
話についていけないからってw

806 :nobodyさん:2007/09/27(木) 16:04:57 ID:???
ここをORMスレと勘違いしていたか、
それともCakePHPがフレームワークだと知らなかったんだろうなw

807 :793:2007/09/27(木) 18:27:59 ID:???
おお、俺がJOINがどうこうとか書いちゃったか荒れちゃったか、すまん。
あの配列をどうこうって言いたかったわけじゃなくて、SQLをPHPで表すことが
「解りにくい」って事を言いたかった。
別にCakePHPを指して「不便だ」って言ってるのではなくて、ORMそのものが
自分には合わないし、"例えば"CakePHPを知らない人(もしくはPHPを知らない人)に
教えるには、ORMを使うより、SQL直書きの方が理解が早いだろう、と。
ただそれだけだったの。ごめんね。


808 :nobodyさん:2007/09/27(木) 20:09:04 ID:???
別に荒れてない変な奴がいるだけだ、どうでもいいが

ORM使ってても極端な話全部クエリベタ書きでも済ませられるわけで、
こんな定型的で単純なクエリいちいち書くの面倒だな、ってとこだけ
ORM側でクエリ生成してもらって抽象的に書けばいいだけのもんだと思うんだけど
ORMを使ってても何から何までORMでやるわけじゃない
ベタ書きや部分的にクエリを生書きするケースなんていくらでも出る
でもその上で単純で面倒な部分を抽象化して楽させてくれるのがORMの役割だろう

教えるにはってのは分かるけどさすがに別問題
SQLは最低限理解してる上でのORMなんだから
ただphpのORMがどれも使いにくいのは分かる、
どちらかというとphpの言語仕様に起因する問題が大きいけど
railsから戻ってくると使い辛くて仕方ない

809 :nobodyさん:2007/09/27(木) 20:40:32 ID:???
> こんな定型的で単純なクエリいちいち書くの面倒だな、ってとこだけ
単純なクエリ(俺は”単純なクエリ”にJOINを使ったものも含める)が
それがほとんどなんだけどね。

> こんな定型的で単純なクエリいちいち書くの面倒だな、ってとこだけ
> ORM側でクエリ生成してもらって
ORMで解消される面倒な部分はクエリ生成部分だけじゃないでしょ?
もっと面倒な変数への代入をやってくれるのがいい。

JOINが含まれている場合、ORMを使わないとベタな二次元の表にしかならないが
ORMならコードで扱いやすいようにちゃんとした階層構造になっている。

ORMとは、その名前の通り、オブジェクト と リレーショナル のマッピング。
普段オブジェクト指向でプログラミングしていたら、ベタな二次元の表は扱いにくい。

> ただphpのORMがどれも使いにくいのは分かる、
で、肝心の使いにくいと言う理由は?
それがないと、なんだかなぁで終わり。


>>793さんはORMに慣れていないってだけで、
ORMが使いにくいとは言っていないと解釈した。
つまり使いにくいと言っているのは>>808だけ。

810 :nobodyさん:2007/09/27(木) 21:28:14 ID:???
っていうか、JOINを使って実現するような場合こそORMの本領発揮だろ?

JOINを使わない場合、二次元の表にしかやりようがないわけで、
それくらいなら、直接データを扱っても変わらない。

ここで勘違いさんは、ORM使わないでやったほうが良いじゃんと思う。

本領発揮のJOINが含まれている場合だと、アソシエーションという新しい用語が
でてくるため、勘違いさんはORMはわけわからんとアソシエーション以前の知識で思考停止する。
単に一対多とかいう情報を設定しているだけなのにね。

この二つの勘違いから、ORMを使う必要はないし、
JOINをやるときは複雑だ。という結論になるんだろうな。

本当は、特にJOINが含まれるようなときに面倒な部分がかなりなくなるから
ORMを使ったほうが便利。なのにね。

811 :nobodyさん:2007/09/27(木) 23:19:39 ID:???
>>809
使いにくいよ
cakeだとそもそもデータ取得して戻ってくるのオブジェクトじゃなく配列だし
model自体(取得して返って来るレコードオブジェクト)の拡張できない
symfonyのpropelはmodelの生成でファイル増えまくるし
Criteriaは冗長過ぎる、生で書いた方がマシ

812 :nobodyさん:2007/09/28(金) 00:31:17 ID:???
読む気にもならん臭いスレになりさがったな。

とりあえずcommon.phpに戻ってみ本当に自分にFWがいるのか再考してみたら?

813 :nobodyさん:2007/09/28(金) 00:35:06 ID:???
配列ってだけでしょ?
modelの拡張? 継承して普通にやっているが?

検索後のデータを内容を加工したり、またセーブ直前にデータを加工
(たとえばひらがなをカタカナに変換するなどしていれたり何でも出来る。

ひらがなをカタカナに変換する例なら、behaviorを継承したオブジェクトを作って
beforeSaveで変換すればいいだけだな。

データベースに無い合計フィールドを付け加えるとかいうのなら、
単にAfterFindでデータを付け加えればいいだけだな。

手間はデータがオブジェクトである場合となにもかわらない。

こういう実装になっていますって言っているだけじゃ使いにくいの説明になっていない。
具体的に、どんなことが出来ないのか言ってくれないとわからないなぁ。

> 生で書いたほうがマシ
いやさ、生でかいたらデータは配列だよ?
自分でオブジェクトじゃなければ使いにくいと言っておきながらw


814 :nobodyさん:2007/09/28(金) 00:36:16 ID:???
>>812
読む気にならないなら、読まなければいいだけw

ぐちぐちいいながら見る必要は無いんだよ。
馬鹿じゃない? だまっていなくなれば問題なし。

815 :nobodyさん:2007/09/28(金) 00:39:35 ID:???
>>812
> とりあえずcommon.phpに戻ってみ本当に自分にFWがいるのか再考してみたら?

再考するまでも無いな。フレームワークとかそんな大げさに考える必要は無い。

common.phpを何倍も便利にしたライブラリ。
より便利なライブラリを使う。
それだけの話

816 :nobodyさん:2007/09/28(金) 00:57:02 ID:???
長文日本語ばかりで萎える
精神論ばかりでなく、コードを提示して
ほら便利だよとか言って欲しい


817 :nobodyさん:2007/09/28(金) 02:12:27 ID:???
>>813
> > 生で書いたほうがマシ
> いやさ、生でかいたらデータは配列だよ?
> 自分でオブジェクトじゃなければ使いにくいと言っておきながらw

propel の Criteria が冗長すぎて、生で条件を書いたほうがマシって話だろ。

818 :791:2007/09/28(金) 06:12:15 ID:???
なんだ、随分とのびたな。

>>794
>複雑どころか、なんと書く必要すらない。
>
>まあ、何もないところからJOINがでてくるわけないので何かの情報は
>必要なわけだが、ER図で、1対1とか1対多とか多対多とか定義するでしょ?
>あの情報を、このテーブルは他のテーブルとどういう関係にあると書くだけ。

書く必要ないって、・・・書いてんじゃん。w


オレもORMは使うよ。でもCakePHPは使ったこと無くて、
Cakeではあの配列をORMっていうのか?って思ったから聞いただけ。
MLでもなし、にちゃんでいちいち勉強してから書き込むかっつの。

791はORM知らない。ORMは銀の弾丸。根拠なしで思い込みで言っちゃってるでしょ?

819 :nobodyさん:2007/09/28(金) 14:27:29 ID:???
普通に配列で戻ってきた方が使いやすいんだが。関数の豊富さにもあらわれているようにPHPは配列多様言語だから

820 :nobodyさん:2007/09/28(金) 15:42:35 ID:???
結果は配列でいいよな
オブジェクトにするにしてもほとんど単なるValueObjectだろう

821 :nobodyさん:2007/09/28(金) 21:06:07 ID:???
配列ってのは間違い。ハッシュってのが正解。

だってさ、配列といったら俺でも不便に思うけど、
それは a[0] ・・・これがID、 a[1] ・・・これがタイトルという風に
インデックス番号でしかアクセスできないからでしょ?
もちろん実際はそんなことは無く、名前でアクセスできるわけで。

それからCakePHPの話だが、Modelの中のデータが配列で格納されているだけであって、
Model自体はクラスだよ。

822 :nobodyさん:2007/09/28(金) 21:17:02 ID:???
連想配列は配列の一種だろ
自分だけの定義で話をすんな

823 :nobodyさん:2007/09/28(金) 21:37:50 ID:???
> ハッシュってのが正解。

まったくの不正解。

824 :nobodyさん:2007/09/28(金) 22:00:36 ID:???
連想配列と配列は他の言語ではまったくの別物。
それをわかっていない奴がいる。

825 :nobodyさん:2007/09/28(金) 22:10:49 ID:???
えっ、どこにどこに?

826 :nobodyさん:2007/09/28(金) 22:17:06 ID:???
なんで他の言語が出てくるんだよw
要するに峻別できるもんじゃねーんだよ
それをとりあげて正解だ不正解だいってるお前の頭が不正解


827 :nobodyさん:2007/09/28(金) 22:34:12 ID:???
連想配列と配列の区別が無い言語ってPHPだけだと思うが?

828 :nobodyさん:2007/09/28(金) 22:38:46 ID:???
フレームワークを使おうが使うまいが、
気の利くUIを、動作調整しながら丁寧に作ってたりすると、
それだけで一日くらいすぐ経っちゃう。

829 :nobodyさん:2007/09/28(金) 22:50:35 ID:???
>>827
そうでもないよ

830 :nobodyさん:2007/09/28(金) 23:17:57 ID:???
へぇ。だったらその言語言ってみせてよ。

831 :nobodyさん:2007/09/28(金) 23:33:18 ID:???
話がそれてるよ
話の主旨は「配列なのか連想配列なのか」ではなく
「(連想)配列なのかオブジェクトなのか」だろ?


array_map() とか使える配列もなかなか便利だけど
メソッド定義で拡張できるオブジェクトの方が潰しが利くと個人的には思う.

>>813みたいな例でいうと
後で必要になる形式のデータを配列作成時に全部生成しておくより,
必要に応じてメソッド呼んで使う時に使うデータを生成するって方が
個人的には好みだ.

832 :nobodyさん:2007/09/29(土) 00:03:46 ID:???
だから、Model内部が連想配列になっているだけで、
Model自体はオブジェクトだってw

833 :nobodyさん:2007/09/29(土) 00:04:04 ID:???
この場合 array_map とかが便利な状況ってあまりない気がするが、
どんな使い方が考えられるんだろうか。

834 :nobodyさん:2007/09/29(土) 00:26:51 ID:???
強引なのは承知だが、PHPにおいては、
配列≒連想配列≒≒≒≒≒オブジェクト
でいいじゃん
聞いててもつまらん話題だ

835 :nobodyさん:2007/09/29(土) 00:32:17 ID:???
連想配列で十分なときは連想配列を使う。
オブジェクトが必要ならオブジェクトを使う。
PHPでオブジェクト(クラス)が使えないとでも思っているの?

836 :nobodyさん:2007/09/29(土) 00:43:09 ID:???
> 連想配列で十分なときは連想配列を使う。
> オブジェクトが必要ならオブジェクトを使う。

なかなかインテリジェントなORMだな。

837 :nobodyさん:2007/09/29(土) 00:49:31 ID:???
ORMの話していたのかw
CakePHPの場合はModelはオブジェクトだね。
だからなに?って感じなんだが。

838 :nobodyさん:2007/09/29(土) 01:40:05 ID:???
これCakeより簡単そうだなあ。
ttp://d.riaf.org/rhacosns000
>>690-702あたりでも出てたようだけど誰か使ってる人居る?

839 :nobodyさん:2007/09/29(土) 02:27:38 ID:???
使っている人いない。Googleの検索数が今の10倍になってから出直してね。

840 :nobodyさん:2007/09/29(土) 17:51:34 ID:???
rhacoに限らず、やはりドキュメントが揃ってないと使い辛いよね。

841 :nobodyさん:2007/09/29(土) 22:14:50 ID:???
http://cakephp.seesaa.net/article/53564832.html

間もなくCake本登場!!
今日のPHPカンファレンスで安藤さんが発表されていると思うので、ここら辺で発表・・・。

世界に先駆けて?CakePHPフレームワークの解説本を出すことになりました。

CakePHPの紹介
Cakeに特徴的な、モデルの使い方詳説
コントローラ、ビューについても解説
PHPプログラミングで必要とされるセキュリティの知識、CakePHP流に実現する方法
Ajaxの隅から隅まで

マイコミ出版から、10月に出版される"予定"です

842 :nobodyさん:2007/09/30(日) 08:54:43 ID:???
Ethnaあたりでもういいだろ

843 :nobodyさん:2007/09/30(日) 13:03:56 ID:???
>>842
確かにあの妥協さ加減は、テロっとWeb制作するにはちょうどいいよな。

844 :nobodyさん:2007/09/30(日) 13:43:07 ID:???
データベースを使わないようなウェブサービス → Ethna
データベースを使う大規模なウェブサービス → CakePHP

こんな感じか。

あと個人的にはどうしても世界レベルではやっているもので
なければ使いたくないな。

845 :nobodyさん:2007/09/30(日) 14:36:51 ID:???
Ethnaって世界レベル?


846 :nobodyさん:2007/09/30(日) 14:43:18 ID:H/GK0oDX
データベースを使わないWebサービスなんて・・・

847 :nobodyさん:2007/09/30(日) 14:44:39 ID:???
>>844
>世界レベルではやっているもの
それはそれでマルチバイト圏が割と忘れ去られているという罠もありえるしな。微妙。

848 :nobodyさん:2007/09/30(日) 14:50:05 ID:???
英語圏のものでも
utf8があたりまえになりつつあるから、
昔より敷居は低くなってるんじゃないかな
ま、utf8ですべて解決とは言わないが

849 :nobodyさん:2007/09/30(日) 17:38:06 ID:???
>>847
世界レベルといったろー。
マルチバイト圏も当然含まれる。

EthnaはEUC-JPが前提
中国語とかやばい。

850 :nobodyさん:2007/09/30(日) 18:17:40 ID:???
>>847 ではないが
当然とか言われてもなー
気持ちはわからんでもないが
世界レベルって言い方は曖昧なんだよ


851 :nobodyさん:2007/09/30(日) 19:51:06 ID:???
世界レベル(笑)

852 :nobodyさん:2007/09/30(日) 20:37:44 ID:???
Cakeってソース見ると、クラクラするほど汚いのになぜ流行るんだろう?

853 :nobodyさん:2007/09/30(日) 20:42:04 ID:???
PHPerがバカばっかりだからだよ

854 :nobodyさん:2007/09/30(日) 21:55:19 ID:???
ソースが汚くてもフレームワーク自体を改造するわけじゃないから、
便利に使えればOKっていうやつがおおいからだろ?

855 :nobodyさん:2007/09/30(日) 22:09:39 ID:???
ピーエイチパー?

856 :nobodyさん:2007/09/30(日) 22:35:08 ID:???
ぺちぱー

857 :nobodyさん:2007/09/30(日) 22:48:34 ID:???
国産のMoonyとか言うフレーム発見したが既出?

858 :nobodyさん:2007/10/01(月) 00:21:21 ID:???
cakeは見たことないがソース汚かったらそれだけで使う気は失せるな

859 :nobodyさん:2007/10/01(月) 03:32:13 ID:???
汚いのなら、直せば良いだろ。
オープンソースなんだから。

860 :nobodyさん:2007/10/01(月) 10:45:26 ID:???
結論:PEARで十分

861 :nobodyさん:2007/10/01(月) 12:11:22 ID:???
>>852
たぶん、Railsゆずり。
RailsはRubyの強力過ぎるリフレクションでどうにかまとまっているようにも見えるが、
PHPで書くとなんだかRailsの悪いとこだけコピったような感じになる。


862 :nobodyさん:2007/10/01(月) 12:43:06 ID:???
>>861
具体的に言うと?

Railsでリフレクションの機能は当然使っているだろうが、
それでも、最低限の機能しか使っていないと思うんだが。

863 :nobodyさん:2007/10/01(月) 13:50:18 ID:???
>>862
え、ソース読んだことある?
とくにActiveRecordの宣言チックに機能追加する部分はほとんどリフレクションのはず
module_eval とか instance_eval とか method_missing とかで検索するといい。
こいつらのいで、機能の定義場所が追えないことが良くある。


864 :nobodyさん:2007/10/01(月) 14:22:27 ID:???
>>863
いやね。何がいいたいかと言うと、一言で言うと、
それのどこが「強力すぎるリフレクション」なの? ということ。

たとえば、CakePHPなら、model->findBy○○(△△)で
データベースの○○フィールドが△△のものを検索とかね。
もちろん、findBy○○メソッドが定義されているわけじゃない。
実行時にメソッド名からフィールド名を取り出して検索している。

そのレベルのリフレクションなら、ほとんどのオブジェクト指向言語にあるよ。
無いのは純粋なC++ぐらいかな。

865 :nobodyさん:2007/10/01(月) 14:44:34 ID:???
メソッドがないってことは
ideの自動補完も使えないってことか
そんなのいらねー(#・д・)、ペッ

866 :nobodyさん:2007/10/01(月) 14:55:00 ID:???
>>864
なんでそこに突っかかるのかよくわからんけど、PHPと比較しての話でしょ?
それにその程度というが、module_evalなんかはたとえばJavaでは難しかろうと思うが


867 :nobodyさん:2007/10/01(月) 14:57:15 ID:???
Ruby強力すぎるリフレクションを持っていると聞いて
?と思っただけだが。

868 :nobodyさん:2007/10/01(月) 15:04:13 ID:???
PHP5.3で名前空間実装でRuby脂肪www

869 :nobodyさん:2007/10/01(月) 15:05:36 ID:???
スクリプトが走ってる最中に動的に
メソッド定義そのものを書き換えられるなんて
rubyの強力な機能以外の何者でもないと思うが
で、それは同時に諸刃でもある

リフレクションは自身の定義の読み取りだけじゃなく書き換えもある
phpは読み取りのリフレクションは備えてるけど
メソッドを直接書き換えたりはできない、せいぜい__callで頑張るくらい

870 :nobodyさん:2007/10/01(月) 15:06:37 ID:???
module_eval見たいな奴がある言語って他にあるの? メジャー系で。
ほいほいオブジェクトのメソッドを上書きできるのってあんまり見ない気が。
メソッドの型とか一覧とかにアクセス出来るだけならたくさんあるけど。


871 :nobodyさん:2007/10/01(月) 15:10:30 ID:???
PHPもPECL使えば、メソッド書き換えできるよ。

872 :nobodyさん:2007/10/01(月) 15:37:55 ID:???
runkit見てみた。
なかなか面白いね。とくにSandboxを作るのは面白い。

言語仕様に組み込めないのはしかたないとして、
実験室レベルから成長する日は果して来るか...
こいつをバリバリ使ったRails級のキラーアプリとか、ないよね。


873 :nobodyさん:2007/10/01(月) 15:52:39 ID:???
面白いだろうけど、書き換えられまくれるのもそれはそれで問題あるしな
結局言語内仕様じゃない1拡張なんだから
その書き換えに発生するコストも高くつくだろうし

railsから参考になる部分はいっぱいあるけど
phpはphpで言語内仕様でサポートする範囲内で
使いやすいようなFW作ればいいと思う

874 :nobodyさん:2007/10/01(月) 21:26:30 ID:???
Rubyが実行時にメソッド書き換えができるのはわかったが、
それをRailsで使いまくっているのか?

っていうか、ここはPHPスレ。Ruby厨はカエレ!

875 :nobodyさん:2007/10/01(月) 21:54:05 ID:???
Rubyも自動補完ほとんど効かないの?
そんな言語使う人いんの?

876 :nobodyさん:2007/10/01(月) 22:07:19 ID:???
guessworkの中の人のブログに載ってたこれでPython勧められた
http://dame.dyndns.org/misc/llahp/
ちなみにPHPのおすすめされ度は最下位w
PHPとはお別れします
アデュー( ´_`)丿☆

877 :nobodyさん:2007/10/01(月) 23:14:56 ID:???
>>875
ゆとりかw
昔はIDEなんてなかったんだぞ

878 :nobodyさん:2007/10/02(火) 09:40:46 ID:???
>>874
2chで名無しにどう言われても信用できないだろ?

だからRailsのソースを読め
そしてインスタンスのmethod_missingとかを実行時に書き換えるのを見れ。
ARのアソシエーションはたいていそうやって見かけの便利メソッドを増やしてる。
あとはaliasで既存のメソッドをコピった後に同名のメソッドを追加するとか。


879 :nobodyさん:2007/10/02(火) 16:09:37 ID:???
ここはPHPスレなんだから、PHP使いのレベルに合わせないと・・・

880 :nobodyさん:2007/10/02(火) 18:07:27 ID:???
DBから引いてくるデータでオブジェクトだと便利なのはせいぜいDATE型のカラムくらいで、他はオブジェクトである必要はない。

881 :nobodyさん:2007/10/02(火) 18:11:04 ID:???
配列つっこんでおけば取り出す時にオブジェクト化してくれるファクトリ書けば
万事解決

882 :nobodyさん:2007/10/03(水) 01:06:22 ID:???
>>878
> ARのアソシエーションはたいていそうやって見かけの便利メソッドを増やしてる。
> あとはaliasで既存のメソッドをコピった後に同名のメソッドを追加するとか。

うん。Rubyすごいね。PHPでも同じことできるけどねw

さっさとRubyスレに帰れよw

883 :nobodyさん:2007/10/03(水) 07:11:11 ID:???
>>882
まて、インスタンスにはできんぞ
上に出てたrunkitを使わんと。

884 :nobodyさん:2007/10/03(水) 11:00:16 ID:???
>>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クラスは何かって? 少し、考えてくれw
それらしい答えが出なかったら夕方にでもうpするよ。

885 :nobodyさん:2007/10/03(水) 11:23:42 ID:???
わかってないのにもったいつけなくてもいいよ

886 :nobodyさん:2007/10/03(水) 12:02:22 ID:???
わかってない ということにしたい理由はなに? ほんとうにわかってないのは(ry

887 :nobodyさん:2007/10/03(水) 16:58:14 ID:???
>>884
インスタンス変数を使ってインスタンスの振舞を変更するのは
あたりまえじゃぁないすか?
そのためにインスタンス変数ってあるもんだし。

できるかできんかで言えば、C言語でオブジェクト指向で書くことはできるし、
実際そういうのは結構あるわけで。


888 :nobodyさん:2007/10/03(水) 17:24:00 ID:???
>>884 激しくダサいな・・・

889 :nobodyさん:2007/10/03(水) 17:37:57 ID:???
>>888
なぜ?

890 :nobodyさん:2007/10/03(水) 17:42:29 ID:???
>>887
あのさぁ。出来るか出来ないかの話を吹っかけておいてさ、
「出来るけど、(その後なんて言いたいのか知らん)」と
言い訳するのやめてくんない?

そんなこというなら、最初っから出来ないなんて大口たたかないで、
「出来るけど、(その後なんて言いたいのか知らん)」と言えという話。

でなんて言いたいのさ、出来るけど時間がかかる? コード書くのが手間?
一度書けば、それで終わりだよね。

891 :884:2007/10/03(水) 17:48:34 ID:???
rubyの擁護ってわけじゃないけど、
ARのリレーションで実行時に書き換えるインスタンスはクラスオブジェクトそのものだとおもうよ。
ARクラスをnewしたオブジェクトじゃなく。
だから>>884の例はARを実装してるRubyの機能をPHPで実現できた証明には弱いと思う。

なにか見えない大きな敵に向かっているようだけど
おれはこの流れで>>887が最初の発言

まぁ、喧嘩腰にならずに
なかよくやろうや。


892 :887:2007/10/03(水) 17:51:24 ID:???
ごめん名前欄まちがえた


893 :nobodyさん:2007/10/03(水) 18:12:43 ID:???
>>891
でもさ、たとえ内部の仕組みが違ったとしても、
それで出来ることと同じことが、同じ程度の手間で
PHPででも実現できるわけだよ。

出来ないと言うのなら、具体的にどんなことが出来ないのか示してほしいね。

894 :nobodyさん:2007/10/03(水) 18:20:54 ID:???
クラス定義の中でクラス関数を呼んで、
そのクラス関数が自分自身のクラスを書き換える、とか?

でも最初はRailsはrubyのリフレクション使いまくりで読みにくいという
話だったはずだけど、いつのまに出来る出来ないという話がでたわけだろうか。
話の流れに関係ない煽りにのせられてないかい?


895 :nobodyさん:2007/10/03(水) 18:37:47 ID:???
rubyはfastcgiなんて不安定なものを使わないと行けないって時点で相当ポイント低いよな。
phpやperlならcgiでもそこそこ動くけど、rubyはfastcgiなしじゃ話にならない。

896 :nobodyさん:2007/10/03(水) 18:58:11 ID:???
オープンソースで作る場合、rubyは選択しづらいな。
rubyが動く環境が少なすぎる。
それらの環境を切り捨てるほどの理由が見つからない。

897 :nobodyさん:2007/10/03(水) 19:55:05 ID:???
JRubyでRailsの.warファイルをJBossとかにデプロイしてイェーイという話も
実運用の話はまだ聞かないしね。Sunはどんだけ本気なのかしらんけど。

898 :nobodyさん:2007/10/03(水) 20:50:42 ID:L+I4Rl+L
最近、PHPを勉強し始めました。
もし、いろいろアドバイスしてくださる方が居れば、こちらへ宜しくお願いします。
http://php121.blog121.fc2.com/

899 :nobodyさん:2007/10/03(水) 21:58:15 ID:???
アドバイスしねーよwww つか宣伝すんな。

900 :nobodyさん:2007/10/03(水) 22:11:57 ID:???
>>898
嘘ばっか教えてやります

901 :nobodyさん:2007/10/03(水) 23:14:02 ID:???
おまいらのレベルの低さに絶望した

902 :nobodyさん:2007/10/04(木) 01:08:40 ID:???
http://japan.zdnet.com/security/story/0,3800079245,20357867,00.htm
なりすまされてRuby脂肪www

903 :nobodyさん:2007/10/04(木) 01:20:43 ID:???
それぐらいで死んでたらPHPなんてもうないじゃんw

904 :nobodyさん:2007/10/04(木) 06:22:51 ID:???
それで死ぬならWindowsもLinuxもとっくに滅びてるなw

905 :nobodyさん:2007/10/04(木) 12:20:13 ID:???
女子中学生がプログラミング勉強ブログを書いていたら、全力でレスしていたはずのスレはここですか?


906 :nobodyさん:2007/10/04(木) 17:55:29 ID:???
ちがいます。女児の間違いです。

907 :nobodyさん:2007/10/06(土) 13:08:07 ID:???
いいえ70歳のお婆ちゃんです

908 :nobodyさん:2007/10/07(日) 14:40:52 ID:???
>>884
includeClass()ってどう書くの?
すごく興味あるんだけど。

909 :nobodyさん:2007/10/07(日) 15:49:45 ID:???
//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;
  }
}


910 :nobodyさん:2007/10/09(火) 04:38:27 ID:???
PHPフレームワーカーはどんなPC使ってますか?
メーカー製PCは、妙に高いし、
自作機作るのも調査が大変だしで
迷ってます

911 :nobodyさん:2007/10/09(火) 07:56:16 ID:???
>>910
CPUはCore2Duoで
メモリ2Gくらい積んでりゃ、
なんだって良いさwww


912 :nobodyさん:2007/10/09(火) 08:17:06 ID:???
PHP専用PCきぼんぬ

913 :nobodyさん:2007/10/09(火) 08:38:12 ID:???
>>912
目の前にあるPCにテプラで「PHP専用」って貼っておけ。

914 :nobodyさん:2007/10/09(火) 15:49:17 ID:???
テプラ買うか・・

915 :nobodyさん:2007/10/09(火) 16:06:16 ID:???
PHPしか走らず、他の言語、特にRubyが走ったら爆発するPCがいいの!(><)

916 :nobodyさん:2007/10/09(火) 21:19:20 ID:???
>>915
PHPしか使えないようにした1CD Linuxでもセットアップしなよ。

917 :いつも全力レス:2007/10/10(水) 00:49:04 ID:???
メーカー製でも安いPCはあるよ
http://akiba.kakaku.com/shop/0710/03/220000.php
【タワー型サーバ】日本HP「HP ProLiant ML115(Athlon64 3500+搭載モデル)」 17,800円

ある程度予算があるなら、DELLのOpteron搭載サーバがいいと思います。
=はてなとかでも使っている

自作するなら、マザーボードはSuperMicroにするのが良いと思います。

918 :nobodyさん:2007/10/10(水) 01:03:33 ID:???
>>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

919 :nobodyさん:2007/10/10(水) 01:10:14 ID:???
「Mint」というオリジナルのフレームワークを作っている方がいました。
http://aqut.jp/php/doc/mint/about.htm

ちいたんみたいに手軽に使えるでしょうか?

920 :nobodyさん:2007/10/10(水) 01:34:02 ID:???
Zendがさっさと安定したバージョン出せば
バカみたいにPHPフレームワークが乱立することは無くなるのに

921 :nobodyさん:2007/10/10(水) 01:36:34 ID:???
>>917
市販のPCケースより安いってどんだけ

922 :nobodyさん:2007/10/10(水) 04:07:20 ID:???
zendはポストpearって感じ

923 :nobodyさん:2007/10/10(水) 10:16:54 ID:???
>>919
自分で使ってみてレポしろよ・・・

924 :nobodyさん:2007/10/10(水) 13:44:10 ID:???
>>920
ZendがPHP4切捨てだから
フレームワークの乱立は収まらない

925 :nobodyさん:2007/10/10(水) 13:48:14 ID:???
4切り捨てとか当然だろ
いつまで4使うつもりだよ

926 :nobodyさん:2007/10/10(水) 15:19:06 ID:???
> 4切り捨てとか当然だろ
> いつまで4使うつもりだよ

うん? レンタルサーバーからPHP4が無くなるまでだけど。


927 :nobodyさん:2007/10/10(水) 15:30:48 ID:???
>>925
鯖ごと納めたシステムが使われなくなるまでwww

928 :nobodyさん:2007/10/10(水) 15:45:09 ID:???
>>925は5だけでやってんの?
自社物onlyか、趣味でやってるだけ?

929 :nobodyさん:2007/10/10(水) 16:30:12 ID:???
>>928
>>925じゃないが、新規案件はもう5だな。
レンサバで動かすとか4じゃなきゃダメならしょうがないけどさ。



930 :nobodyさん:2007/10/10(水) 17:09:40 ID:???
べつに乱立自体は構わないんじゃない?
なんか困ることある?

>>920は単に本家のお墨つきがついた良いフレームワークがないことが不満なだけのような気がするが。


931 :nobodyさん:2007/10/10(水) 17:54:54 ID:???
PHP4のリファレンスの説明って分かりにくいよな・・・
リファレンスのリファレンスを渡したら
ポインタのポインタみたいになるかと思ってずっと避けてた(><)

932 :nobodyさん:2007/10/10(水) 18:46:31 ID:???
つうかリファレンスは糞

933 :nobodyさん:2007/10/11(木) 01:51:19 ID:???
PHPは名前の付け方がアホなんだよ。リファレンスもそうだし、オーバーロードとかも。一般的な言語の知識があると混乱するだけ。

934 :nobodyさん:2007/10/11(木) 06:03:05 ID:???
pu-he-po-

935 :nobodyさん:2007/10/11(木) 10:56:38 ID:???
>>933
リファレンスもオーバーロードも一般的な意味だと思いますが

936 :nobodyさん:2007/10/11(木) 11:12:08 ID:???
>>935
んじゃ>>933に頭の良い名前の付け方を教えてもらおう。
「リファレンス」→「」
「オーバーロード」→「」

はい、お願いします。

937 :nobodyさん:2007/10/11(木) 11:38:26 ID:???
リファレンスは
ショートカットやポインタとは違うことを明確に示すために
アナザーネームでいいんじゃね

938 :nobodyさん:2007/10/11(木) 11:57:13 ID:???
ショートカット (´゚д゚`)!
アナザーネーム (´゚д゚`)!

939 :nobodyさん:2007/10/11(木) 12:48:25 ID:???
すれ違い

940 :nobodyさん:2007/10/12(金) 00:46:00 ID:???
mixinはrhaco

941 :nobodyさん:2007/10/12(金) 16:26:37 ID:???
別窓で開かれたページから、別窓を開く前のページへ値は渡せますか??

管理画面のボタンを押すと別窓を開き、別窓に表示されたサムネイルを選択すると管理画面に反映されるという仕組みです。


942 :nobodyさん:2007/10/12(金) 16:40:50 ID:???
>>941
スレ違い
つJavascript

943 :nobodyさん:2007/10/12(金) 16:54:23 ID:???
ありがとうございます

944 :nobodyさん:2007/10/12(金) 23:16:08 ID:???
>>936
PHPのリファレンスは参照じゃなくて別名。エイリアスとかハードリンクとか言うべき物。
PHPのオーバーロードは、普通の言語のメソッドオーバーロードとか演算子オーバーロードじゃなくって、Perlのオートロードみたいな物。
JavaとかC++とかの一般的な言語の知識しかない人がPHPのマニュアル読んだら確実に混乱するだろう。

945 :nobodyさん:2007/10/12(金) 23:22:51 ID:???
>>944
フレームワークの話をしていただきたい

946 :nobodyさん:2007/10/13(土) 04:26:15 ID:???
小さなサイトだからと生書きで書き始めたが
後から一括処理を追加するのが面倒に・・・
ちいたんくらい使っておけばよかったか

947 :nobodyさん:2007/10/13(土) 11:51:41 ID:???
フレームワークで構築したサイト久しぶりに見たら見通し悪すぎワロタ

948 :nobodyさん:2007/10/13(土) 12:24:33 ID:???
>>947
なんのフレームワークだ?
うまく使えば逆に見通しはいいはずだが。

949 :nobodyさん:2007/10/13(土) 14:36:35 ID:???
フレームワークの構造そのものを忘れたら何使っても大抵は見通し悪いわな

950 :nobodyさん:2007/10/13(土) 16:26:23 ID:???
>>944
PHPのリファレンスは、C++由来の参照だよ。
オーバーロードがPerlのオートロードだとか意味不明だが、おそらくマニュアルに
> __call, __get そして __set メソッドを通してオーバーロードすることができます。
と書いてあるのを読み違えてるんじゃないか?

>>949
MVC的な発想で作ってれば、多少は構造を忘れても、けっこう簡単に把握できると思う。

951 :nobodyさん:2007/10/13(土) 17:02:46 ID:???
>>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に来た人は
マニュアルを読んで単語の使い方に混乱する人が居てもおかしくはないと思う

952 :nobodyさん:2007/10/13(土) 21:05:25 ID:???
オーバーロードを何故実装しないのかな

953 :nobodyさん:2007/10/13(土) 21:18:34 ID:???
>>952
弱い型付けの言語で実装してるの知らないけどあるの?

954 :nobodyさん:2007/10/13(土) 22:03:02 ID:???
普通の言語
一般的な言語
の定義が曖昧です。

955 :nobodyさん:2007/10/13(土) 23:41:08 ID:???
ペチパーはこれだから。

956 :nobodyさん:2007/10/14(日) 00:34:36 ID:???
agavi 0.11RC6リリース
http://www.agavi.org/

957 :nobodyさん:2007/10/14(日) 01:00:58 ID:???
>>952
> オーバーロードを何故実装しないのかな
(C++風の)オーバーロードを実装しないのは
実装するまでもないからじゃね?

オーバーロードをなぜ使いたいかというと、
一つの関数をいろんな型、個数の引数で呼び出したいからなわけだけど、
PHPでは普通にいろんな型、個数で呼び出せるでしょ?

958 :nobodyさん:2007/10/14(日) 01:03:48 ID:???
Perlは演算子オーバーロードできる。

959 :nobodyさん:2007/10/14(日) 01:45:54 ID:???
演算子オーバロードは邪悪。必要ない。

960 :nobodyさん:2007/10/14(日) 09:23:01 ID:???
演算子オーバーロードにせよ、メソッドオーバーロードにせよ、実装しないのは実装が大変なのが理由だろうな。
特に演算子オーバーロードできれば言語仕様のコアな部分をユーザが修正できるわけだけど、この実装はかなり難しいだろう。

961 :nobodyさん:2007/10/14(日) 09:24:56 ID:???
Perlの場合、メソッドオーバーライドはやりようがない。そもそも仮引数を明示しないから。

962 :nobodyさん:2007/10/14(日) 09:26:23 ID:???
間違えた。↑メソッドオーバーロードだ。

963 :nobodyさん:2007/10/14(日) 10:15:54 ID:???
phpの場合も引数というのは、
最低保障引数であってそれ以上の引数をつけても
呼び出せるし、もちろん関数からその引数を操作できるわけで。

(つまりfoo($value)というメソッドをfoo(1,2,3)という引数で
呼び出せてfunc_get_args()で2,3の引数にアクセスできる)

メソッドオーバーロードを実装するまでもなく、
それ相当のことができるわけさ。

メソッドオーバーロードは型あり言語では必須の機能かもしれないが、
型なし言語なら無くても同じことができるから必要なし。

演算子オーバーロードはねぇ。
あれ、Javaでも可読性が悪くなるという理由でサポートしないと明言されたような機能だし。

964 :nobodyさん:2007/10/14(日) 13:27:47 ID:???
PHPでメソッドオーバーロード的なことをしようと思うと、メソッド内部で引数を数えてIFで切り分けて他のメソッドに委譲するだとかの汚いコードを書かないといけない。


965 :nobodyさん:2007/10/14(日) 13:28:37 ID:???
そういう泥臭いコードを書かないで済むようにメソッドオーバーロードがある。

966 :nobodyさん:2007/10/14(日) 13:37:57 ID:???
演算子オーバーロードは黒魔術的で、乱発すれば可読性が落ちるのは確か。
スクリプト言語の場合、厳密さより効率を優先する場合が多く、ライブラリのソース自体を目で追えるわけだから、演算子オーバーロードがあって困ることはない。
実際、RubyやPtyhonも演算子オーバーロードできる。

967 :nobodyさん:2007/10/14(日) 13:41:17 ID:???
Ptyhonじゃなくって、Pythonだったな。
そもそもPHPの実装って非常に未熟な感じがする。3項演算子が左結合なのも実装技術が低いから以外に理由が浮かばないし。

968 :nobodyさん:2007/10/14(日) 15:08:00 ID:???
>>967
お前また来たのか
実装技術が低いPHPのスレになんざ来ないでRuby様に遊んでもらってろよ

969 :nobodyさん:2007/10/14(日) 15:16:14 ID:???
>>951以外の、リファレンスとオーバーロードについての指摘はずっと俺が書き込んでたんだが。

970 :nobodyさん:2007/10/14(日) 15:17:40 ID:???
最近はPHPからプログラミングを始めて、PHPしかやったことがない人が多すぎる。
だから、PHPのリファレンスやオーバーロードが世間からずれてることに気づかない。

971 :nobodyさん:2007/10/14(日) 17:07:28 ID:???
PHP言語について語るなアホども

972 :nobodyさん:2007/10/14(日) 18:25:57 ID:???
>>964
> PHPでメソッドオーバーロード的なことをしようと思うと、
> メソッド内部で引数を数えてIFで切り分けて他のメソッドに委譲するだとかの汚いコードを書かないといけない。

おいおい。オーバーロードする場合、名前は同じなんだぞ。
同じ名前でまったく違う処理をすることなんて、ほぼないんだから、
結局は他のメソッドに委譲することになるだろ。

あと引数を数える必要も、普通は無いな。
そういう場合は、表略可能な引数で対応する。

つまり、型無し言語でオーバーロードなんていらないってわけだ。

973 :nobodyさん:2007/10/14(日) 22:42:19 ID:???
convet($scalar)とconvret($array)で使い分けるとか。引数を調べないといけないケースはいくらでもある。


974 :nobodyさん:2007/10/14(日) 22:43:17 ID:???
↑convert()だった

975 :nobodyさん:2007/10/15(月) 00:12:02 ID:???
>>973
それでも、調べた後の処理は共通だろ?
その例だと、スカラーなら要素数1の配列に変換するだけ。
C++のオーバーロードであっても、一般的には同じように要素数1の配列に変換した後、
配列版の関数に委譲するだろ?(もしくは逆に配列を一個一個取り出して非配列版の関数に委譲する)

オーバーロードってのは、違う処理だけど名前は同じにしたい!
じゃあ引数で区別できれば便利じゃね? という発想から生まれたものじゃなく、

処理はほとんど同じだけど、違う型でも扱えるようにしたい。
でも宣言は一つの型しか受け付けられない。別の名前は作りたくない。
という問題から生まれたものさ。

ゆえに、もとから違う型でも扱える、型なし言語ではほとんど無意味。

976 :nobodyさん:2007/10/15(月) 00:17:56 ID:???
おまいらスレタイ完全無視してるよな
いいかげんにしろ


977 :nobodyさん:2007/10/15(月) 02:10:37 ID:???
まずオーバーロードってメソッドオーバーロードのことな。
PHPのオーバーロードと混同するからな。PHPがオーバーロードなんて混乱しやすい名前付けたのがアホなんだけど。
現実にはメソッドオーバーロードが有効なケースは多くある。convert()というメソッドがスカラー変数を引数にとって、コンバートされたスカラー変数を返すようなAPIだったとして、
後から一括でコンバートするようなメソッドを追加するとき、convert()の仮引数を配列に、返り値を配列に変えないといけない。
もちろんis_array()で引数や返り値を調べて処理を分岐することは可能だけど、それじゃあ美しくないという感覚。この感覚がないなら、前提がまるで違うわけで話にならない。
それとPHP(に限らず大抵の言語)は型はあるから。PHPは動的に変化するだけで。is_array()やis_int()で仮引数を調べることはよくあること。

978 :nobodyさん:2007/10/15(月) 02:57:30 ID:???
異なる処理に同じメソッド名を使う時点で美しいとは思えないがな

979 :nobodyさん:2007/10/15(月) 13:39:13 ID:???
オーバーロードの話してるやつは他に行けと言ってるのが分からんのか?

980 :nobodyさん:2007/10/15(月) 15:20:08 ID:???
2chでスレ違いスレ違い言う奴もうざい
そんなこと言っても何も変わりゃしねーから何も言わないでいい

981 :nobodyさん:2007/10/15(月) 16:54:46 ID:???
Zendがフレームワークの本命って言われるのかが気になってしょうがない。
pearの再開発にMVCくっつけたライブラリ集にしかなってなくね?

982 :nobodyさん:2007/10/15(月) 22:24:14 ID:???
PHPフレームワークの作成は、サードパーティが頑張ってくれているから、Zendは早くPHP6をリリースした方がええんとちゃうの?

983 :nobodyさん:2007/10/15(月) 22:24:48 ID:???
>978

984 :nobodyさん:2007/10/16(火) 13:27:56 ID:???
>>982
に賛成

985 :nobodyさん:2007/10/16(火) 13:54:22 ID:???
日本のZendはただの代理店だからな。
提灯記事をあちこちに載せてマーケティングをがんばってるんだろうけど、
ド素人じゃあるまいし、それに乗せられる奴もいないわな(www

986 :nobodyさん:2007/10/16(火) 15:33:31 ID:???
そろそろ次スレの季節

987 :nobodyさん:2007/10/16(火) 15:45:45 ID:???
あと1ヶ月は持つべ

988 :nobodyさん:2007/10/16(火) 16:41:12 ID:???
http://livepipe.net/projects/picora/
Rails風。
名前がかわいい。

989 :nobodyさん:2007/10/16(火) 19:14:23 ID:???
oppaiとかの方がかわいい

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

991 :nobodyさん:2007/10/16(火) 19:32:35 ID:???
>>990
MVCを理解してくれ

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

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


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

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

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

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

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


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

996 :nobodyさん:2007/10/17(水) 15:46:31 ID:???
vとcを1ファイルにするくらいならvとmじゃね?

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

998 :nobodyさん:2007/10/17(水) 15:58:53 ID:???
おまいらギリギリまで会話かw
次スレを早くぅ

999 :nobodyさん:2007/10/17(水) 16:02:55 ID:???
続きはこちら
http://pc11.2ch.net/test/read.cgi/php/1192604501/

1000 :nobodyさん:2007/10/17(水) 16:03:16 ID:???
おれが1000ゲット

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

207 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)