【PHP】フレームワーク CakePHP 3ホール目【本命】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2008/03/14(金) 15:16:00ID:HF9x5ODX10分で作る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/
0207nobodyさん
2008/03/19(水) 22:11:32ID:???何を言っているんだ？
自分のレベルが低いと告白しているのか？
0209nobodyさん
2008/03/19(水) 23:03:06ID:XOo5uLlV返信ありがとうございます。
> コントローラのアクションでUserモデルからデータを引っ張ってくる
> アソシエーションによりCommentもくっついてくる。
なるほど。
きちんとリレーションを設定すれば、コントローラ側ではUserモデル
からデータを引っ張るだけで、芋づる式にcommentsを取れるんですね。
> ビューは渡されたデータをぐるぐるして表示する。
今、$usersをforeachで回してる状態なんですが、これを$usersと
$commentsの二重ループにすればオッケーですかね。
ちょっとやってみます。
>>206
論点がずれてませんか？
そもそも、具体的なアクセス数、H/Wの規模を示さないと意味のない
指摘じゃないでしょうか。
この方法だと中規模以上に向かないから、この方法を使うといいよ、
と言うのならまだ分かるのですが。
0210nobodyさん
2008/03/19(水) 23:13:10ID:???>>208
お前らのcakeはこの時どういったクエリが発行されんの？
select ... from users ... (id 1,3,5のユーザがヒットする)
select ... from comments where user_id in (1) ...
select ... from comments where user_id in (3) ...
select ... from comments where user_id in (5) ...
0211nobodyさん
2008/03/19(水) 23:28:29ID:???そして、この findAll() で実行された SQL は以下の通り。
SELECT `Job`.`id`, `Job`.`com_id`, `Job`.`name`
FROM `jobs` AS `Job` LEFT JOIN `coms` AS `Com` ON `Job`.`com_id` = `Com`.`id`
WHERE 1 = 1 ORDER BY `Job`.`id` ASC LIMIT 10;
0212nobodyさん
2008/03/19(水) 23:42:19ID:???参照の方向が違う。
0213nobodyさん
2008/03/20(木) 00:12:41ID:???hasmanyとかconditionsにどういうSQLで
JOINするかをSQLの断片で書いているしなぁ。
JOINしているとわかりそうなものだがなぁ。
0214nobodyさん
2008/03/20(木) 00:28:36ID:???結局「表示するユーザ数+1のクエリが発行される」が間違ってることは示せないんでしょ。
実際やってみてクエリログ見ればすぐ分かるはずなんだが。
0216nobodyさん
2008/03/20(木) 00:40:19ID:???その代わり複雑なＳＱＬ文を書かないといけないから
CakePHPの負荷よりも生産性というスタイルに合わないがな
ループの中でクエリをぐるぐる発行しまくると負荷が高くなる
0217nobodyさん
2008/03/20(木) 00:43:11ID:???結局こういうのが出てくるのか・・・
ほんとバカばっかだなー
それじゃ論点がどうずれてるか説明もらってもいい？
210での発言にphpの基礎は全く関係ないから、それのほうが論点ずれてると思うのだが。
んで、実際お前のcakeではこの処理でどういうクエリが発行されんの？
0219nobodyさん
2008/03/20(木) 00:52:19ID:???とてつもなく負荷の高いシステムがたくさん世に出そうだな
こりゃサーバー会社が儲かるな
sakuraインターネット株でも買うか！
0220nobodyさん
2008/03/20(木) 05:31:17ID:???柔軟な制御ができん、
ページリンクに検索項目のパラメーター付加できない、というか
できるけど、面倒なことしないとダメくさい
ソート項目のパラメータは標準で付加できるようだが
0221209
2008/03/20(木) 10:56:59ID:mwRuCB98私の技術力だと、二重ループ以外に実現する方法が思いつかないのですが、
他によい方法があったら教えてもらえますか？
ユーザ毎のコメントを表示する機能はパスするにしても、
同様にmasManyリレーションのテーブルを親子両方とも表示したい
機会はあると思うので。
負荷という意味では、masManyの定義でlimit=>10とする事で大量の子を
取得しないように、というのは心がけています。
0223nobodyさん
2008/03/20(木) 12:36:12ID:???データを取得することが
負荷が高いと思っているのかな？
JOINの方がよっぽど負荷高いですぜ。
0224nobodyさん
2008/03/20(木) 12:40:34ID:???0225nobodyさん
2008/03/20(木) 12:58:50ID:???> お前らのcakeはこの時どういったクエリが発行されんの？
こういうクエリが発行されますがなにか？
select ... from users ... (id 1,3,5のユーザがヒットする)
select ... from comments where user_id in (1, 3, 5 ) ...
0226nobodyさん
2008/03/20(木) 13:35:31ID:???自分の性格に合わない気がしてきた
0227nobodyさん
2008/03/20(木) 13:39:58ID:???CakePHPはメモリも食わないし、負荷も高くない。
生産性は高い。
0228nobodyさん
2008/03/20(木) 13:40:43ID:???1.ページ送りの絞り込み条件パラメータをセッションで持たせている
2.ページ送りの絞り込み条件パラメータをURLの後ろに繋げてる(CakePHP1.1 paginate)
3.ページ送りの絞り込み条件パラメータをURLの後ろに繋げてる(CakePHP1.2 pagination)
0229nobodyさん
2008/03/20(木) 13:45:28ID:???4. 基本は3と同じだが、場合によってpagination等をオーバーライドして独自の条件を追加している。
0231nobodyさん
2008/03/20(木) 13:45:54ID:???たしかに、
●自分の用途に合わせて、全てのコードとHTMLを一から作成したシステム
●作り込み部分は最小限にして、大半のコードはcakePHP任せにしたシステム
を比べると、負荷は、一から作成したシステムの方が、余分なものがない分、
軽くできるかもね。
まあそこはトレードオフの部分だから、自分に向いてないと思ったら、
cakePHP以外のやり方を模索すればいいと思うよ。
0233nobodyさん
2008/03/20(木) 13:49:21ID:???どこでもフレームワークを使っている。
0234nobodyさん
2008/03/20(木) 13:50:32ID:???View側で
$paginator->prev()
$paginator->next()
の第２引数に絞り込み条件を配列で入れてやら無いと
URLの後ろにパラメーターが付加されてなくない？
http://localhost/cake/test/index/page:1/parameta:hogehoge
みたいなかんじ
0235nobodyさん
2008/03/20(木) 13:55:14ID:???いまソースが手元に無くて忘れたが、CakePHP1.2でかなり改善された。
そういえば、そういうパラメータを”コントローラ”側で追加していたきもする。
コントローラーのpagination変数だったっけ？
pagination[モデル名]だっけ？
まあわすれた。
0236nobodyさん
2008/03/20(木) 13:55:53ID:???どちらかと言うと、「負荷が高いシステム」と言うより、
「大規模なシステム」はフレームワークを使ってるという感じじゃない？
そうしないと、コーディングや保守が大変だもんなあ。
0237nobodyさん
2008/03/20(木) 14:03:35ID:???生産性重視で高級言語（フレームワーク）で書くかの話でしかないな
0238nobodyさん
2008/03/20(木) 14:07:42ID:???CakePHPは小規模フレームワークのクセにsymfonyと同レベルくらい負荷かかりすぎ
0240nobodyさん
2008/03/20(木) 14:15:07ID:???0242nobodyさん
2008/03/20(木) 14:18:04ID:???http://www.tsujita.jp/blojsom/blog/default/PHP/2007/07/13/PHP%E3%83%99%E3%83%B3%E3%83%81%E3%83%9E%E3%83%BC%E3%82%AF-Zend-Framework-vs-Symfony-vs-CakePHP-vs-CodeIgniter-vs-PHP-on-TRAX.html
0243nobodyさん
2008/03/20(木) 14:20:54ID:???一番重要なモデルが貧弱すぎる。中規模以上ならCakePHPだな。
http://blogs.atanaka.biz/tanaka/index.php?itemid=691
・フレームワークにありがちな、あまり使わない機能が削がれている
・フレームワークにありがちな、よく使う機能もけっこう削がれている。
・だから、ステップ数が他のPHPフレームワークと比べて格段に少ない。
・だから、実行速度が速い。（ベンチマークはこちら）
・フレームワーク自体が複雑なことをしようとしていないので、潜在バグの深刻さも小さい。（たぶん）
・マニュアルがかなり読みやすく、取っつきやすい。
・cakePHPには名前のインパクトには負ける。
・ZendFramework には格式の高さで負ける。
・MVCというよりは、VCだ。モデルはあくまでもおまけ的。
・PHPがそもそもテンプレート的なんだからテンプレートエンジンいらない、と考えているふしあり。（だから速い、と）
・でも、簡単な変数置き換えの簡易テンプレートはデフォルトでついてるし、Smartyとの連携もできる。
0244nobodyさん
2008/03/20(木) 14:22:14ID:???[PHP][フレームワーク]CodeIgniterスレ
http://pc11.2ch.net/test/read.cgi/php/1177683436/
0245nobodyさん
2008/03/20(木) 14:25:59ID:???モデルはCIベースでオレオレ的に拡張した方がいい。
CakePHPの既存モデルにしっくり来ないから
まずコードが凄く見難い状態になる
結局バリデートにYAML使ったりと拡張しないいけない
0246nobodyさん
2008/03/20(木) 14:27:28ID:???中規模 CakePHP
大規模 Symfony
これでいいじゃん
0247nobodyさん
2008/03/20(木) 14:29:19ID:???中規模 CI
大規模 ここまできたらCIでいいや
0248nobodyさん
2008/03/20(木) 14:31:12ID:???0250nobodyさん
2008/03/20(木) 14:36:52ID:???$paginator->options(array('url'=>'hogehoge'))
controllerでpaginate(モデル)した後のoptionsにセットしてもurlに展開される
$this->params['paging'][モデル]['options']['hogeoge_key']='hogeoge_value'
*この方法は裏技的な気がするけど、、、
0252nobodyさん
2008/03/20(木) 14:40:57ID:???わざわざCakePHPスレを盛り上げて乙
0253nobodyさん
2008/03/20(木) 14:46:46ID:???最初は機能が少なくて、バージョンがあがるにつれて機能が追加され最終的には重くなるんだよな。
で、ほかと同等の機能を備えたときには、ほかと同等の重さになっている。
0254nobodyさん
2008/03/20(木) 15:00:55ID:???使ってる方、どうぞ書き込んで下さい。
http://pc11.2ch.net/test/read.cgi/php/1177683436/l50
0255nobodyさん
2008/03/20(木) 15:11:51ID:???0256nobodyさん
2008/03/20(木) 15:33:39ID:???hasManyアソシエーションでlimitを指定しないと確かに225のクエリになる。
ソース読んだらそのためのif文があった。これは知らなかった。サンクス
limit指定しないのが普通なのか・・・あと、なんでそういう実装にしてるんだろう。
limitでUserの件数絞るとしてもwhere user_id (1,3,5)はできると思うのだが。
0257nobodyさん
2008/03/20(木) 15:35:10ID:???> limitでUserの件数絞るとしても
limitでCommentの件数絞るとしても
0259nobodyさん
2008/03/20(木) 15:42:19ID:???バカじゃん俺。この振る舞いについてのドキュメントはどっかにあったのかな。
連投スマソ。
0260nobodyさん
2008/03/21(金) 01:06:38ID:???コントローラーにこんな感じで書こうと思うのですがどうでしょうか。
start transaction
$resultA = $modelA ->method();
if($resultA == 'error')
{
rollback
return;
}
$resultB = $modelB ->method();
if($resultB == 'error')
{
rollback
return;
}
$resultC = $modelC ->method();
if($resultC == 'error')
{
rollback
return;
}
commit
0262nobodyさん
2008/03/21(金) 11:15:08ID:???0263nobodyさん
2008/03/21(金) 11:28:48ID:???0264nobodyさん
2008/03/21(金) 22:38:30ID:???0265nobodyさん
2008/03/22(土) 02:17:57ID:rTbTxKR5コントローラにはあまり詳細な処理は書きたくない（つまり、大まかな流れだけ）ので、
具体的な処理はコンポーネントをこさえて、そちらで処理したいんだけど考え方あってるかな？
たとえば、会員登録処理をするアプリを例にすると、UserRegisterComponentみたいなのを作って
identify()やregister()、update()といったモデルを扱う処理を記述して、
コントローラーからはフォームの値の受け取りとコンポーネントをコネコネ使うこと、結果によって
ビューを表示しわけるようなイメージです。
ソース書いて晒した方が早い？
0266nobodyさん
2008/03/22(土) 03:46:35ID:???> コントローラにはあまり詳細な処理は書きたくない
> 具体的な処理はコンポーネントをこさえて、そちらで処理したい
大事なのはこれらの明確な理由が何なのかってことだと思う。
その会員登録処理がシステムの他の部分からも必要になるならコンポーネントにした方がいいと思うよ。
もしくは他のアプリでも(ほぼ)そのまま使用できるなら。
あとはコントローラとモデル(DAO層)を分離することでテスタビリティを向上させたいとかかなぁ
例えばテストの時はモックコンポーネント使うようにすればデータベースがなくてもコントローラのテストができる。
0267265
2008/03/22(土) 05:08:43ID:rTbTxKR5なるほど。コンポーネントで会員登録処理と思いついた理由は指摘のとおり他のアプリで
いつも同様のことを実装してるのでコンポーネント化してしまおうというのが一番の理由。
それにコントローラ内に細かい条件分岐や処理を書き始めるとものすごくコードが肥大して
メンテナンスがし難いし、もし今後会員登録のフローを同アプリケーションの別箇所でも使い
たいって仕様変更があっても対応しやすいかと。
でも、「会員登録（管理）コンポーネント」なんて作っちゃうとモデルやDBテーブルの構造が
かなり固定化＆依存してしまうのがいやだなだ、と…（AuthComponentみたいにね）
それならばpluginにしちゃえば？って考えることもあるけど、pluginってあんまり使われてないし。
うーむ。
0269nobodyさん
2008/03/22(土) 10:19:47ID:???DBテーブルの構造がかなり固定化＆依存
これ内容が会員登録だったらテーブル構造に依存しちゃうのやばいだろ？
会員認証なら固定依存しても、それほど問題ないけど
コンポーネントてそもそもDBテーブルの構造がかなり固定化＆依存してしまうものなんだね
0270nobodyさん
2008/03/22(土) 10:52:32ID:???コンポーネント設計のポイントは、Plug-and-Playを可能にすることであり、独立性を高めることにある
重要となる設計要素は、インターフェースであり、注目すべきは設計要素間の依存関係だと思う
内部実装に依存しない形でコラボレーションをモデル化できるインターフェースが重要じゃないかな
コンポーネント化するということは、結局クラスをグループ化することだからね
クラス間の関連（集合-部分、汎化-特化）と依存関係を意識して設計しないと
物理的にはコンポーネント化したが、論理的にはひとつのシステム全体
ひとつの再利用単位として使わざるを得ないという状況が現れるから
この点で、依存関係の設計はかなり重要
0271nobodyさん
2008/03/22(土) 11:26:27ID:???モックコンポーネント
あまり聞かない、組み合わせだけどｗ
モックとコンポーネント入れ替えするものじゃないの？
0272nobodyさん
2008/03/22(土) 11:49:52ID:???0273nobodyさん
2008/03/22(土) 19:56:20ID:rTbTxKR5「配布できる」と書いてあるくせに、プラグイン配布サイトって見たことないやと思って。
「会員登録プラグイン」とかあるといいのになー
会員登録コンポーネントの件、結局ユーザーテーブルを分けて（users:ログインIDとパスワードだけ、user_profiles:その他のプロフィール項目）
コンポーネントで固定化するのはusersテーブルを主にして、user_profilesの方はアプリケーション毎に
自由に定義できるような仕様でコンポーネントを書いてみようかと思っています。
0274nobodyさん
2008/03/22(土) 20:52:09ID:???そういうこと。テストの時はモックを使うようにする。
「コンポーネントのモック」って意味でモックコンポーネントって言った。
0275nobodyさん
2008/03/22(土) 21:01:00ID:???会員登録プラグイン
何度も使うような処理でも無いし面倒な処理でもないからなあ
個人的には確認画面やらページ送りやら何度も使う場面のあるプラグインもしくは
コンポーネントが欲しい
0276nobodyさん
2008/03/23(日) 01:31:09ID:???yamlの空白に少しはまった
0278nobodyさん
2008/03/23(日) 12:24:28ID:???ファンクションはありますか？ イメージとしてはこんな感じで。
$this->Post->hogehoge($id, 'Address'->'Hokkaido');
Model classのファンクションを一通り眺めてみたのですが、
それらしきファンクションを見つける事ができませんでした。
http://api.cakephp.org/class_model.html#d25735e5d69a1c55c58de6df8c06bd9e
0280278
2008/03/23(日) 13:46:28ID:9wMqWTzf先に挙げたURLで、「Public Member Functions」と記述されていたので、
ファンクションと書かせてもらいました。
methodと言えばいいですか？
既存のものでいうと、findAllやsaveなどの事です。
ご存じでしたらお教え下さい。
0282nobodyさん
2008/03/23(日) 21:00:13ID:xiSCrZA7会員登録プラグイン、完成したら俺にくれ
0284nobodyさん
2008/03/23(日) 23:07:41ID:???カラム単位の更新でいいなら、saveField。
$this->Post->id = $id;
$this->Post->saveField('Address', 'Hokkaido');
0285nobodyさん
2008/03/23(日) 23:25:30ID:???小さい車輪だろうが再開発をしなくて済むなら助かる。
0286nobodyさん
2008/03/24(月) 00:14:26ID:???そうじゃなければ、すでに作ってる人たくさんいるよ
0287nobodyさん
2008/03/24(月) 00:19:02ID:???スルー推奨。
しばらく前、本やWebを参考にRoRを使っていたが、cakePHPの方が
使いやすい。
ひょっとしたら、RoRでActiveRecordとかに若干慣れたので、
馴染みやすかっただけかもしんないけど。
0288nobodyさん
2008/03/24(月) 00:22:17ID:gAnd/HKbなんのためにプラ銀機能なんて実装されてんの？
0289nobodyさん
2008/03/24(月) 03:29:33ID:???0290nobodyさん
2008/03/24(月) 03:37:25ID:???会員登録ページのメソッドにアクセスしてるにもかかわらず
コントローラでPaginationコンポーネントを定義していれば
ページ処理の関わるクラスがnewされるんでしょ
0291nobodyさん
2008/03/24(月) 13:06:37ID:???コンポーネントやモデルはヘルパーに比べればメソッド単位で呼び出しやすいけど
こっちも深く考えずにコントローラ単位で呼び出すんだ
多分
0292nobodyさん
2008/03/24(月) 13:16:08ID:???function gugurekasu() {
App::import('Helper', 'Hoge');
$ajax = new HogeHelper();
}
0293nobodyさん
2008/03/24(月) 20:55:32ID:???ヘルパーとか呼び出したいのなら、
そういうコンポーネントを作ればいいんじゃないのかな？
コンストラクタあたりで、url見てごにゃごちゃすれば出来るでしょう？
0296nobodyさん
2008/03/25(火) 10:30:40ID:Qe2AafnSだからといってコントローラにごちゃごちゃとロジックを書き並べたくないので
コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます。
これって俺だけ？
0297nobodyさん
2008/03/25(火) 10:37:30ID:???まずいケーキだってケーキ様が言っている。
http://cakephp.org/files/OCPHP.pdf
0298nobodyさん
2008/03/25(火) 10:46:51ID:???ケーキがどうのこうのいおうが
自分の見やすい書き方が一番
たとえば１万step以下のコードなら
全部コントローラに書いた方がいい、みたいなね！
0299nobodyさん
2008/03/25(火) 10:55:58ID:Qe2AafnS3ページ目？ こんなにモデルに書くもんかね…
俺だったらｃとｍの間のコンポーネントをずっしり書くな。別のプロジェクトにも使いまわしできるし。
コントローラだとほぼ、使いまわせないしな。
0300nobodyさん
2008/03/25(火) 11:02:26ID:???0301nobodyさん
2008/03/25(火) 11:05:24ID:???コントローラに関する再利用性の高いメソッドはコンポーネント
モデルに関する再利用性の高いメソッドはビヘイビア
再利用性が高いロジックじゃないとダメ
そのロジックがコントローラ側かモデル側かどっちに属するかを間違えるとダメ
0305nobodyさん
2008/03/25(火) 11:13:20ID:Qe2AafnS0306nobodyさん
2008/03/25(火) 11:14:25ID:???コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます
これダメだろ？再利用性の高さとか無視してるやん
0307nobodyさん
2008/03/25(火) 11:17:23ID:???それだけでもオワッテルｗ
■ このスレッドは過去ログ倉庫に格納されています