>>550
質問に対してこれでできんじゃね？って方法を書いただけだから、
こっちに問題はないけど。

この板、IDでないから誰が何喋ってんのか全く分からんｗ

ところで、ClassRegistryが出てきたからついでに聞きたいんだけど、
new Hoge()じゃなくてClassRegistry::init('Hoge')が推奨されるのってなんで？

昔コントローラーじゃないところでモデル使うことがある時、
new Hoge()してるって言ったら、だめって言われたことあるんだけど、
まだ初心者だったら理由までは教えてもらえなかったんだよね。
よくわからないまま、ClassRegistry::init()を使うようにだけしてるんだけど、
理由知りたい。

newしたら初期化されるじゃん

phpunitのテスト駆動開発について。
テストを先に書くということですが、
メソッドを先に書く場合もありますか？

また、掲示板サイトを作る場合、
記事を書く
記事を見る
記事を削除

の3つのケースを先に書いてテストし実装する
もしくは一つの機能ごとにテストを書く実装する、のどちらが良いのでしょうか。

>>556
テストを先に書くことがテスト駆動開発の必須条件の一つだと思うんだけど、
別に原理原則にこたわることもないと思われ。
ただ、教科書的にはまずテストを書いて赤色から発進するのが通則。

>>556
テスト駆動開発は、一般的にはアジャイル開発の一部とされている
（たぶん、そうじゃない場合もあるはずなんだけどあまり記憶に無い）ので
単純なテストからだんだん複雑にして行くことを前提に、
最初は簡単な「記事を書く」テストを書いて実装して
簡単な「記事を見る」テストを書いて実装して、
簡単な「記事を削除」テストを書いて実装して・・・ってことなんじゃないかな？

だけどそれも程度によるだろうから、最初はざっくりアウトライン的に
全体を作って、作りこむに従って単体テストを増やしていったりテスト自体を
詳細にコーディングするってことでいいんじゃないかな？

>>557
ありがとうございます！
勉強になります。

まぁ自分で書いておいてこんなこと言うのもあれだけど、
TDDに限らず、ここで聞くより専門の書籍を一冊買って
それを読んで体系から身につけたほうがいい。

画像のバリデーションで、画像をアップロードしていない場合は
バリデーション自体を中止したいのですが、良い方法はないでしょうか？
以下のようなルールをモデルに書いています。

'image' => array(
　array(
　　'rule' => array('extension', array('jpg', 'jpeg', 'gif', 'png')),
　　'message' => '拡張子が違います',
　　'allowEmpty' => true,
　)
)

営業 hasOne 顧客 というアソシエーションを一時的に張って、
検索条件を
'顧客.id' => null
とすれば行ける気がするのだがどうだろう。

あと、カウンターキャッシュという裏ワザもあるが、
アプリケーション依存になるんで一長一短。

>>562
なるほど！試してみます。ありがとうございます。

クックパッドってCake使ってるのかな？
なんかURLのルールが似てる気がする

>>564
Railsじゃなかった？今は知らんけど

ああ、Railsだから似てると感じるのか

AppControllerを継承したクラスを継承したコントローラで
AppControllerに書かれた$uses、$componentsが使えない（マージされない）問題は
Cake2では直ってるんだっけ？
今確認できないのでどなたか教えてください

>>569
Dispatcher でリフレクション呼び出してあれこれゴニョゴニョしてるんで、
多分大丈夫。
正式なアナウンスは知らん。

>>569
その問題、今初めて知ったわ。

久しぶりに自分が作った1.3のソース触ったけど、糞すぎて情けなくなる・・・

オレの1.2のコードをやるから、その汚い糞を拭き取れ。

カテゴリの状態を維持したまま別のコントローラーを実行するための
ルーティングってどう書けばいいですかね？

/hoge/　→Categoryモデルのname「hoge」
/hoge/news/　→Newsモデルのcategory_nameが「hoge」
/hoge/news/detail/1　→Newsモデルのidが1でcategory_nameが「hoge」

こういう場合、hogeの箇所（カテゴリ名）が不特定文字列なので
どういう書き方をすればいいか悩んでいます。cake2系です。

Router::routes(array('/:category/'), array('controller' => 'categories'));

Router::routes(array('/:category/:controller/'));

Router::routes(array('/:category/:controller/detail/:id'));

でどう？

あと、第三パラメータで正規表現でのフィルタリングができるんで、
3つ目のURLパターンにおいてIDは数値と決まっているなら

Router::routes(array('/:category/:controller/:id'), array(), array('id' => '[0-9]+'));

とすることで

/hoge/news/1

をマッチさせることが出来ると思う。

問題ない。
ルーティングは単純な正規表現を先頭からマッチさせていくだけ。
で、最後の最後に通常のマッチングがコアの方に用意されている。

あ、問題あるわ。すまんｗ

>そういう場合は、固定のコントローラーを
>ルーティングに書いていけばいいんですかね？
>Router::routes(array('/contacts/:action'), array('controller' => 'contacts'));

そうですね。

>>580
ということは、固定のコントローラーは全てルーティングに書く必要があるんですね。
そうなるとあまり利便性が良くないですね。

>>581
カテゴリ名を自由にするってことは、特定の文字を禁止にするんだろうから、
それを表現できるパターンを第3パラメータに書けば良いと思うよ。
たとえば ["member", "user"] というコントローラを作るんなら

$route = '/:controller/:action/*';
$default = array();
$options = array('controller' => '(member|user)');
Router::connect(compact('route', 'default', 'options'));

あと、アクションを設定しない場合に index を適用させるなら

$route = '/:controller';
$default = array('action' => 'index');
Router::connect(compact('route', 'default'));

を最初に加えておく。

あとすまん、
上で Router::routes() っていうのは Router::connect() の間違いだった。すまん。

>>583
ありがとうございます。色々工夫してやってみます。

>>584
ありがとうマジで助かった！

RailsとCakeでMVCを覚えたせいで見事に騙され、モデルはテーブルに紐付くもんと思ってたわ
テーブル関係ないビジネスロジックをどこに書くか迷って、コンポーネントに書いてたけど
モデルに書いた方がいいんだろうか？

>>587
ビジネスロジックをモデルに書くのは常識だ。
コンポーネントに書いたほうが良いなんて聞いたこと無い。
Rails も Cake もその点においては何も騙してねーと思うよ？

テーブルをまたがる共通処理や、似て非なるテーブルに同じ処理をしたい場合に、ロジックを置く場所がないて話だと思うけど。
そういう場合にRailsの1モデル-1テーブル形式は破綻してるのは確か。

「具体的に言うと、モデルはデータベースのテーブルを表しますが」
http://book.cakephp.org/2.0/ja/models.html
とあるせいで、モデル＝テーブルに紐付く（原則として）と思ってたよ
市販の解説書も同じような感じで書いてる

>>588
モデルの中で他のモデルをClassRegistry::initとかやりたくないんだよ
コントローラに書きたくなければコンポーネントになる

RailsにしてもCakeにしてもActive RecordないしTable Data Gatewayパターンを利用するクラスをModelと命名して
データベーステーブルと（さらにはコントローラとも）１対１対応しなきゃいけないように見えるから勘違いしやすいんだよな

Railsは１つのモデルに関するロジックは"モデル"クラスに書けるけど
Table Data GatewayのCakeはこれすらコントローラやヘルパーに溢れ出やすい印象

複数"モデル"が絡むときに簡易サービス層として利用されやすいのがコンポーネントなのかな
コントローラから呼びやすいしファットコントローラの一番楽な回避策だろうし


初心者でも（本来の広い意味での）モデルの中にサービス層を作りやすい実装や解説にしておいてくれるとありがたいんだけど

>>593
なんだその理由ｗｗ

>>595
何がおかしいんだ？

>>589

>似て非なるテーブルに同じ処理をしたい場合
これはビヘイビアがいい気がする。

前もこの話題出たよな
結論は出なかった

作るものの規模とかで最適な構成は変わるしね。
>>594 のいうサービス層が必要になる規模は、CakePHPではちょっと対象外なんじゃないかと思ってる。
CakePHPの中の人がどう思って作ってるかはしらんけど。

複数モデルにまたがる処理をコンポーネントに書いている人は
$useTable = false の別のモデルを作った方がずっと楽だと思うんだが。

コントローラから直接参照できる点は一緒。
データのセット、バリデーション、フォーム値の復元。
使うモデルを $hasOne とか入れとけば ClassRegisry::init も呼ぶ必要ない。