【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/
0334nobodyさん
2008/03/26(水) 03:51:47ID:???0336nobodyさん
2008/03/26(水) 04:38:16ID:pkIggipTシーケンス図やクラス図なんかどんな風に記述してるかとか見せてもらえると
参考になります。
0337nobodyさん
2008/03/26(水) 04:51:55ID:???UMLを使うと従来の方法より効率が落ちる時もある。
なぜなら、従来なら手書きで適当に書いてきた図をUMLでどうやって書けばいいのか調べなければならないから。
書き方が全部頭の中に入った後でなら従来よりスムーズに開発ができるようになるかもしれない
が、しかし、それまでは相当の苦労が必要ｗ
オブジェクト指向開発とUMLとはまた別の話でUMLはオブジェクト指向開発の道具にすぎない
0339nobodyさん
2008/03/26(水) 05:04:03ID:???そんなクラスが複雑じゃないやん
0340nobodyさん
2008/03/26(水) 05:24:25ID:???0342nobodyさん
2008/03/26(水) 10:50:05ID:???だがそれは個人の話であって統計的な意味は無い。
検索結果のほうがまだ意味があるな
PHP UML の検索結果 約 957,000 件中 1 - 10 件目 (0.03 秒)
Java UML の検索結果 約 593,000 件中 1 - 10 件目 (0.04 秒)
C# UML の検索結果 約 404,000 件中 1 - 10 件目 (0.04 秒)
0343nobodyさん
2008/03/26(水) 11:29:28ID:???0344nobodyさん
2008/03/26(水) 11:31:39ID:???0346nobodyさん
2008/03/26(水) 11:58:29ID:???複雑になってくるクラス間の関連性の構造の手助けとしてＵＭＬを活用することが多い
だから>>339のいってるように複雑なクラスで無ければ必ずしもＵＭＬが必要とは思わない
0347nobodyさん
2008/03/26(水) 12:17:07ID:???実装者が未熟な場合か、処理が複雑なときだけかな。
クラスダイアグラムはモデル限定でこれもテーブル構成が複雑なときだけ。
ユースケースは文書に起こして仕様書にするので必須。
PHPのクラスを自動生成してくれる奴なかったっけ?
あれでCakeのモデルを自動的に管理してくれると楽かも...楽じゃないかw
0348nobodyさん
2008/03/26(水) 12:24:40ID:???書いているだけでしかないからなぁ。
それならコードで書いてコードからクラス図を自動生成したほうが楽。
0349nobodyさん
2008/03/26(水) 12:38:45ID:???正確にはEJBを使った場合だが、同じものを作るにしても
無意味に複雑になりすぎる。
あれじゃあ、UMLが必要になるのもわかる。
0350nobodyさん
2008/03/26(水) 13:44:26ID:ktIW9Uv7それだから「できました」とかいいながらテストしたらバグ出まくりのプログラムなんか量産しちゃうんだよwwww
UMLじゃなくてもいいが、実装前に詳細なロジックを書き起こしてからコードつくるのは常識だろ。
時間がかかる、めんどくさい、頭の中にもう仕様書書いてあるから、という奴に限ってたいした技術力じゃないんだよな。
設計書ってのはコーディング作業が楽になるだけでなく、チーム関係者との意識共有や、リリース後しばらくたってメンテが必要になった時に効果がでるもんだぜ。
プロとして仕事でやってるならば当たり前だと思ってるが、ここにはプロはいないのか？
0351nobodyさん
2008/03/26(水) 14:32:19ID:???0352nobodyさん
2008/03/26(水) 15:25:48ID:???実装前に詳細なロジックを書き起こしてからコードつくるのは常識だろ
それお前だけの常識乙ｗ
CakePHPのような小規模案件に無理があるぞお前ｗ
0355nobodyさん
2008/03/26(水) 15:37:50ID:???わざわざＵＭＬとか工数伸びるだけやんけ
そんなんで、ほんまに黒字になってんのかｗ
0356nobodyさん
2008/03/26(水) 15:41:14ID:???スレ違いながら言わせてもらうと・・
実際、開発しながら見えてくる事って多いよね。
キチンと設計や仕様固めが出来ないまま、見切りスタートを切ってしまうことも多々。
問題は、その仕様の追加、変更に対応出来るように設計する事だよ。
0357nobodyさん
2008/03/26(水) 16:12:51ID:???俺は書き方すら知らないけど。
作る前に一応メモに何をどうするかを書き出して、その通りに作ってくね。
あまりに自分の頭の中だけで作ると変数とか何を使ったかわからなくなったり。
イラレで仕様書とか作るのが激しくめんどい。
よって手書きで自分はやってます。
0358nobodyさん
2008/03/26(水) 16:15:44ID:???w
0359nobodyさん
2008/03/26(水) 17:32:25ID:???最低限、要求定義書とユースケースとビジネスロジック(=モデル)の関係図とそれを基にしたスキーマ設計位は必要じゃねーの
打ち合わせ段階で作りまくるじゃん、そんなの
どやってクライアントのイチャモンに対応してるの？
>>357
イラレで仕様書とか正気？
0360nobodyさん
2008/03/26(水) 17:56:28ID:???よって俺もexcel＆イラレだな。
0361nobodyさん
2008/03/26(水) 17:58:19ID:???概要みたいなもんだからね。
たとえば関数をすべてコーディング前に列挙できるかといったらまず不可能
プロのプログラマはコードで設計するんだよ。
鉛筆で図を書くか、キーボードでコードで書くかの違い。
0362nobodyさん
2008/03/26(水) 18:01:13ID:???0363nobodyさん
2008/03/26(水) 19:04:34ID:???○プロはソースに意味のあるコメントを残す。
0366nobodyさん
2008/03/26(水) 21:07:55ID:???0368336
2008/03/27(木) 00:00:03ID:d9lPRB8S意外と盛り上がっててびっくり…
0370336
2008/03/27(木) 02:53:28ID:d9lPRB8Sマジかよ。それなんてイラレ？
0371nobodyさん
2008/03/27(木) 11:48:14ID:???値を省略して（空文字で）データベースに保存した場合空文字でINSERTされる。
このときのどう保存されるか動作はデータベース依存であり
MySQLは0になり、PostgreSQLはエラーになる。
https://trac.cakephp.org/ticket/4233
チケットが出ていたみたいだが、修正無しでクローズ？
これ直る見込みないんかいな。確かに空文字とNULLは違うものだが
「データベースの省略可能な数値フィールド」ってのは
数値とNULLしか入れられないんだよね。
どうせNULLが入ったフィールドをModelから読み込むと
空文字になるんだし（あってるよね？）
NULLに変換して保存したほうが実用的だと思うんだけどなぁ。
データベース間の違いも吸収したほうがいいし。
beforeSaveあたりで書き換えるか・・・
0374nobodyさん
2008/03/27(木) 17:50:07ID:???広範囲のテーブルから値を持ってくるにはどうすればいいんでしょうか
SQLならLEFTJOINを繋げて行けば済むのですが
単純にrecursiveを増やしていくとクエリの量が異常に増えて困っています
0375nobodyさん
2008/03/27(木) 19:31:16ID:???どうせ同一人物だろうからトリップつけてくれ。削除すっからさ。
0379nobodyさん
2008/03/27(木) 21:54:01ID:???アソシエーションが直接繋がっている関係なら資料は山ほどあるのですが
例えば4テーブル先まで繋がっているデータを手繰り寄せてくる場合、デバッグ情報を見ると
一旦findで取得してきた配列をforeachで回して一つ一つまたfindを使っているように見えます
結果、データ自体は取ってこれるもののSQLの発行数が異常な量になってしまいとても使う気になれません
SQLの発行を抑えつつもアソシエーションを柔軟に広げるためには、自前でqueryを使うしかないのでしょうか？
0380nobodyさん
2008/03/27(木) 22:01:13ID:???var $fixtures = array(〜〜〜);
こんな感じでfixturesをしているわけだけどさ、
なんかテーブルの生成のタイミングとか変じゃない？
テストを単体で実行すると問題なく動くんだけど、
すべて実行するとテーブルが無いとか言われることがある。
0381nobodyさん
2008/03/27(木) 23:06:17ID:???adobe社のイラレだと思うけど。
>>375
わかる。人をバカにしてばっかだよな。あおってるやつ。
見てて気分悪い。
>>376 >>377
リファレンス見てわかるならそのURL教えてあげようよ。
しかも、聞いてる 374 はある程度知識あると思うよ。
もうちょっと人を思いやる気持ちを持とうよ。
0384nobodyさん
2008/03/27(木) 23:25:34ID:???0385nobodyさん
2008/03/28(金) 00:13:02ID:???残念なやつが多い
>>379
その4テーブルはどんなリレーションなの？
で、今はどんなアソシエーションを記述してんの？
もしかしたらDB設計が悪いという可能性もある。
0386nobodyさん
2008/03/28(金) 00:51:53ID:???各フレームワークの評価目的でプロトタイプを作っていますので
特定のテーブルの再設計で問題を解決するアプローチでは応用範囲が非常に限られてしまいます
申し訳ありませんがCakePHP側での解決を求めています
例えばごく単純にモデルが
A→B→C→D
とbelongsToで数珠繋ぎにアソシエーションが設定されている場合
AのリストにB〜Dのデータを動的に付加して取得したいとすると
どのような指定をすればよいのでしょうか
SQLならJOINをただ書き連ねていけばいいのですが
0388nobodyさん
2008/03/28(金) 01:30:56ID:???0389nobodyさん
2008/03/28(金) 01:42:40ID:???初心者が他人の力借りて簡単にCakePHP評価しようなんて
CakePHPなめすぎだろ？
自分で死ぬ思いでググれボケ
0390nobodyさん
2008/03/28(金) 02:37:39ID:???できそうにない。
https://trac.cakephp.org/ticket/2931
上で同じようなこと言ってたけど対応なしにcloseされた模様。
https://trac.cakephp.org/ticket/4277
上も同様のことを言ってる。3週間ほど前。
>>377 >>383 >>387 >>388 >>389
俺もこれの具体的な解決方法を知りたいです。どうか教えてください。
0393nobodyさん
2008/03/28(金) 03:20:48ID:???今調べて出来そうにないって。こういうケースはじめてなの？
経験浅すぎじゃね。１つのサイトをCakePHPで完成させたことないやろ
0394nobodyさん
2008/03/28(金) 03:22:38ID:???いや、これに関しての日本語の情報がなかなか見つからなかったから英語の記事を探さざるを得なかっただけ。
で、CakePHPの知識がある人はこれをどうやって解決してるんでしょうか？
0396nobodyさん
2008/03/28(金) 03:56:27ID:???0397nobodyさん
2008/03/28(金) 06:59:33ID:???何でだかアンチが混じっている。
で、cakePHPは重いとか、質問者を叩いたり。
無視推奨。
つか、アンチしてる人、cakePHPを無視すればいいのにね。
0398nobodyさん
2008/03/28(金) 08:46:16ID:???日本のサイトで分からなければ、海外サイトくらい見るだろ。
分からなければWeb翻訳すればいいんだしな
0399nobodyさん
2008/03/28(金) 09:18:10ID:???トリップの付け方も知らないらしいし、ほんと終わってんな。ｗ
0400nobodyさん
2008/03/28(金) 09:20:55ID:???とてつもないバカが何人かいるな
0401nobodyさん
2008/03/28(金) 09:29:46ID:???まさしくそのtickets通りです
CakePHPは隣り合ったアソシエーション間ではJOINを繋いでSQLワンコールに最適化してくれますが
それ以上のテーブルをまたいだ関係を持とうとすると途端にクエリ量が増えてしまいます
個人的にrecursiveでアソシエーションの深度を指定する考え方は
好感が持てるのですが、負荷の高さを考えると使用をためらわざるを得ません
サブクエリをインテリジェントに挿入しろとは言いませんが
今回の様な使用頻度の高いと思われる(かつ、割と実装の想像しやすい)処理ならば
既に解決された方がいらっしゃるのかと質問に至りました
--
先ほどContainableBehaviorを試してみましたがクエリ量は変わりませんでした
やはりコアに直接手を加えないといけないようですね(´・ω・`)
0402nobodyさん
2008/03/28(金) 10:01:46ID:???モデルにB→Aのアソシエーションも記述してあると
B→Aのクエリも発行される
だから
A→B→C→D のようなのをそのままやっちゃうと
えらいことになる
だから、いらいないアソシエーションはunbindModelでぶった切る
あと、1.2だと発行クエリが1.1より最適化されている
（つまり、少なくなってるってこと）
0403nobodyさん
2008/03/28(金) 10:11:39ID:???明らかにアンチじゃない奴のほうがたち悪いぞ。質問者叩いてるのもそう。
>>402
>>401の問題解決にはならないんじゃない。B->Aのアソシエーションがなくても起こるから。
>>401
DBにview作れば早いと思うよ。
0404nobodyさん
2008/03/28(金) 10:15:32ID:???レベル低いよな。
ここでアフォみたいな質問してるやつは
CakePHPでサイト構築したことあるのかと聞きたいよ
0405nobodyさん
2008/03/28(金) 10:19:27ID:???もっと常識レベルでの会話して欲しいな
駄文ばっかで何の役にも立たないよ
0407nobodyさん
2008/03/28(金) 10:30:15ID:???0408nobodyさん
2008/03/28(金) 10:36:03ID:???0409nobodyさん
2008/03/28(金) 10:57:56ID:???ウェブアプリなんて画面に表示する少ないデータを
表示するだけなんだからJOINしなくてもいいと思うんだけどね。
どうせ複雑なJOINならJOINするのにも負荷かかるわけだし。
ま、パフォーマンスと開発効率のトレードオフ。
どうしても必要なら、モデルに専用の検索メソッドでも作って
自分でクエリー書けばいいんじゃない？
0410nobodyさん
2008/03/28(金) 11:00:25ID:???0411nobodyさん
2008/03/28(金) 11:03:37ID:q/btZ3WHCakePHPが人気になって普及してきた証拠かなぁｗ
アンチじゃない人はIDだすようにするか？
そうすればID出していない人はアンチってわかるし。
出したら出したで削除できるしｗ
0412nobodyさん
2008/03/28(金) 11:10:07ID:???いい質問には、マナーをもって接するが
ろくでもないレスばっかりだからな
0414nobodyさん
2008/03/28(金) 11:14:01ID:???訂正を促すのが良い返答の仕方だよ。
0415nobodyさん
2008/03/28(金) 11:14:44ID:q/btZ3WHやってみなきゃわからないじゃんｗ
0417nobodyさん
2008/03/28(金) 11:57:59ID:anJTbKapもちろん速度を重視しなくてはならない場面ならば専用メソッド内でSQLを書きます
しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
フレームワーク自体に手を出して最適化させた方がコスト的にベターかなと思います
>>403
複雑なアソシエーションのパターンが出来上がってる時はView使った方がいいですね
今ふと考え付いたのですが、結合済みの仮想テーブルを作って、それを元に
CakePHP側のモデルを構築するアプローチは面白いかもしれません
#仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
0418nobodyさん
2008/03/28(金) 12:20:53ID:???負荷を考えるならフレームワークやめろ
CakePHPなんてのは、どうでもいいクライアントに高速納品するための道具てことに気づけよバカ
0420nobodyさん
2008/03/28(金) 12:43:39ID:???> 結合済みの仮想テーブルを作って、それを元にCakePHP側のモデルを構築する
view作ればって言ったのはそういうこと。
面白いかどうかはおいといて、現状の打開策としてはアリかなと思うわけです。
> 仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
このDB依存は仕方ないと割り切ればいいんじゃないかな。割り切れるところだと思うし。
0422nobodyさん
2008/03/28(金) 12:53:20ID:???やってくうちに想像しない難点が沢山でてくるよ
0424nobodyさん
2008/03/28(金) 13:04:47ID:???最適化したいならＣＩスレにいって、このスレからでていけや
0426nobodyさん
2008/03/28(金) 13:34:05ID:???どのフレームワークでも同じこと。
CIでもSymfonyでもRubyOnRailsでも同じだよ。
特にCIは最悪だね。いろんな意味で。
ここではすれ違いだから言わないけど。
0428nobodyさん
2008/03/28(金) 13:44:02ID:???> しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
シンプルではないよ。
CakePHPでもその他でもそうだけどO/Rマッピングというのは
従来の表形式の使いづらいリレーショナルデータベースを
高レベルに扱いやすく使えるようにするもの。
リレーショナルデータベースを基本に設計されたものではなく
より理想的なオブジェクト指向風なデータ構造をもとに設計されたもの。
だからいろんな取り出し方ができる出来る柔軟性がある。
たとえば、behaviorでデータ挿入・取り出し時に色んな処理をかませられる。
そういう柔軟性を持たせながらシンプルなSQLに置き換えるのは容易ではない。
不可能な場合すらある。
なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること。一日働いて3万円人件費をかけるのなら、
その3万円でスペックをあげたほうが総合的に考えてメリットが
高いという時代だから、今は。
0429nobodyさん
2008/03/28(金) 13:50:03ID:???データベースを使う場合、貧弱だよな。
あれならSQL直書きした方がいいってほどメソッドがアホらしいしｗ
なによりビヘイビアが無いのが一番痛い。
0430nobodyさん
2008/03/28(金) 13:50:47ID:???なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること
サイトリニューアルなど
既存ユーザーが多数いる自社製品ならパフォーマンスを意識する
0431nobodyさん
2008/03/28(金) 13:52:21ID:???マシンスペックを上げろ
0433nobodyさん
2008/03/28(金) 13:55:17ID:???■ このスレッドは過去ログ倉庫に格納されています