【PHP】フレームワーク CakePHP　5ホール目【v1.2】

【PHP】フレームワーク CakePHP　5ホール目【v1.2】 at PHP

1:nobodyさん
08/12/19 15:52:19 ylogT+7c
■本家
URLﾘﾝｸ(www.cakephp.org)
APIドキュメント
URLﾘﾝｸ(api.cakephp.org)
cookbook（マニュアル）
URLﾘﾝｸ(book.cakephp.org)
the Bakery
URLﾘﾝｸ(bakery.cakephp.org)

■日本語フォーラム
URLﾘﾝｸ(cakephp.jp)

■過去スレ
【PHP】フレームワーク CakePHP　4ホール目【v1.2】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワーク CakePHP　3ホール目【本命】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワーク CakePHP　2ホール目
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワーク CakePHP
ｽﾚﾘﾝｸ(php板)

2:nobodyさん
08/12/19 15:53:15
■その他いろいろ
10分で作るCakePHPアプリ for Windows
URLﾘﾝｸ(p4life.jp)

日本のcakePHP ユーザのためのハブサイト
URLﾘﾝｸ(cakephp-users.jp)

CakePHP 規約ワードメーカー　WordMaker for CakePHP Conventions
URLﾘﾝｸ(www.cpa-lab.com)

あとこのへんとか（初心者向けTIPS）
URLﾘﾝｸ(www.avatarfinancial.com)

CakePHP Note
URLﾘﾝｸ(www.garacter.com)

CakePHP入門リンク集
URLﾘﾝｸ(pub.studio15.jp)

CakePHPを使ったMVC設計のベストプラクティス - Sooey
URLﾘﾝｸ(www.sooey.com)

Qdmail（日本語メールコンポーネントとして利用可能なライブラリ）
URLﾘﾝｸ(hal456.net)

CakePHPカンファレンス東京
URLﾘﾝｸ(conference.cakephp.jp)

3:nobodyさん
08/12/19 15:53:49
■ver1.1用
チートシート
URLﾘﾝｸ(www.cakephp.org)

CakePHP プログラマーズリファレンスガイド
URLﾘﾝｸ(cakephp.jp)

連載：CakePHPで高速Webアプリ開発｜gihyo.jp … 技術評論社
URLﾘﾝｸ(gihyo.jp)

CakePHPフレームワークによる快速WEB開発 |codezine
URLﾘﾝｸ(codezine.jp)

■関連書籍
CakePHP ポケットリファレンス
URLﾘﾝｸ(www.amazon.co.jp)
CakePHP徹底入門
URLﾘﾝｸ(www.amazon.co.jp)
CakePHPガイドブック
URLﾘﾝｸ(www.amazon.co.jp)
Fast CakePHP
URLﾘﾝｸ(www.amazon.co.jp)

4:nobodyさん
08/12/19 15:56:22
テンプレらしきものは以上
最近のサイトでお勧めのものがあればどうぞ

5:nobodyさん
08/12/19 17:52:20
乙

6:nobodyさん
08/12/19 21:56:40
ろっくまん！

7:nobodyさん
08/12/20 01:42:56
Ruby on railsは、まともなスピードで動かす場合、
月5,000円のレンタルサーバーが必要です。

一方、cakephpなら、月500円のレンタルサーバーで
十分なスピードで動きます。

8:nobodyさん
08/12/20 01:57:02
php (笑)

9:nobodyさん
08/12/20 02:03:11
>>8はきっとあまり仕事ができないタイプ

10:nobodyさん
08/12/20 02:05:02
>>9 は頼まれてない余計なことばかりやって貧乏なタイプ

11:nobodyさん
08/12/20 10:48:19
>>6
まあ徴兵制だろうね。
戦前（に成人した）世代と戦後世代の日本人を見比べれば一目瞭然。

12:nobodyさん
08/12/20 17:36:31
cakephp に限ったことじゃないかもしれなけど、
できるプログラマーって何を聞いても親切に教えてくれるよな。

できないプログラマーってひたすら人をバカにしたがるよな。
なんなんだろうなこの違い。やっぱり謙虚さが大事なのかな。

13:nobodyさん
08/12/20 17:49:45
深く理解してないと教えられないからな

14:nobodyさん
08/12/20 17:53:38
>>12
> できるプログラマーって何を聞いても親切に教えてくれるよな。

「できるプログラマー」って何なのか詳しく教えてほしい。

15:nobodyさん
08/12/20 18:25:16
すぐヤラせてくれるプログラマーのこと？って書こうとしたけどヤメた。
できるとか、できないとかじゃなくて性格の問題だとおもいます。

16:nobodyさん
08/12/20 18:28:42
>>12 さんのいう「できるプログラマー」についての定義が待ち遠しいね。

17:nobodyさん
08/12/20 18:29:08
できる＝仕事の効率がいい
って事でしょ要するに
自分だけできればいいって人は仕事できるってあんまり言われないからね

18:nobodyさん
08/12/20 18:31:46
>>17
> 自分だけできればいいって人は仕事できるってあんまり言われないからね

その対象人物が周りから「できる」と言われればいいということ？
それは、「仕事の効率がいい」ということにはならないね。

19:nobodyさん
08/12/20 18:49:16
ひねくれた奴ばっかりだな

20:nobodyさん
08/12/20 18:56:26
>>14,16,18が使えない人間なのはわかった

21:nobodyさん
08/12/20 18:57:26
>>20
言葉の定義をしないままに議論なんか出来ないので、
「使えない人間」って何なのか詳しく教えてくれるとうれしい。

22:nobodyさん
08/12/20 19:29:30
定義も何も仕事できるかできないかだろ単に

23:nobodyさん
08/12/20 19:43:42
>>22
「仕事できるかできないか」ってどう評価するの？

24:nobodyさん
08/12/20 19:47:08
それが解らないって事はお前は仕事仲間を評価したりできてないってことだよな
一生リーダーになれないぞ

25:nobodyさん
08/12/20 19:49:29
>>24
> それが解らないって事はお前は仕事仲間を評価したりできてないってことだよな

なんでそういう飛躍をしちゃうの？

26:nobodyさん
08/12/20 19:54:06
ってことは評価できるって言うことだよね？
君は同僚を評価するときはどうやってしてるの？

27:nobodyさん
08/12/20 20:00:09
>>26
> ってことは評価できるって言うことだよね？

どこをどういう風に解釈すると、そういう問いを出すことが出来るの？

28:nobodyさん
08/12/20 20:01:17
今までの流れとは全く関係なくこの質問に答えて欲しい

>>27
君は同僚を評価するときはどうやってしてるの？

29:nobodyさん
08/12/20 20:03:12
>>28
今までの流れとは全く関係ないということなので、前提をつくらないと。

> 君は同僚を評価するときはどうやってしてるの？

同僚の何を評価すればいいの？

30:nobodyさん
08/12/20 20:52:18
同僚が仕事できるかどうかだろ

31:nobodyさん
08/12/20 21:39:25
標準のEmailコンポーネントは、
まだ日本語使うにはきつい？？

32:nobodyさん
08/12/20 22:12:10
俺は野良の使ったな結局
qdmail

33:nobodyさん
08/12/20 22:21:13
使ったことないのだが、symfonyと比較すると何がどのように違うの？
ざっくりでいいので教えてもらえるとうれしい。

34:nobodyさん
08/12/20 22:24:46
>>32
qdmailで送信すると
ヘッダにqdmailって入るんだけど、どうにかならんかなー？

35:nobodyさん
08/12/20 22:44:20
ってかプログラマだよなお前？
X-PHP-Qdmailで捜してって消せばいいんじゃないの？
MITライセンスなんだし

36:nobodyさん
08/12/20 22:45:23
>>35
そういう答えは求められていないと思われ。

37:nobodyさん
08/12/20 22:48:55
どういう答え？
ソース開いて$this->header['X-'.$this->xmailer]の部分消せみたいな具体的な指示？

38:nobodyさん
08/12/20 22:52:22
インターネッツの向こうにも人間が居ることを忘れないほうがいいと思うよ。

39:nobodyさん
08/12/20 22:54:57
こいつさっきから粘着してる荒らしだろ。
スルーしろよ。
>>34は消し方聞いてるんだからその回答で間違っちゃいない。

40:nobodyさん
08/12/20 22:56:03
> こいつさっきから粘着してる荒らしだろ。
> スルーしろよ。

それスルーしたことになってるのか？

41:nobodyさん
08/12/20 22:57:35
釣り針がぶっと過ぎて飽きた

42:nobodyさん
08/12/20 23:07:09
またRubyヲタが荒らしに来たのか
スルーしないけど

43:nobodyさん
08/12/20 23:08:42
論理が飛躍するかわいそうな子が荒らしとか何とか言っても説得力ないよなぁ

44:nobodyさん
08/12/20 23:16:12
なんでもRubyのせいにするとはPHPの方はRubyをいしきしてるんでしょうか。

45:nobodyさん
08/12/20 23:22:45
PHPしか使えないんだから仕方ないよ。
PHPしか使えない人たちの中で仕事ができる人なんでしょ。

46:nobodyさん
08/12/20 23:26:07
なにをもって仕事をできるとするかの問題が残ってはいるけどな。

47:nobodyさん
08/12/20 23:35:11
あんまり無能をいじめるのはかわいそうじゃないか？
Rubyもできない仕事もできない、そして仕事ができるという定義も解らない。

48:nobodyさん
08/12/21 00:17:25
>20
同意。

49:nobodyさん
08/12/21 11:26:07
まらRuby厨が荒らしに着てんのかｗ
いい加減にしろよ（笑）

Rubyが思ったほどシェアが増えなくて
あせっているのはわかるけど、
こんなところでPHPをたたいても
Rubyのシェアは増えないぞ。

これ、2年前にも言った。

50:nobodyさん
08/12/21 12:45:08
そういや楽天ってまつもと氏招いてRuby研究やってるのに
自社サービスはPHPとJavaだよな

51:nobodyさん
08/12/21 15:19:52
Ruby のせいにすると何かいいことあるの？

52:nobodyさん
08/12/21 15:44:20
>>51
Cakeへの文句の半分くらいをRoRが引き受けてくれる

53:nobodyさん
08/12/21 17:04:19
RoRで作ってもレンタル鯖で動かんしなぁ
だったらJavaでいいじゃんみたいな

54:nobodyさん
08/12/21 17:10:46
>>53
工数どんだけ違うんだよｗ

55:nobodyさん
08/12/21 17:27:24
SAStrutsだったら工数変わらんのじゃない？
開発中はデプロイしなくていいからスクリプト言語と変わらんし
scaffoldみたいなのもあるよ
殆どCakePHPと同じ

56:nobodyさん
08/12/22 17:14:23
Auth使うと認証必要ページにいったときに自動的にログインページに飛ぶけど
最初のページに対してPOSTデータを送っていた場合、失われるんだよね

ログインページへのリダイレクトはAuthコンポーネントが勝手にやってるから
セッションに入れたりって事も出来ない

どうすればいいと思う？

57:56
08/12/22 17:27:43
ログイン後に元のページへAuth->redirect()で戻るけどPOSTデータがなくなってるから意味無い場合がある
って事ね

58:nobodyさん
08/12/22 18:20:32
運用はさて置いて、
「認証が出来てない状態でPOSTが出来てることがそもそもおかしい」
というのが直感。

この場合は
「POST元のページに認証をかけて、そもそもの条件が発生しないようにする」
が解。
（当然、認証外のPOSTは受け捨て）

……これじゃダメなんだろうってことは察するけどｗ

59:nobodyさん
08/12/22 18:24:37
何かPOSTした時点で認証って別におかしくないでしょ
セッション短いとかあるタイミングで改めてログイン再確認とか

60:56
08/12/22 18:35:31
>>58
とりあえずその方向で一応の解決はした。
未認証の場合、フォームじゃなく「○○をする」みたいなリンクを出して
クリックするとログインフォーム、ログインすると元のページに来てフォームが表示されてる、
と言う形にした。

ただこの場合気になるのは、ビューでいちいちログイン状態を見て
リンクとフォームを切り替える必要がある事。
AuthコンポーネントがPOSTデータの再現もしてくれるのなら、
単にフォームを表示するだけで済む。

POSTする前に認証させておけ、と言うのとどちらが本来正しいのかは判断しかねるけど。

61:nobodyさん
08/12/22 20:05:14
モデルにアソシエーション書く時って
自モデルのフィールド名は指定出来るけど相手モデルのフィールド名は指定出来ないよね。
デフォルトでidフィールドが参照される

これって変更できる？

62:nobodyさん
08/12/22 20:09:45
auth compornent使ってみたけど、
これってログイン画面1つしか管理できないんですかね？

2種類のログイン画面を設置したいとき、なにかやり方ありますか？
投稿用と、観覧用など…

63:nobodyさん
08/12/22 20:20:39
userテーブルにprofile_idがあり、profileテーブルがあるとする
postテーブルにuser_idがあるとする
profile-user-post と言う関係

profileのフィールドでpostテーブルを絞り込み、paginatorで表示したい。
と言う場合直接ＳＱＬ書く以外にどういう手段がある？

端的に言えばpaginatorでの二つ先のテーブルのバインドってこと。
コンテイナブルで出来るのかと思いきや、直接アソシエーションが張られてないとダメらしい。
つまりuserとprofileが繋がってても、postからprofileが直接繋がってないとエラーになる。

モデルにpaginate用のメソッドを書けるけど
それ使っても直接ＳＱＬ書く事は避けられそうにない。
割と良くあるアソシエーションパターンだと思うんだけど。

64:nobodyさん
08/12/22 20:21:13
>>62
loginアクションで２つのビューを切り替えればいいんじゃない？

65:63
08/12/22 21:56:02
joins使って一応解決
にしてもスマートだとは思えない

66:nobodyさん
08/12/22 22:57:09
>>61
???
foreignKeyではだめなの？

> 自モデルのフィールド名は指定出来るけど相手モデルのフィールド名は指定出来ないよね。
> デフォルトでidフィールドが参照される
これの意味するところがよくわからない。

67:62
08/12/22 23:08:40
>>64
あ、画面だけっていうか、ユーザのアクセス管理も2パターンにわけたいって意味でした。
ちょっと書き方足りなくてすみません。

68:62
08/12/22 23:20:27
うーん。cakeの中にもうひとつcakeを置いて、そこで2つ目のユーザ管理するしかないかな。
トホホな気もするけど…

69:nobodyさん
08/12/22 23:41:22
>>67
<a href="URLﾘﾝｸ(book.cakephp.org)">AuthComponent の変数 :: 認証 :: 組み込みのコンポーネント :: マニュアル :: 1.2 Collection :: The Cookbook</a>
ここを読むと、userModelで別テーブルを指定してやればいいように思える。

70:62
08/12/22 23:56:41
>>69
書き方まぎらわしくてすみません。
投稿用のユーザ管理と、観覧用のユーザ管理があって、それぞれ
別のページにアクセスできることを想定してました。

複数のモデルをauthで管理できればいいのですが、情報ないですね。
特殊なケースではないと思うのですが、みなさん各自でカスタマイズして
るんでしょうか？

71:69
08/12/23 00:11:20
> 複数のモデルをauthで管理できればいいのですが、情報ないですね。
うん、そういう意味で上のリンクを張ったんだけど。

モデルを切り替えるんではなくて、複数のモデルを一緒くたにして扱いたいってことですか?

72:62
08/12/23 00:26:01
>>71
はい。複数のモデルを一緒くたにして扱いたいのです。
それぞれのモデルに登録されたユーザ毎にでアクセス制限かけたくて。

思いついた方法は、cakeの中にもうひとつcakeを入れることくらいでした。

73:nobodyさん
08/12/23 01:20:40
そういう権限レベルを分けるためのコンポーネントがある

74:nobodyさん
08/12/23 01:21:10
つーかもう一つcake入れるとかふざけたことやらずに
せめて自分でコンポーネント実装しろよｗ

75:62
08/12/23 01:57:15
や、やっぱふざけてますかこれw
肝はコンポーネントなんですね。実装といわれると
とても難しそうですが、調べてみます。

みなさん、ヒントをありがとうございます。

76:nobodyさん
08/12/23 02:23:37
ACLでいいんじゃないの？
最初理解するのは難儀かもしれんけど。

77:nobodyさん
08/12/23 03:31:28
>>73の言うように権限レベルを分けるコンポーネントはすでにあるよ
1.2で動くかどうかは知らんけど

78:73
08/12/23 06:42:00
つーかＡＣＬの事ね

ところで質問なんだけどモデル名とテーブル名の変換関数とかって

79:nobodyさん
08/12/23 08:28:34
>>56
URLﾘﾝｸ(book.cakephp.org)
やりたいことができるよ

80:nobodyさん
08/12/23 08:30:26
>>78
URLﾘﾝｸ(book.cakephp.org)
これ？　　とエスパー

81:69
08/12/23 08:50:50
>>72
認証と権限管理がごっちゃになってない?

Authコンポーネントは認証をするためのものだから、
そういう使い方をしようとすると無理が出るんだとおもう。

他の人も言っているように権限管理はACLコンポーネントを使うのがいいよ。

82:nobodyさん
08/12/23 15:24:32
routeがすげえ強力だというのを把握した

83:nobodyさん
08/12/23 16:03:34
CakePHPって、どこもかしこもarrayだらけだ。
arrayの入れ子ばかりたくさん書いていると、なんだかLISPを書いているような
気になる。
つうか、LISPの偉大さを思い知った気がする。
リストの入れ子の表現力はすげえな。

84:nobodyさん
08/12/23 16:08:36 BZm1ywfg
管理用機能と一般ユーザ用機能が完全に分けられるなら
システムごと分けちゃった方がベターだと思うんだ

85:nobodyさん
08/12/23 17:32:11
phpは配列の方が扱いやすい

echo"僕の名前 $a['name']";

こういう書き方が出来るけど

オブジェクトだと

echo"僕の名前 $a->name";

こうするとエラーが出るから

echo '僕の名前'.$a->name;
とか解体作業が必要になる

86:nobodyさん
08/12/23 17:34:50
phpは配列を扱う関数が豊富だから
オブジェクトを扱う場合も結局は配列の変換しないと
phpには豊富にある配列関数を利用できないんじゃない

87:nobodyさん
08/12/23 17:49:25
>>85

ネタですか？w

88:nobodyさん
08/12/23 17:50:33
レベル低過ぎ

>>85
後者でもエラーでないよ？　つうか、前者であれ後者であれ、
どこまで変数かを示すように、ブレースで囲む習慣をつけたほうがいいよ。

>>86
オブジェクトを配列として扱いたいんならArrayObjectとかあるやん。
foreachでプロパティ以外を扱いたいならIterator系をimplementすればいいし。

89:nobodyさん
08/12/23 23:11:18
PHPユーザの中でもレベルの低い層がCakePHPへ流れてきている悪寒

90:nobodyさん
08/12/24 03:20:53
PHP界隈って、どうしても「レベル低い」言いたい人がいるよねw

91:nobodyさん
08/12/24 04:16:31
アソシエーションの解決をスマートに解決する方法ないかなー
２つ３つ先のテーブルとなるとjoins使うしかないよね？

アソシエーションで読み込んだモデルのrecursive設定を見てそこからさらに見てくれればいいのに
アソシエーション探索を行うモデルを指定出来るようにして

92:nobodyさん
08/12/24 05:46:45
>>88
ArrayObjectはPHP5.2からだよ。
phpはオブジェクトは扱いにくいって言ってるだろうが素人が
なんでわかんねーかな

93:nobodyさん
08/12/24 05:53:40
>>88
ｐｈｐはオブジェクトの方が扱いやすいと思ってんの？

94:nobodyさん
08/12/24 05:59:57
PHP4のサポート終わってみんな5.2になりつつあるんだから5.2からでもいいんじゃね？

95:nobodyさん
08/12/24 06:04:17
>>88
オブジェクトだと
ArrayObject関数とか必要になるんでしょ？
それって手間じゃない？

96:nobodyさん
08/12/24 06:09:24
>>88
>>foreachでプロパティ以外を扱いたいならIterator系をimplement
どうやって？コード書いてくれよ
javaじゃないんだからさ。。。

97:nobodyさん
08/12/24 06:11:27
>>94
なりつつあるもののを
当たり前に使えるのような言い方をするのは
いかがなものかと・・・

98:nobodyさん
08/12/24 06:19:47
>>88
ArrayObjectみたいな不安定な関数よく使ってるよなｗｗｗ
URLﾘﾝｸ(uruseiyatsura.way-nifty.com)

99:nobodyさん
08/12/24 06:22:53
>>88
>>オブジェクトを配列として扱いたいんならArrayObjectとかあるやん。

ArrayObjectてオブジェクトを配列として扱う関数なん？
配列をオブジェクトとして扱うんじゃなくて？
URLﾘﾝｸ(php.mirror.camelnetwork.com)

100:nobodyさん
08/12/24 06:27:46
>>88
ArrayObjectて配列をオブジェクトとして扱ってるよね？
記事をきちんと読もうよ！素人さん

101:nobodyさん
08/12/24 11:25:53
いまさら知ったんだけど、OpenPNEがフレームワークにsymfonyを採用したみたいね。
ちょい嫉妬ｗ

102:nobodyさん
08/12/24 13:12:13
>>97
特定の環境で動かすアプリが殆どなんだから
一般配布するCGIでもなけりゃ使えるなら使えばいいともう

103:nobodyさん
08/12/24 14:29:58
>>102
つかえばいいやん
CakePHPで使う必要がどれだけあるのかと・・・

104:nobodyさん
08/12/24 14:34:03
使える、使いたい、って言ってる人に対して、
使う必要ないってかたくなに言うのもなんだかなぁって思う。

105:nobodyさん
08/12/24 17:44:15
あくまでアドバイスや意見で自分で判断すればいいじゃん

106:nobodyさん
08/12/24 20:54:05
>>105
おまえのはアドバイスじゃねーよｗ
自分の発言繰り返して読んでみろ

107:nobodyさん
08/12/24 23:37:14
>>106
あらあら、次は勝手に特定ですかw

108:nobodyさん
08/12/25 12:13:56
2カラムのインデックスをmodelにプライマリキーとして設定することが可能であれば、
設定を教えて頂けませんでしょうか？

既存のmysql DB管理にcakeを使うつもりでいたら、上記設定のため
idのテーブルを追加してプライマリに設定することが行えませんでした。

109:nobodyさん
08/12/25 12:26:16
cake使うなら、OOPの勉強は必須？

なんかやたら「なんちゃらextends～～」とかって
出てくるんですけど？？

110:nobodyさん
08/12/25 12:31:02
>>109
不要。
extendsが何をしているかとか、疑問に思ったら都度調べるくらいの姿勢があれば良いと思う

111:nobodyさん
08/12/25 13:14:10
>>108
URLﾘﾝｸ(book.cakephp.org)
「できなかった」というと？

112:nobodyさん
08/12/25 13:30:27
>>111
既存のプログラムが使用しているDBを、横からcakeで管理したかったので、
DBを新しく作ったり、すでに作られている2カラムのインデックスを解除したりは
できません。

idカラムを作成し、auto incrementalを設定しようとすると、
すでにprimaryが存在するために処理が失敗してしまいました。

primaryに設定されている2カラムのインデックスを解除すると、
既存のプログラムが動作しなくなってしまうのです…

113:nobodyさん
08/12/25 13:47:22
>>112
CakePHPでは複合プライマリキーは使えない

114:nobodyさん
08/12/25 13:57:27
>>112さん
ここを読むといいよ!

"複合キー" フォーラム - CakePHP Users in Japan
URLﾘﾝｸ(cakephp.jp)

115:nobodyさん
08/12/25 23:43:53
>>113-114
cakeと複合キー処理について、理解が深まりました。
なんとかなりそうです。ありがとうございます。

116:nobodyさん
08/12/26 10:52:31
1.2 stableあげ

117:nobodyさん
08/12/26 11:25:09
RC4からほとんど変わってないやんけｗ
もっと完全にバグ取ってからにしてほしかった・・・

でもおめでと～！

118:nobodyさん
08/12/26 12:06:29
1.2すたぶるキター

く・・クリスマスプレゼント？

119:nobodyさん
08/12/26 12:24:27
しかもケーキってとこが洒落てるｗ

120:nobodyさん
08/12/26 12:32:56
いや、クリスマスケーキか

121:nobodyさん
08/12/26 12:33:32
あ、リロード忘れてレス付いてるのきづかんかったわ

122:nobodyさん
08/12/26 15:09:01
いつもDonationの所 No Thanksでごめんね。

123:nobodyさん
08/12/26 15:14:48
三項条件式どんだけ便利やねん。多様は可読性悪くする
ビューで使うとかなり見通しがよくなる

124:nobodyさん
08/12/26 15:26:28
CakePHP におけるシンボルの命名規約

private 先頭にアンダーバーを２つ置く __test
protected 先頭にアンダーバーを１つ置く _test
public 先頭にアンダーバーを置かない test

ナンジャコリャー

125:nobodyさん
08/12/26 15:44:12
>>124
Pythonでも似た仕組みが使われている。
慣れれば悪いものじゃない。

126:nobodyさん
08/12/26 16:23:26
cakephp,ちょっとむずかしくない？

127:nobodyさん
08/12/26 16:33:19
EthnaやMapleよりかなり簡単だと思ったが

128:nobodyさん
08/12/26 17:06:20
>>126
難しいというか独自ルールが多いとは感じた。
しかし、それを超えた先の開発効率はすばらしいと思う。

129:nobodyさん
08/12/26 17:06:36
ん？
cakeのprotectedってどういうタイミングで使うん？？

130:nobodyさん
08/12/26 17:13:03
ほんとに開発効率高いのかなあ
symfonyも使ったけどバリデーションルールの自動生成が無いのは確実にマイナス

131:nobodyさん
08/12/26 18:17:48
1.1から1.2に変えたら表示に常に10秒余計にかかるようになったけどなんで？

132:nobodyさん
08/12/26 19:14:18
debugモードじゃね

133:nobodyさん
08/12/26 19:19:08
開発効率の向上以上に、メンテナンス効率の向上を実感することが多い
過去製作したコードを見たとき、「何でこんなことしてるんだっけ？」っていうのが激減した

134:nobodyさん
08/12/26 19:50:29
1.2stableのbakeって複数プロジェクト前提みたいになったけど、どこにプロジェクト作るのがいいんだろ?
cakeの一番上のディレクトリに、/appと並ぶ形で作ると管理しやすいかな。
PDTとかで管理する上でも。

135:134
08/12/26 22:09:57
結局楽するために今までどおりappの中に作る事にした

136:nobodyさん
08/12/26 22:30:57
複数プロジェクトってどうやるんですかね？

137:nobodyさん
08/12/26 22:36:04
複数プロジェクトとうか、コア(cakeディレクトリ)の共有だろ？
マニュアルに書いてある。
URLﾘﾝｸ(book.cakephp.org)

138:nobodyさん
08/12/26 22:41:30
コミュニティのレベルも低いし
だめっぽくねcake

139:nobodyさん
08/12/26 22:55:42
とくにダメっぽいところ感じないんだが

140:nobodyさん
08/12/27 01:25:44
>>136
bakeで好きなところにプロジェクトを吐けるよ

141:nobodyさん
08/12/27 03:36:46
URLﾘﾝｸ(book.cakephp.org)
とかIE7でもおかしいし、firefoxだともっとやばい
なんとならんの？

142:nobodyさん
08/12/27 08:43:14
CakePHPの新しい本（英語だけど）
Practical CakePHP Projects 400ページ 3,963円　08/12/8発行
URLﾘﾝｸ(www.amazon.co.jp)
どうよ？

（参考）半年前に発売されている姉妹書
Beginning CakePHP: From Novice to Professional 344ページ 3,963円 08/7/21発行
URLﾘﾝｸ(www.amazon.co.jp)

143:nobodyさん
08/12/27 12:39:56
>>142
4000円とかあほくさー

ページあたり10円かよ

144:nobodyさん
08/12/27 13:29:46
「Terrible Examples, Poorly Written Book...」って言われてる。

145:nobodyさん
08/12/27 13:52:50
このシリーズって日本で言うと「できる」シリーズみたいなもんだろ？

146:nobodyさん
08/12/27 15:59:16
できるシリーズは明らかに超初心者向けな写真メインの構成なだけで
値段も倍くらい違うし一緒にするのはかわいそう

147:nobodyさん
08/12/27 18:29:26
早速CakePHP 1.2.0.7962-Stableをダウンロードし、CakePHP1.2を始めようとしたら
URLﾘﾝｸ(cakeforge.org)
app/config/の中に、database.php.defaultファイルが見当たらない。
探し方が悪いのか？本家が忘れ物したのかな？
みなさんのところdatabase.php.defaultファイルあります？

148:nobodyさん
08/12/27 18:33:33
>>147です。
database.php.defaultありました。スマソ

149:nobodyさん
08/12/28 18:51:53
聞きたいことがある。

Model::save() で、バリデーションエラーではなく、DBシステムエラーが起こっ
た場合には、同様に戻り値は false になるんだろうか？

もしそうなら、バリデーションの場合とシステムエラーの場合とで、戻り値が
falseの時の処理を分けなければいけないと思うんだけど、どうしたらいいんだろ？

1. save()の前にvalidate()を実行して分岐する。
2. save()のあとにinvalidFields()を実行して分岐する。
みんなはどうしてる？

150:nobodyさん
08/12/28 20:13:58
>>149
Model::onError()

151:nobodyさん
08/12/28 20:41:33
>>150
うわー、これ知らなかった！
なんだ、DBアクセスの箇所ごとにエラー処理する必要はなかったんだ。
ありがとう。

152:nobodyさん
08/12/28 22:11:07
DBエラーって、onError()イベントハンドラのコール以外で知ることはできない？
うちの場合ちょっと事情があって、onError()関数でを上書きできないので。

153:nobodyさん
08/12/28 22:33:37
クラスDboSourceのソースを見たら、Model::onError()が呼ばれるときは、
Model::save()の戻り値はやっぱり false だった。
save のあとで invalidFieldsがあるかどうかで分岐すればよさそう。

154:nobodyさん
08/12/29 03:21:56
>>152
適当にDboを継承してonErrorが呼ばれてる部分を実装すればいいのでは？
やりたくないけど。

>>153
DB側がエラーになってる時点で、saveも糞もないと思う。

155:nobodyさん
08/12/29 10:08:14
>>154
>>153は、controllerでどう書くかを言ってるんだろ

156:nobodyさん
08/12/29 10:43:26
>>152
まずはどんな事情かを説明しろ

157:nobodyさん
08/12/29 13:36:03
「CakePHP徹底入門」の正誤情報掲載してくれ～
URLﾘﾝｸ(seshop.com)
08年9月発売で、発売から4ヵ月も経っているのに、まだ正誤情報掲載してないぞ～
俺は、Ajaxの項のp.178のリスト5.5が全然違うのがわからず、メチャ手間取ったぞ～
ＣＤのLIST5-5も全然違うじゃねーか。ダブルパンチだ。
早く正誤情報掲載してくれ～

158:nobodyさん
08/12/29 18:21:03
そんな本のことはさっさと忘れるべき。

159:nobodyさん
08/12/29 20:00:17
>>158
本を悪く言ってんじゃなくて、反対
「CakePHP徹底入門」良い本だから期待している。
CakePHP１.２で解説されているから非常に便利。内容も入門者にはベスト。良い例題でわかり易い説明。

まだ半分までしか読んでないけど、気付いた間違いを紹介
p.179誤
37: <?php echo $jptime->jpdatetime($product['Product']['created']); ?>
40: <?php echo $jptime->jpdatetime($product['Product']['modified']); ?>
正(ＣＤもＮＧ)
37: <?php echo $product['Product']['created']; ?>
40: <?php echo $product['Product']['modified']; ?>

160:nobodyさん
08/12/29 20:00:53
p.180誤
リスト5.7
1: function index() {
リスト5.8
1: function index() {
正(CDはOK)
リスト5.7
1: function index($id = NULL) {
リスト5.8
1: function index($id = NULL) {

p.89中あたり誤
INSERT INTO products VALUE (1, 1, '商品１', now(), now())
INSERT INTO products VALUE (2, 2, '商品２', now(), now())
INSERT INTO products VALUE (2, 2, '商品３', now(), now())
正(CDはOK)
INSERT INTO products VALUE (1, 1, '商品１', now(), now());
INSERT INTO products VALUE (2, 2, '商品２', now(), now());
INSERT INTO products VALUE (3, 3, '商品３', now(), now());

上記３つはプログラムが動かないけど、以下２つはどうでもいい事

p.133下の方誤
shopping/controllers/category_controller.php
正
shopping/controllers/categories_controller.php

p.116下の方誤
と質問がきますので、「y」を入力して終了します。
正
と質問がきますので、「n」を入力して終了します。

161:nobodyさん
08/12/30 19:33:21 uva7pRTj
Railsを猿真似してくれたら楽なのに
所々にいらぬお節介がついて回るよね、cakeは
核になるMVCを無意味に密に結合するような作りにしたりして
素晴らしいお手本があるにもかかわらず何故センスのない変な拡張をいれるんだorz

162:nobodyさん
08/12/30 23:28:49
好きなFW探して使ったらどうでしょうか

163:nobodyさん
09/01/01 15:27:00
おっ、マニュアルのレイアウト崩れが直った？

164:nobodyさん
09/01/01 16:48:24
>>163
目次の「3 CakePHPによる開発」をクリックするとレイアウト崩れるけど？
URLﾘﾝｸ(book.cakephp.org)

165:nobodyさん
09/01/01 17:23:53
あらま、これってどこかに報告したほうがいいの？

166:nobodyさん
09/01/01 21:00:37
他のページも崩れまくってる

以前のマニュアルページがそのままインポートされてる感じだね

167:nobodyさん
09/01/02 07:50:16
setFlash()をflash()すると
末尾に 1 っていうゴミが付いてくるんだけど、なんだろう？

168:nobodyさん
09/01/02 07:57:24
事故解決
echo $session->flash();

って書いて返値のtrueを出力してた

169:nobodyさん
09/01/02 22:49:27
>>163　　>>165
1.2マニュアルのレイアウト崩れ直ったみたい。
URLﾘﾝｸ(book.cakephp.org)

170:nobodyさん
09/01/02 22:55:13
>>169
おっ、ほんとだ中の人gj

171:nobodyさん
09/01/03 02:12:26
なおってねーよ
再現率は１００％じゃないのかねぇ

172:nobodyさん
09/01/03 02:28:49
ページによって出たりでなかったりってのはあったが
今見た限りでは直ってた

どこのページで問題出てる？

173:nobodyさん
09/01/03 03:49:50
1項目づつ次のページのリンクたどってくとおかしいね

174:nobodyさん
09/01/03 18:30:22
Formヘルパーのinputメソッドを使って文字の入力画面を表示すると
文字サイズが大きいのですが、文字サイズを小さくするにはどうすれば
よいでしょうか？よろしくお願いします。
echo $form->input('content', array('type'=>"text", 'label'=>""));

175:nobodyさん
09/01/04 10:58:57
>>174
それはCSSとかの話じゃなくて？

176:nobodyさん
09/01/04 12:47:21
>>175
ヒントありがとうございます。
正解みたいですね。CSSは耳にした事はありますが、難しいので避けてました。
CSS レイアウト　スタイルシートがキーワードのようですね。
URLﾘﾝｸ(www.bnote.net)
URLﾘﾝｸ(www.ideaxidea.com)
勉強してチャレンジしてみます。

177:nobodyさん
09/01/04 14:23:59
('A`)

178:nobodyさん
09/01/04 17:01:24
テーブルレイアウトが主流だけど、数年後にはcssは必須になってる。
今から先取りして覚えておいて損はない。

179:nobodyさん
09/01/04 17:31:20
現時点でテーブルレイアウトにしようなんて奴は逆に勇者に見えるわ

180:nobodyさん
09/01/04 18:16:16
グーグルはテーブルレイアウトだよ

181:nobodyさん
09/01/04 18:47:13 u5+bOtGZ
費用対効果
テーブル使った方がはるかに効率的な場合に狙ってやるのは○
テーブルレイアウトしかできないのは論外

182:nobodyさん
09/01/04 18:48:37
デザイン直ってないな
崩れまくり

183:nobodyさん
09/01/04 19:10:12
>>180
グーグル自体がクロールされる必要はなかろう。。

184:nobodyさん
09/01/05 02:25:07
なぜCakePHPみたいな将来性なさそうな技術に時間使ってるの？

185:nobodyさん
09/01/05 02:48:35
>>184
お前さんもここで使ってるよねw

186:nobodyさん
09/01/05 02:48:56
じゃあCake以外でいいの教えてくれよ。PHPで。

187:nobodyさん
09/01/05 03:19:39
オープンソースあぷりの多くがPHP製

188:nobodyさん
09/01/05 16:02:01
>>187
それはちょっと前にPerl開発者が言ってた台詞だよ・・・

189:nobodyさん
09/01/05 20:31:10 qd8O6pD6
仕事で仕方なくcake使ってるが次使うことはないだろう・・・

190:nobodyさん
09/01/05 21:29:11
>>189
ちなみに次は何を検討してる？

191:nobodyさん
09/01/05 23:41:50
もち、ちぃたん

192:nobodyさん
09/01/06 09:15:09
つｽﾚﾘﾝｸ(php板)

193:nobodyさん
09/01/06 09:26:24
URLﾘﾝｸ(book.cakephp.org)

まだ壊れてるぞー

194:nobodyさん
09/01/06 09:36:40 UaXiuRrZ
URLﾘﾝｸ(book.cakephp.org)

この辺りも
1ページ表示で崩れる

195:nobodyさん
09/01/06 15:31:13
>>193-194
この問題ってcakephpの問題じゃなくて
デザイン(css)の問題でおｋ？

196:nobodyさん
09/01/06 15:48:45
フレームワークの恩恵を受けるのは
マスターしてから１年後だと思う。１年経つとCakePHPに特化した使いまわし出来るロジックがかなり増える
なので新しいフレームワークが出て、すぐ移行するのは
今まで蓄積したロジックを捨てるに等しいので
CakePHPを８割、新しいフレームワーク２割という感じでフレームワークを使っていこうと思っている

197:nobodyさん
09/01/06 15:52:53
成長性を考えると、全体案件の２，３割は新しいフレームワークへ力を入れた方がいい
このバランスが大切だと思う、完全シフトはただのバカと思うし
CakePHP１００％たより過ぎも、将来がない

198:nobodyさん
09/01/06 15:55:30
新しいフレームワークを覚えるにしても
CakePHPを超えるものは見当たらないから
実質、ＣａｋｅＰＨＰ１００％でやってる

199:nobodyさん
09/01/06 16:08:25
コンセプトさえ理解してれば新しいフレームワークの導入なんて
せいぜい三日程度のコストしかかからないと思うんだが
独自コンポーネントを移すにしても

200:nobodyさん
09/01/06 16:30:45
1.2.0.7962 Finalきた

201:nobodyさん
09/01/06 17:03:32
細かいところでハマりまくる日々…
出来る人との違いを痛感します

202:nobodyさん
09/01/06 17:51:38
>>200
あけおめ

203:nobodyさん
09/01/06 17:54:47
>>196
言うよねぇ～

俺も2年くらい使ってるけど、ほんっと使い回しが効く。
素晴らしいです。

204:nobodyさん
09/01/07 00:15:09
>>200
メリクリ

205:nobodyさん
09/01/07 02:09:30
CakePHP 1.2 SP1はまだですか？

206:nobodyさん
09/01/07 10:48:13
ModelBakerが話題にあがってこないけど、誰も使ってないのかな？
URLﾘﾝｸ(www.widgetpress.com)

Macユーザー自体少ないのかな。

自分はこれからさわってみます。

207:nobodyさん
09/01/07 16:24:24
>>206
なんか凄そう。と思って落としてみたけど10.5専用なのね・・・残念。

208:nobodyさん
09/01/07 16:47:56
URLﾘﾝｸ(book.cakephp.org)
これってトランザクション使わないとまずい？

209:nobodyさん
09/01/07 16:55:48
>>208
詳しいことは他の人に譲るが
記憶が定かなら、確か件数取得（select）して、書き込む（update）だけだったと思うから、トランザクション関係ないはず。

210:209
09/01/07 17:00:24
>>208
あれ？複数Modelのsaveについて言っているのかな？

211:nobodyさん
09/01/07 17:04:53
>>210
関連モデルのsaveについて言ってる
公式マニュアルのくせに何の注意書きも無いから内部でうまくやってるのかなと

212:nobodyさん
09/01/08 09:16:02
実験してみてくれ

213:nobodyさん
09/01/08 11:52:33
Cake1.2です
viewで
echo $form->error('Modelname.fieldname', '出力されるエラー表示');
だとうまくいくのに
echo $form->error('Modelname.fieldname');
でmodelの$validateで代入した'message'が表示されません。
これでうまくいくようなことがあちこちに書いてあるのに。
どうやったら'message'を出力できるんでしょうか。

214:nobodyさん
09/01/08 14:16:03
解決しました。
modelの文字コードが原因でした。

215:nobodyさん
09/01/09 08:36:44 I5IAXkbt
初歩的な質問かもしれないんですが
モデルクラスのプロパティは、コントローラーをまたがって保持されます？

なにがやりたいかというと、
モデル内でファイルを読み込んで、そのデータをプロパティに保持
(DBを使わないモデル)
他のコントローラーからそのモデルクラスのプロパティを参照したい

personモデル
　var $sex;
function loadfile() { ファイルを読み込んでプロパティをセット }
function getSex() { 性別を返す }

peopleコントローラー
getSex()でデータ取得

profileコントローラー
　getSex()でデータ取得

各コントローラーで、必ず毎回ファイルを読み込まないとだめでしょか？

216:nobodyさん
09/01/09 08:42:51
静的メンバで以下みたいにやれば出来るんじゃね
if(isSet(ClassName::sex)){
//ファイル読み込み
}

一応いっとくとプロセスまたがっては無理だよ

217:nobodyさん
09/01/09 08:43:21
あ、if(!isSet())ね

218:nobodyさん
09/01/09 08:51:49
なるほど…ありがとうございます
できなくはないんですね

基本的には、CakePHPの流儀(というかPHPフレームワーク?)としては、
コントローラーごとに毎回データを読む(DB使う場合も)
という感じでしょうか

あとはキャッシュ機能を使うみたいな

219:nobodyさん
09/01/09 08:54:52
コントローラー呼び出しごとにアクセスがあると、
ちょっと心配なんですが、キャッシュ機能使えってことでしょうか

セッションに保存するのはなんか違う気がしますし

220:nobodyさん
09/01/09 09:02:28
セッションに保持すればよいということではないの？
というか、そもそも、people と profile が関連づけられていれば、profileコントローラーは不要だと思うが
（よく読み込まずに答えたから、見当違いだったらすまん）

221:nobodyさん
09/01/09 09:02:36
DBアクセスオブジェクトは一つしか作られないよ

222:nobodyさん
09/01/09 09:03:29
目的がパフォーマンスならセッションに入れる意味はあまり無いんじゃないの？
DBから読むかファイルシステムから読むかの違いでしょ

223:nobodyさん
09/01/09 09:05:38
どういうDBアクセスが発生してるか気になるならデバッグモードにすればいい

224:nobodyさん
09/01/09 10:12:30
>>215は、Model とController の対応が間違っているということはないの？
Userモデル(Personモデル)
Usersコントローラー
があって、

/users/index で、Usersリストを表示する
/users/view で、Userプロフィールを表示する
みたいな

質問を読むと、根本的な問題のような気がする
（Peopleモデルというのがイメージできないし、Personsコントローラーがあれば、Profilesコントローラーは要らなそうな気がする）

225:215
09/01/09 11:09:25
すんません
例は適当です…

具体的には、ファイルからデータを読み込ませ、
そのデータを元に、各コントローラーでフォームを自動構築しようとしています
(入力内容が毎回可変なため、このようにしています)

ファイルには各コントローラーにまたがる入力項目のデータが含まれていて、
各コントローラーでは、そのデータを読み込んでフォームを構築します

この場合、コントローラーごとにファイルに何回もアクセスする
ということでいいんでしょうか？
(今のところ、データベースは一切使いません。)

226:215
09/01/09 11:16:27
ファイル(product)
　商品名:text
　価格1:select
　価格2:select
　(価格の数は可変)

ファイル(price)
　1000
　2000
　3000
　(可変)

モデル
product
　price

コントローラー
　productController
priceController

ビュー
　product(商品の選択画面)
　　ファイルを読み込んで商品名を選択する画面
　price(価格の入力画面)
　　価格のデータ数分だけフォームを入力

コントローラーを分けているのは、もう少し複雑で、他のデータなども混じるためです
うまく説明できない・・・・

227:215
09/01/09 11:23:38
実際にはpriceにも、価格専用のフォーム生成のためのデータが入ってます(これも可変)

productにまとめると肥大化&実際に価格データ専用のアクションも必要になるため、
コントローラーをわけてます。

うまく説明できないのですが、
とりあえず、コントローラーまたぐならファイルに毎回アクセスしろってことですかね

228:nobodyさん
09/01/09 11:37:58
コンポーネント使えよ

229:nobodyさん
09/01/09 11:38:29
いやむしろエレメント使えよ

230:215
09/01/09 11:54:38
>>228

コントローラーは共通じゃないです
モデルは一部共通ですね
となるとビヘイビア？

どのみち、普通にやるとなれば毎回ファイルアクセスは発生ですね
後で外部クラス化を考えることにします…

231:nobodyさん
09/01/09 12:05:39
なんでビヘイビアになるんだ？
コンポーネントかエレメントで出来るだろ

232:nobodyさん
09/01/09 12:12:39
>>225 から想像するに、通常DBに保存するデータを、DBの代わりにファイルに保存しているということかな？

そうだとすると
「コントローラーごとにファイルにアクセスで良いか」というのは、Yesということになるね
（ただし、正確には、ControllerではなくModelだけど）

ProductとPriceがHasManyの関係にあるのなら、なるべくDBを使うべきでしょう。
（もしかしたらHABTMかもね）

233:nobodyさん
09/01/09 12:15:46
いやいやそれ以前に
フォーム生成処理を共通化したいのならエレメントかコンポーネントだろ

234:nobodyさん
09/01/09 12:19:41
で、パフォーマンスを気にするのであれば、ビューキャッシュか、CacheEngine使うということで良いと思うが。

235:nobodyさん
09/01/09 12:20:22
あ、>>234は、>>232のつづきね

236:nobodyさん
09/01/09 12:28:58
>>233
たぶん、>>215が気にしているのは、「毎回DBやファイルを読み込むのが気持ち悪い」ということかなと。
だとすると、viewの問題ということなんだけど、そもそもModelやControllerの設計がまずいとキャッシュも使えないからね。

237:nobodyさん
09/01/09 12:34:01
PHPで常駐プロセスにデータを預けておくと言う事は出来ない。
DBに記録する以外は。

Cakeのキャッシュなんて所詮はファイルシステムから読み出してるに過ぎないから
それ以上の高速化は無理。

そもそもやろうとしてる事がエレメントを使って書くべきものに思えるが。

次ページ