>>451
モデルのキャッシュを消してみては

しない。ちょっと書く内容が異なるだけ。

モデルが複合主キーのテーブルに対応してないのは
問題だと思うんだが。
リプレイス案件とか既存のシステムと同じDBを使うとかだと
逃げ道作ってくれないと困るんだよ・・・

複合キーなんていらなかったんや

>>457
何故そう言える？

最近のトレンドであるActiveRecordが複合キーを使う事を考慮してないからね。
ActiveRecordを実装するにはO/Rマッパーが必要で、
O/Rマッパーは複合キーと相性が悪いよね。
ActiveRecordにも得手不得手があるから、ActiveRecordが苦手なスキーマが必要ってなら、
ActiveRecordを前提に成り立ってるフレームワークであるCakePHPは、
そもそも道具選びが間違ってるんじゃないかな。
それは言いすぎだとしても、
CakePHPをはじめとしたフレームワークは、
ニーズの多いところをよりよくカバーするから、
ニーズの少ないところにサポートが無いのはしょうがないと思うよ。
各テーブルにidという主キーが必ずあるようなスキーマで、
大抵のものは作れるし、その規約に沿ったほうが楽ってのもあるね。
長々と書いたけど、
俺はそんなスキーマで作るようなのしか、今のところ作る予定が無いから、
複合キーなんていらなかったにゃって思ったんだ。
もちろん冗談交じりだぞ。

CakePHPを始める時に参考にした図書とかあります？

Cookbookってお勧めできるほどには参考にならない気がする。
英語版はまだマシだけど、
日本語版は古い・間違いが多い・サンプルがシンプルすぎて実務で悩むとこは結局学習できない。
読む必要が無いってわけじゃないんだけど、Cookbookだけだとつらいと思うよ。

CakePHPによる実践Webアプリケーション開発って本を参考にしたけど、
これはもう古いからなぁ。1.2ベースだし。
でも一応、Cookbookのサンプルを作って基本的なことを理解してからなら、
この本はそこそこ役に立ったよ。

余談だけどACLが複雑すぎて使う気が起こらない。

昔は積極的に本を買ってたけど、最近は不作だから買ってないな…
そういうユーザーが多いから、良い本が少ない→売り上げ少ない→次の本が出ない、の悪循環なんだろうか

はじめはCook Bookでいいと思う。
CookBookには詳細な機能はあまり丁寧に載っていないので、いちいちネットで調べることが多くなってくる。
そうなったらリファレンス本を買って眺めながらいろいろつくってみるといい。
自分の場合はそれでかなり覚えたよ。
個人的には秀和システムのCakePHP辞典がおすすめ。
手持ちの初版には誤字が少しあるけど、暇な時に眺めるだけでおもしろい。

まぁ、Cakeに限らず、リファレンス本が一番便利だよな。
自分が何したいかで調べたらいいし、作者の作法を身につけなくても良い

一次情報だけで十分。
Cookbookで流れをつかんで、開発しだしたらAPI Class Indexを参照すればほぼ足りる。
そのうちタイミングとかインスタンス生成が気になってソースを見ることになるけど。

アクションじゃなんか問題あるの？
てか、例えばユーザーのプロフィールページの場合、ユーザー名とか書きたいから、
モデルからユーザー名など貰って、アクションでセットする事になるんじゃ。

アクションでセットは良いんだけど、編集するのに、
controller見なきゃ行けないというのがな・・・

かといってビューで編集するのもなんか違う気がするし

でも、タイトルってビュー（デザイン）の部分じゃないか？

そう思うなら別に$title_for_layoutを使わなくてもいい

画面に出すテキストが全てビューにあるなら、
Cakeってかphpで作る必要ないっしょ。

>>472
そうだよな。

だけど、viewの使い回しが出来なくなるよな。

レイアウト使わずに、ヘッダをエレメントにすればいいんだけど、美しくはないね。

変数にタイトルをセットしてエレメント呼び出しの手順で。

>>476
それしたら前にめちゃくちゃこのスレで罵倒された
「決まったもん以外定数にするな！」ってw

cakePHPを利用したデータのやりとりを勉強してるんですが、
リクエストを送っても何も戻ってこないんですが
modelフォルダの中に何も入れてないのがいけないのでしょうか？
教本にはcontrollerのファイルとcomponentのファイル、ctpファイル、と合計3つしかファイル作ってないんですが・・・

>>478
とりあえず
・cakephpのインストール完了画面を出す
こんな感じの
・controllerだけでhello worldを出す
この2点をやるのが先だ

>>477
まぁ定数だからな。

>>479
やってみます！ありがとうございます。

484ですが、インストール画面を出すことには成功しました。
ただ、ググったサイトを参考にHello_World_controller.phpをつくり、ソース↓
<?php class HelloWorldController extends AppController {
public $name = 'HelloWorld';
public $uses = array();
public $autoRender = false;

function index()
{
echo "hello world!";
}
}?>
これをapp/controllersフォルダに入れて、xxx/hello_world/にアクセスしたところ、
HelloWorldController could not be found.と言われてしまいます。
なぜ認識してくれないんだろうか、、、

>>486
度々失礼いたします。それはHello_World_controller.phpのファイル名ってことですよね。
誤字脱字がないことを確認して、もしかしてアンダーバーが悪いのかと消したりしたんですが
どうにも認識してくれません。。。↓のサイトのまんま参考にやってみたのですが、、、
http://ameblo.jp/tondemonight/entry-10117208283.html
理解力のない馬鹿ですいません。もう一息ヒントをいただけませんか。

478ですが、やっと原因がわかりました。
JSON形式で出力するはずが、HTML形式で出力されているのが原因でした。
478で言っているctpファイルで、JSON形式にエンコードする旨が書かれているのですが、
調べたところ、layoutフォルダにdefault.ctpを作ればよいと書いてあり、

[default.ctp]

<?php echo $content_for_layout; ?>

というファイルを作ったところ、確かにブラウザで直アクセスしたときの表示は変わったのですが、
javascriptからのリクエストに対するレスポンスは変わらずHTML形式のままでした。
あともう少しだと思うのですが、、、何か良い方法があればご教授ください。

IDも出ないスレで何言ってんだ

初心者のうちはたしかに命名規約で混乱することが多いね
つCakePHP 規約ワードメーカー
http://www.cpa-lab.com/tech2/inflects/

womanって入れると、テーブル名がwomenになったんだけどさ、
これってややこしいよな。それならテーブル名がwomanでもいいじゃん。

Cakeの規則に合わせるのは大事だけど、
英語得意じゃない日本人にとっては、分かりやすい形で良いと思うんだけどなあ

>>494
いや、
Aというデータがあるとして、
・Aの複数形=その中には複数のAデータがある
・Aの単数形=Aのデータ1つ

複数形は、DBでいうとテーブル。
プログラミング言語では配列。
単数形は、DBでいうとレコード
プログラミング言語では配列でない変数

複数形になれると、無意識に使うようになるよ。
英語が得意でなくても英単語覚えるのは別。
実際英単語組み合わせてプログラミングしてるんだから。

>>495
だから、それらを開発者が、あるいはその他の人間が覚える必要あるのか？
と言いたいんだ。せっかく作ったのを自慢したいのはわかるけどさ。

別にテーブル名はあくまで”識別名称”なだけだから、何だって良いんだよ。
別にCakeに従わないからと言ってエラーになるわけじゃないんだし。
womanという単語で分かるなら、womanというテーブルで良いんだ。
categoryをcategoriesにしなくても良いんだよ。categorysが誤訳でもさ

>>496
皆が１つのルールを覚えて使う事による効率というのがあるんだよね。
というかフレームワークってそういうためのもの。
使わない自由もあるけど、Cake使うならCakeのルールを覚えて使う事をお勧めするよ。
まあCookbookでpeopleテーブルととPersonモデルって見たときは、
最初は誤植か何かかと思ったよ。
そしてちょっとやりすぎだとは思う。

「皆が」って言うけど、ぶっちゃけ複数人で開発向きじゃないよね。Cakeって。

複数人開発に向いてるフレームワークって何？

>>496
あなたプログラミングに向いてないわ・・・。
自分が気にしないからって、categorysとか付けちゃう人と開発したくないな。
自分しか触らないって言うんだろうけど、
その精神は今後絶対に成長に影響する。
不特定多数が使うようなライブラリを開発することも、
複数人で開発することも、全て否定するんだよね。

>>498
一人で開発しようが、規約（＝レール）は大事だよ。
統一された規約のもと開発するのは、とても安心するし、効率的。
そのレールの上に乗って進んでいくだけになるからな。