ありがとうございます。

>>33
なるほど、専用のクラスがあるんですね。
というか、Cookbookに載ってますね。勉強不足でした。

>>34
最初その方法を考えたんですが、前述のとおり違和感があったので悩んでました。
でも結構メジャーなWordPressがその方法を取っているってことは、パフォーマンス的には良い方法なんですかね？

WordPressの開発思想は独特だよ。
DRYを積極的に無視してクラスもなるべく作ってない。
メリットは、入り組んだクラス呼び出しや
汎化してぱっとみなんの処理か分かりにくいコードが少ない。
だからプログラミングが苦手な人でも、改造したいところを変えれば、
あまり他に影響させずに改造できる。
デザイナーなどの支持を得ての普及だね。
それもひとつのやり方だけど、
コードが読みにくいし俺はあまり好きじゃないな。

設定がDBにあるのは、そういった考えの下、
管理画面から変更できるようにするためだろうね。
WordPressは基本的に設定ファイルを変えて、アップロードとかする必要が無い。

>>51
パフォーマンス的にはSQLを一回投げる分悪くなりそうだけど、
>>52の言うように、管理画面からいろいろ設定を変えたりすることを考えると
DBで保持してた方が更新が楽な気がするなあ
「絶対固定！」って値ならファイルのどこかに書いちゃってもいいと思うけど

まったくお勧めはしないけどね。
WordPressはオープンソースで配布して使うから、
ブログ名の設定が管理画面から出来る必要があるだけだし。
そういう設定なんて早々変更はしないでしょ。
開発者が設定ファイルを変更するなんて簡単だし、
DBに入れるほうが余計なトラブルの元さね。
設定をDBに入れると、開発中のデバッグで泣きを見ると思うよ。

そうそう。外部ファイルにまとめられるならその方が良い。

俺は、サイト用の設定はDBでとアプリ用の設定はファイルでって言う風に分けてるよ。
使い回しする時に楽だからね。

サイト名とかサイト説明とかそういうのはDBで管理画面からいじれるように。
画像置き場のパス設定だとか外部APIのTokenみたいなのは設定ファイルに入れとくって感じで。

>>58
Configure::storeを上手く使えばok？

http://logsoku.com/thread/pc11.2ch.net/php/1229669539/935-944
だめっぽいですね。結局DBか…。

セッションをDBに保存している場合、
定期的(?)に古いセッション情報を削除しているらしく、
そのタイミングでDB側が処理に詰まってしまう。
誰か解決方法教えてください。

通常のフォルダとSSL用のフォルダに分かれてるサーバーの場合、
どうやって配置すればいいんだろう？

これ使えないね、初心者用

だめですね。
「他の条件以外」を完全に満たしていて、「他の条件」を満たしていない時にsaveされてしまいますね。。。（当たり前か・・・）

全然読んでないけど落ち着いてマニュアルじっくり読んでこいよ。

ちょっと疑問に思ったんだが

CakePHPであることを隠蔽するってあったけど、どうしてもコントローラ名(URLの一部)が複数形の単語だったりで、特徴あるからすぐバレるよね？

かといって命名規則を無視出来んし

それって特徴か？

アソシエーション組む時って
リレーション先のテーブルのモデルのphpファイルも用意してやらなきゃいけないの？
リレーション元のモデルからbelongsToとか使えば特に要らない？

なぁ、前から疑問に思ってたことなんだが、
なんでCakePHPはControllerにビジネスロジックを書いちゃうの？
MVCとかちゃんと理解して作ったとは思えないんだよね。

ちゃんとModelにロジックかいてる人も居るよ

マニュアル読んでると、

コントローラ名
モデル名(ただし単数系)
ビューのフォルダ名

DBのテーブル名

を統一しろ！的になってますが

UsersのDBテーブルに対して、同じ名前のコントローラー、モデル(単数系)、ビューのそれぞれを持っていたとします。

ただしhttp://www.hoge.com/registrations/として、

registrations_controller.phpとregistration.php上でメインでUsersテーブル(外部モデル)を扱うことって可能ですか？

もちろんregistrationsというテーブルは一切持たないものとして、usersテーブルのレコードを処理するためだけのコントローラーです。

CakePHPのctpを使いたくないです
テンプレートと入れ替える方法どこかに載ってないでしょうか

>>75
MVCに慣れていない最初はControllerに書いちゃいがち。Controllerは動きがわかりやすいからね。
そのうちああこんなのモデルに書いた方がいいだろ。って気がつく。

>>83
例えば、どんな例？

誰かキャプチャを実装してる人いる？

ReCaptchaは王道だけど会員にならないといかんし、
KCaptchaは地味過ぎる
Securimageが一番いいけど、他の人のブログ参考にしても、マトモに動かん

チェックボックスAとB、テキスト入力CとDがあって、
チェックボックスAが選択された場合テキストCが必須
チェックボックスBが選択された場合テキストDが必須

のようなvalidateはどうかけばええでしょう？

普通にbeforeValidateにifで書けば？

>>88
ありがとう
ちょっと試してみます

>>77と同じ疑問を持ってるんだけど
Controllerがテーブル名っておかしくね？
他のテーブル使う時どうすんのよ？
てゆーか、普通コントローラはユースケース毎に付けね？

推奨されているやり方であって、強制力はないわけだし、
自分のやりやすい形でやればいいじゃん。
ビジネスロジックもコントローラに書くことはできるわけだし。

少なからず、コントローラとモデルの名前が一緒だったら、
このコントローラは、このモデルに関する物だなと直感的にわかる

キャプチャとか使う方が面倒なもん入れないでくれ、読めねーんだよあれ
無能な技術者が思いついたとしか思えんアホみたいな仕様だよな、あれ
10年後は誰も使ってなくて「昔あんなんあったよねーキャハハ」って笑われてるよ

キャプチャは甘え

メール欄の確認があってしかもコピペ不可だとぶん殴りたくなるよね

Cakeの導入を検討してるのですが、一つ質問させて下さい。

select user_name from users;
から取得したデータをビューで出力する際、テンプレートで例えばですが、

<?php foreach (...): ?>
<?php echo h($data['user_name']) ?>
<?php endforeach; ?>

のような制御が必要ですよね。
Cakeって配列の命名はcamelCaps形式だと思うのですが、カラムがuser_name (アンダースコアを含む) の場合、
配列のキー名はsnakeCase形式になりますよね。
命名規則がバラけると思うのですが、その辺りどちらかに統一するとか指針はあるのでしょうか。

>>97
テーブル名をuser_nameじゃなくてusernameにするのがいいです。
HABTMの時に頭がごちゃごちゃになります。

無理ならInflectorを通してみて確認するといいよ。
どっかにそういうサイトもあったけど忘れた。

ああごめん。カラム名はなんでもいいです。

HogeUser,MogeUser,PogeUserというモデルがあって、
それぞれのユーザー同士で1対1の簡易メッセージの送受信をさせたい時、下記のような設計で問題無いでしょうか？

■モデルのアソシエーション
HogeUser hasOne Mailbox
MogeUser hasOne Mailbox
PogeUser hasOne Mailbox
Mailbox HATBM Message

■DB
mailboxes:
id

mailboxes_messages:
mailbox_id
message_id
sended (true=送信側, false=受信側)
opened(true=開封済, false=未開封)

messages:
id
title(件名)
body(本文)
created

*_usersテーブルはそれぞれmailbox_idフィールドを持っています。
*_usersはそれぞれ構造が全く異なるのでusersとして統一させることはできません。