トップページ⇒php
1001コメント324KB

【PHP】フレームワーク CakePHP　3ホール目【本命】

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2008/03/14(金) 15:16:00ID:HF9x5ODX
http://www.cakephp.org/

10分で作るCakePHPアプリ for Windows
http://p4life.jp/cake/

マニュアル日本語化
http://www.cakephp.jp/doc/

日本語フォーラム
http://cakephp.jp/modules/newbb/

あとこのへんとか（初心者向けTIPS）
http://www.avatarfinancial.com/pages/cake/

CakePHP入門リンク集
ttp://pub.studio15.jp/2007/11/13/cakephp-links/

【PHP】フレームワーク CakePHP　2ホール目
http://pc11.2ch.net/test/read.cgi/php/1194976228/
【PHP】フレームワーク CakePHP
http://pc11.2ch.net/test/read.cgi/php/1163850802/
0412nobodyさん2008/03/28(金) 11:10:07ID:???
アンチを勘違いしてると思うが
いい質問には、マナーをもって接するが
ろくでもないレスばっかりだからな
0413nobodyさん2008/03/28(金) 11:13:12ID:???
>>411
自治厨乙。
だいたいにして、IDなんていつでも変えれるんだから意味ないじゃん。
0414nobodyさん2008/03/28(金) 11:14:01ID:???
ろくでもないレスは無視するかマナーをもって
訂正を促すのが良い返答の仕方だよ。
0415nobodyさん2008/03/28(金) 11:14:44ID:q/btZ3WH
>>413
やってみなきゃわからないじゃんｗ
0416nobodyさん2008/03/28(金) 11:17:51ID:???
>>415
どんだけ必死なんだよｗ
0417nobodyさん2008/03/28(金) 11:57:59ID:anJTbKap
>>409
もちろん速度を重視しなくてはならない場面ならば専用メソッド内でSQLを書きます
しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
フレームワーク自体に手を出して最適化させた方がコスト的にベターかなと思います

>>403
複雑なアソシエーションのパターンが出来上がってる時はView使った方がいいですね
今ふと考え付いたのですが、結合済みの仮想テーブルを作って、それを元に
CakePHP側のモデルを構築するアプローチは面白いかもしれません

#仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
0418nobodyさん2008/03/28(金) 12:20:53ID:???
>>417
負荷を考えるならフレームワークやめろ
CakePHPなんてのは、どうでもいいクライアントに高速納品するための道具てことに気づけよバカ
0419nobodyさん2008/03/28(金) 12:26:48ID:???
>>417
今頃フレームワークの評価とか手を出すとか、どんだけ遅れてんだよ
この業界は進歩が早いの知ってる？
0420nobodyさん2008/03/28(金) 12:43:39ID:???
>>417
> 結合済みの仮想テーブルを作って、それを元にCakePHP側のモデルを構築する
view作ればって言ったのはそういうこと。
面白いかどうかはおいといて、現状の打開策としてはアリかなと思うわけです。

> 仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
このDB依存は仕方ないと割り切ればいいんじゃないかな。割り切れるところだと思うし。
0421nobodyさん2008/03/28(金) 12:49:51ID:???
>>417
やる前にあれこれ聞かずにやってみろよ
こんなとこで解決できれば苦労しねーよクソが
0422nobodyさん2008/03/28(金) 12:53:20ID:???
評価なんてソース解析して自分で実際にサイト構築しないとわからねーよ
やってくうちに想像しない難点が沢山でてくるよ

0423nobodyさん2008/03/28(金) 13:01:42ID:???
>>417
速度重視とか柔軟性考えるならＣＩにしろや
0424nobodyさん2008/03/28(金) 13:04:47ID:???
CakePHPを最適化させにくいフレームワーク
最適化したいならＣＩスレにいって、このスレからでていけや
0425nobodyさん2008/03/28(金) 13:28:19ID:???
>>420
0426nobodyさん2008/03/28(金) 13:34:05ID:???
っていうかJOINにならないというのは
どのフレームワークでも同じこと。
CIでもSymfonyでもRubyOnRailsでも同じだよ。

特にCIは最悪だね。いろんな意味で。
ここではすれ違いだから言わないけど。
0427nobodyさん2008/03/28(金) 13:40:13ID:???
>>426
どのフレームワークも同じなら軽量でサクサク動作するＣＩの方がマシ
0428nobodyさん2008/03/28(金) 13:44:02ID:???
>>417
> しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると

シンプルではないよ。

CakePHPでもその他でもそうだけどO/Rマッピングというのは
従来の表形式の使いづらいリレーショナルデータベースを
高レベルに扱いやすく使えるようにするもの。

リレーショナルデータベースを基本に設計されたものではなく
より理想的なオブジェクト指向風なデータ構造をもとに設計されたもの。
だからいろんな取り出し方ができる出来る柔軟性がある。

たとえば、behaviorでデータ挿入・取り出し時に色んな処理をかませられる。

そういう柔軟性を持たせながらシンプルなSQLに置き換えるのは容易ではない。
不可能な場合すらある。

なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること。一日働いて3万円人件費をかけるのなら、
その3万円でスペックをあげたほうが総合的に考えてメリットが
高いという時代だから、今は。
0429nobodyさん2008/03/28(金) 13:50:03ID:???
CIはデータベースを使わない。使う頻度が少ない場合にはいいけど、
データベースを使う場合、貧弱だよな。

あれならSQL直書きした方がいいってほどメソッドがアホらしいしｗ
なによりビヘイビアが無いのが一番痛い。
0430nobodyさん2008/03/28(金) 13:50:47ID:???
>>428
なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること

サイトリニューアルなど
既存ユーザーが多数いる自社製品ならパフォーマンスを意識する

0431nobodyさん2008/03/28(金) 13:52:21ID:???
> 既存ユーザーが多数いる自社製品ならパフォーマンスを意識する
マシンスペックを上げろ
0432nobodyさん2008/03/28(金) 13:54:32ID:???
>>429
複雑なアソシエーションはＳＱＬ直書きになるんならＣＩが理にかなってる

0433nobodyさん2008/03/28(金) 13:55:17ID:???
複雑なものじゃなくてシンプルにしようと考えような。
0434nobodyさん2008/03/28(金) 13:55:42ID:???
>>426
symfony(というかpropel)はJOINになる
0435nobodyさん2008/03/28(金) 13:56:08ID:???
>>431
ユーザーが増えるたびに、どんだけマシンが必要になるんだよ
0436nobodyさん2008/03/28(金) 13:56:12ID:???
JOIN使わないで一回一回よんでも
パフォーマンスはたいして変わんないんだけどなｗ
0437nobodyさん2008/03/28(金) 13:57:04ID:???
>>435
ユーザーが増えると重くなるのはどれでも一緒ですが？

働いていない人は、人件費というコストを計算に入れないからなぁｗ
まあ、がんばれやｗ
0438nobodyさん2008/03/28(金) 13:57:54ID:???
>>436
変わるよ　あほか
0439nobodyさん2008/03/28(金) 13:57:57ID:???
ＳＱＬ直書きになる機会が多いならＣＩがいい
0440nobodyさん2008/03/28(金) 13:58:21ID:???
O/Rというのはリレーショナルデータベースからの
脱却に意味があるというのに、今時SQLなんて低レベルなことやるかよｗ
0441nobodyさん2008/03/28(金) 13:58:54ID:???
>>437
ずっと開発してるわけじゃねーからｗ
人件費とか１回ぽっきりやん
0442nobodyさん2008/03/28(金) 14:00:15ID:???
複雑なＳＱＬならＯ/Rマッピング使えないじゃん
今のＣａｋｅＰＨＰなら
だったらＣＩでＳＱＬ直書きが最高よ
0443nobodyさん2008/03/28(金) 14:03:25ID:???
>>437
重くなりかたが異なってくるんですが？

1回で済む処理を2回のクエリで行ってるとアクセス数が増えたときにクエリ発行数が大きく変わることがわかんない？
ほんとにプログラマなのか？まぁ、がんばれや
0444nobodyさん2008/03/28(金) 14:05:37ID:???
ぷｗ 頭固いな。mixiの話とかしらんのかいな

mixiでは”高負荷に耐えるためにJOINを使っていない”んだよ。

http://www.google.co.jp/search?hl=ja&rlz=1T4GGIH_jaJP221JP221&q=MIXI+MYSQL+JOIN+%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3&lr=

0445nobodyさん2008/03/28(金) 14:07:29ID:???
>>442
使えていますが？ JOINが使われないってだけでしょうが。

パフォーマンスに問題が無い場所で、
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHPと、
SQLを書くのと同等の手間をかけなければならないCIでは
どちらが優れているかは言うまでも無く、CakePHPですね。
0446nobodyさん2008/03/28(金) 14:08:18ID:???
>>441
マシンスペックを上げるのも一回ぽっきりですが？
0447nobodyさん2008/03/28(金) 14:09:13ID:???
ビヘイビアがない時点でCIは糞ｗ
0448nobodyさん2008/03/28(金) 14:11:24ID:???
>>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP

group byとかどうやんの？
0449nobodyさん2008/03/28(金) 14:12:45ID:???
>>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP

この発言無理がありすぎやろｗ
0450nobodyさん2008/03/28(金) 14:13:42ID:???
>>444
あのさ、読解力なさすぎ。
「高負荷に耐えるためにJOINを使っていない」とは書いてない。
0451nobodyさん2008/03/28(金) 14:14:14ID:???
結局アンチはいつものCI厨だったなｗ
0452nobodyさん2008/03/28(金) 14:15:24ID:???
>>450
ではJOINを使わない理由になんて書いていますか？言ってみてください。
0453nobodyさん2008/03/28(金) 14:17:30ID:???
>>452
スケールするためにデータベースを分割し、JOINが使用できなくなったから。
0454nobodyさん2008/03/28(金) 14:20:13ID:???
スケールとはパフォーマンスをあげるということです。
0455nobodyさん2008/03/28(金) 14:21:44ID:???
うん。だから？
0456nobodyさん2008/03/28(金) 14:22:38ID:???
>>455
おまえの負けてことだよ
0457nobodyさん2008/03/28(金) 14:24:15ID:???
>>456
あからさまにバカだな。論理的に考えられないんだな。
0458nobodyさん2008/03/28(金) 14:24:38ID:???
>>447
1.1使ってる人は真性なる糞ですね
0459nobodyさん2008/03/28(金) 14:25:14ID:???
高負荷に耐えられるパフォーマンスを作り出す為に、
データベースを分割してJOINが使用できなくなった。

負荷を考えるのなら、JOINなんかするより、
マシンに投資してデータベースを分割（当然マシンも増えているはず）して
アプリケーションで行ったほうがいいということです。
0460nobodyさん2008/03/28(金) 14:28:55ID:???
>>457
さっきまでパフォーマンスの話してたやろうが
論理的な会話してないのお前だろｗ
0461nobodyさん2008/03/28(金) 14:31:33ID:???
結局ＣＩが最強てことじゃんか
0462nobodyさん2008/03/28(金) 14:37:17ID:???
CIはフレームワークを使っているとは思えないほど開発工数がかかる。

データベース部分は、SQLの単語（selectやfromやwhere）を
それぞれメソッドに置き換えて実行しないといけない。
なんとビックリｗ

だから糞。
0463nobodyさん2008/03/28(金) 14:38:23ID:???
わろたｗ

$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);

$query = $this->db->get();
0464nobodyさん2008/03/28(金) 14:38:41ID:???
>>459
ただ、「マシンに投資してデータベースを分割（当然マシンも増えているはず）して」が始めからできるわけじゃないんだよね。
だからSQL発行数も含め、パフォーマンスには常に気を遣うわけで。
mixiが今はソフトウェア側でパフォーマンスを気にしてないかっていったらそんなことはないし。

>>460
パフォーマンスの話してるよ。何言ってんの？
もう面倒だからお前いいよ。
0465nobodyさん2008/03/28(金) 14:40:13ID:???
だからパフォーマンスを重視するところだけ
最適化して、あとは楽で速いコーディングをすればいいじゃんか。

パフォーマンスの基礎だよ？
0466nobodyさん2008/03/28(金) 14:41:27ID:???
>>463
これいいね。わかりやすい構文だ
CakePHPの
find(null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,)
これに比べれば天と地に差
0467nobodyさん2008/03/28(金) 14:42:45ID:???
>>466
引数の数を勝手に増やすなｗ

最後の引数の意味言ってみろよ。
いえなければ赤っ恥だなｗ
0468nobodyさん2008/03/28(金) 14:42:48ID:???
>>464
おまえ誰だよ？トリップでも番号でもいいから付けろよｗ
0469nobodyさん2008/03/28(金) 14:44:26ID:???
>>463はPHP4だと
$this->db->select('title');
$this->db->from('mytable');
$this->db->where('id', $id)
$this->db->limit(10, 20);
こうなります。
0470nobodyさん2008/03/28(金) 14:45:17ID:???
>>464
名無しで必死にレスしてるようだが
名前に番号でもつけてくれないと
今までどんな発言してんかわかんないんだがｗ
0471nobodyさん2008/03/28(金) 14:46:08ID:???
>>468
どうせトリップつけさせて削除しようって魂胆だろ。
そんな手に引っかかるか。ばーかｗ
0472nobodyさん2008/03/28(金) 14:46:42ID:???
>>469
わかりやすくていいね、さすがＣＩ
ヌルヌルフレームワークとは大違い
0473sage2008/03/28(金) 14:50:37ID:JUQ1v1x2
$this->flash で出てくるはずのページがIE6だと表示されん。ソースは吐かれてる。
ってことはUTF関係か。
0474nobodyさん2008/03/28(金) 14:50:44ID:???
アンチレス繰り返してたら、えらい盛り上がってきた
04754252008/03/28(金) 14:54:55ID:???
すみません、途中投稿しました

>>420
その通りですね。同一アプリケーション内でDBをスイッチする事はありえないので
リスクとしては小さいため十分検討できます(一応、PostgreSQL使ってる方は注意です)

>>424
CodeIgniterもとてもいいフレームワークだと思います
ぜひその情熱で当該スレッドを活性化させて盛り上げて欲しいですね

>>428
確かにアソシエーションの自動判別が面倒(無理)という事情は分かります
面倒なSQLを叩かずオブジェクティブにデータセットを取得できる機能が
すでに実装されていているのですからそれを使うに越した事はありません
この辺りの実装はアプリケーション全体のパフォーマンスに影響するため
サーバ増設前の改良を十分に検討できる部分だと思います
0476nobodyさん2008/03/28(金) 14:54:59ID:???
実はアンチを煽って盛り上げさせているというのはナイショだｗ
見ろ他フレームワーク（特にCI）の静けさを！
0477nobodyさん2008/03/28(金) 14:56:44ID:???
>>469みたいなコードを書くぐらいなら
SQLをそのまま書いたほうがいいな。
0478nobodyさん2008/03/28(金) 15:06:18ID:???
>>428
すみません
>>475の説明はちょっと意味不明ですね、スルー推奨です
0479nobodyさん2008/03/28(金) 15:45:01ID:???
Ｃａｋｅは糞
0480nobodyさん2008/03/28(金) 15:54:32ID:???
aki(ryが本出してるから糞
0481nobodyさん2008/03/29(土) 07:40:57ID:???
あの本は確かに糞だったな
0482nobodyさん2008/03/29(土) 09:07:16ID:???
あれは本当に酷かった
0483nobodyさん2008/03/29(土) 15:28:58ID:???
文句だけは達者だな
0484nobodyさん2008/03/29(土) 15:56:30ID:???
達者？
0485nobodyさん2008/03/29(土) 16:10:19ID:???
このスレはいつも無駄に盛り上がるよな
0486nobodyさん2008/03/29(土) 16:54:04ID:???
>>484
ゆとり乙
0487nobodyさん2008/03/29(土) 17:43:56ID:???
>>486
ゆとり乙
0488nobodyさん2008/03/29(土) 20:03:50ID:???
>>486
ゆとり乙
0489nobodyさん2008/03/29(土) 22:04:16ID:t2qvxoud
CakePHPっていいフレームワークだよな
0490nobodyさん2008/03/29(土) 22:08:25ID:???
ソース汚いけどな
0491nobodyさん2008/03/29(土) 22:15:25ID:???
最高のフレームワークだね
完璧すぎる
0492nobodyさん2008/03/29(土) 22:29:55ID:???
おまいらマインドマップ使ってる？
0493nobodyさん2008/03/29(土) 22:57:31ID:???
30才過ぎるとマインドマップ使わないと
トイレ行った後とか今まで何考えてたかさえ忘れる
0494nobodyさん2008/03/29(土) 23:43:43ID:VJRoSuRr
なんでマインドマップの話になったか分からないけど、自宅と会社のＰＣに
ＦｒｅｅＭｉｎｄインストール済み。

自宅ではCakePHPのシステム設計に使ってる。
ひとつずつやる事片付けて、終わったブランチに「レ」のアイコン付けるのが
楽しい。
0495nobodyさん2008/03/30(日) 02:14:14ID:???
ＵＭＬはルール化した図解表現
マインドマップは自由な図解表現
0496nobodyさん2008/03/30(日) 02:16:24ID:???
マインドマップで設計し形になったものをＵＭＬ化する
0497nobodyさん2008/03/30(日) 02:17:48ID:xhO/sY7i
んで、UMLで書いた仕様書を投げ捨ててウンコする
0498nobodyさん2008/03/30(日) 02:19:35ID:???
CakePHP使ってればUMLもマインドマップも必要ない
0499nobodyさん2008/03/30(日) 02:26:47ID:???
作業途中に仕様的にやばい匂いがしたらマインドマップ使ってる
0500nobodyさん2008/03/30(日) 02:31:49ID:???
問題を解決しやすい方法として
思ったことを、どんどん言葉として書き出す
わかってるからと頭の中でしまいこむと、全体的な解決図を結び付きにくくする
0501nobodyさん2008/03/30(日) 02:45:33ID:???
難しい状況を言語化する能力がコミュニケーション能力での重要ポイントだと思う。
もっと言語化するクセつければ、コミュニケーション能力向上になるんじゃないかな
0502nobodyさん2008/03/30(日) 17:27:12ID:???
render呼んだ後
すぐexit();
してる？
0503nobodyさん2008/03/30(日) 20:27:27ID:3z+xm+ln
>>473
遅レスだが、ソースの頭にBOMを付けたら表示されるようになた。
が、viewのファイルは8Nで保存しておかないと、たまに悪さをするようだ。
0504nobodyさん2008/03/30(日) 22:06:44ID:???
>>502
もっと常識的な質問たのむ
0505nobodyさん2008/03/31(月) 10:30:36ID:???
>>502
してないよ
0506nobodyさん2008/03/31(月) 10:59:21ID:???
>>505
コンポーネントでrenderを呼んだときは
exitしないとデフォルトのrenderが最後に読み込まれるよ
0507nobodyさん2008/03/31(月) 11:00:31ID:???
cakePHPのテスト環境だけど
SeleniumとSimpleTestの組み合わせが最強？
0508nobodyさん2008/04/01(火) 01:26:52ID:j0Vrw1hD
>>507
そっちのテストなら、ｾﾚﾆｳﾑだろうと手作業だろうとなんだって良くね？

ユニットテストをするのなら1.2から正式対応したSimpleTestって言うだろうけど。

ていうか、テスト駆動開発って面倒ですよね、時間がかかるけど出来上がり安定するのは確かだけど。
0509nobodyさん2008/04/01(火) 01:34:29ID:???
正確にはテスト駆動じゃないけど、
ある程度の規模になったら、ユニットテストをやらないなんて
考えられないよ。

修正があるたびに同じテストなんてやってられない。
それこそ時間がかかる。
0510nobodyさん2008/04/01(火) 02:09:46ID:???
Selenium IDE これいいね。これだけでも同じテストする必要がないし
なんといってもテストが楽
0511nobodyさん2008/04/01(火) 12:33:08ID:???
Yahooが占いコンテンツ制作にCakePHPを採用
■ このスレッドは過去ログ倉庫に格納されています