>>649
languagesテーブルはレコードが4行のみ？これから増える場合とかありますか？

>>647
いくつか方法思いついたけど、根源の「listとeditだけで気になるほどソースが長くなる」症状がどういうものかが分からんからなんとも言えん。
確か、CakePHPを使う人が勘違いするパターンとかいう話であったが、本当はモデルに実装するべき処理をコントローラーに置いてしまっていないか？見てみるといいかも

>>649
何のために言語分けるのか分からんのだけど、localeは使わないん？

>>648
mypageというテーブルがあるのではなく、
mypageと言うのは、マイページ＝会員専用のページという意味です。
diaryはタイトルとか内容がある、普通の日記です。（例として出しました）
>>652
findを書くだけでも1つのコントローラーに書いていけば長くなりませんか？
あと、652さんのレスを見ると、私の質問でいうと
「diary_list」とか「diary_edit」にするのが一般的なのでしょうか？

ソースが長くなっても視認性は劣りますが、
「みんなそうしてるよ。気にするな」であれば良いのですが・・。

他に何か例があった気がするんだけどとりあえず
http://d.hatena.ne.jp/hiromi2424/searchdiary?word=cakephp%20behavior
^ここのがモデルをカスタマイズする上でかなり参考になると思う。

>findを書くだけでも1つのコントローラーに書いていけば長くなりませんか？
^については、条件多ければそりゃ長くなるだろうけど・・・おいらのとこだと受け取ったパラメータ配列をfindに渡すくらいの長さになるかな。
よほどそのメソッドにおいて特殊な事をするんでない限り、モデル側に出す、というのが「良い」パターン、という感じみたいだ

そもそもfindを組み立てるのはモデルでやって
結果をコントロールで受け取って、ビューに渡す

[HogeModel]
public function latestComments{
return $this->find('all', array(...));
}

[HogesController]
public function index()
{
$this->set('models', $this->Hoge->latestComments())
}

みたいな。

最初はbakeで焼いてみればいいのに。
基本的にはこんな感じなんだな。ってのがbakeで生成されたコードみればだいたいわかるしょ。

なんでうちのエンジニアbakeつかわねぇんだろ。

>>654-655
findの書き方は別として、私が悩んでいるのは
>「diary_list」とか「diary_edit」にするのが一般的なのでしょうか？
という部分であったりもします。

>>655さんのレスを見ると、diary_list・diary_editみたいなアクションを
コントローラーに作成していくパターンで良いのかもしれませんが、
普通は、「機能名_動作」というアクションにするので、
ここに違和感があるわけです。

この部分に関して言及されていないので、
気にしなくても良いのかもしれませんが、
気にしないとURLが変わるので、私としては気になります。

すみません。上記の文が変なので書き直します。
----------
>>654-655
findの書き方は別として、私が悩んでいるのは
>「diary_list」とか「diary_edit」にするのが一般的なのでしょうか？
という部分です。

>>655さんのレスを見ると、diary_listやdiary_editみたいなアクションを
コントローラーに作成していくパターンで良いのかもしれませんが、
普通は、「機能・コンテンツ名＝コントローラー」「動作＝アクション」になるので、
diary_listみたいに1つのアクションにするのは違和感があります。

この部分に関して言及されていないので、
気にしなくても良いのかもしれませんが、
気にしないとURLが変わるので、私としては気になっています。

CakePHP2使ってる人いる？

3なら使ってるよ

ページを移動するたびにSQLを発行して読みに行ってるのですが
function内で設定した内容を次回に持ち越す
というような事をするにはどうすればよいのでせうか？

▲保存されたデータがあるか
┃保存されたデータの呼出し
╋━━━━
┃SQLの発行
┃呼び出したデータの保存
▼
みたいな

>>660
趣味程度に使っているよ

1.3 で質問なんですが、
例えば Test1 テーブルと Test2 テーブルがあったとして、
この2つのテーブルから Test1, Test2 それぞれでなく、
あわせて新着順に10個の項目を取得する方法はありますでしょうか？

結合して時間をキーに降順かけてから10個取り出せば良いんじゃないの

参照（SELECT）だけなら2つのテーブルのviewを作った方がすっきりすると思う。

>>662
cache
普通はよくアクセスするページの保存に使うが、sqlの結果そのものを保存する場合にも使っちまおう、というのも見かけた事がある。ADOdbの確かメソッド名のどこかにcacheとか名前ついてるやつ。

だがまぁ、ふつうは次回に持ち越すなどと考えないでpagenationを使うもんだ

自分が考えた流れ図通りに作れないとモチベーション一気に下がるよね

>>667
Aを表示(SQL読み込み)→B表示→ページ移動→A表示(再読み込み)
って流れになってるから
Aを表示(テーブル保存)→B表示→ページ移動→A表示(保存したテーブルから読み込み)
っていうのをやりたい

モデルにfindを書いているのですが、
コントローラーからfindの結果を取得して
それをpaginateにしてビューに渡すと言った事が出来るのでしょうか？
もし出来る場合はソースの書き方を教えて下さい。

function index(){
$data = $this->paginate();
$this->set('data',$data);
}

自分はこう書きます
function index(){
$this->paginate = $this->ModelName->methodName();
$this->set('data', $this->paginate());
}

>>671-672
それは普通にコントローラーでpaginateしてるだけですよね？
そうではなくて、findの箇所はモデル内で作成しています。
それを取得してpaginateのfind箇所を置き換えられないかと思い質問しました。

#test_controller
$list = $this->Test->getFind($options);
$this->set('test_list', $this->paginate($list));

こういうイメージです。（もちろんこれでは動きませんが...）

>>673
モデルの中で自己流でfindをオーバーライドしてるなら
_findAll,_findCount,_findFirstあたりもきちっとつくらねばならん。
この辺はPagenateがどういう動きをしてるか、Modelクラスのソース追って下さい。

流れ図は思い浮かぶんだけど表現する方法がないのがもどかしいぉー
ずーっとJavaやってたからJavaベースで思い浮かぶのがそもそもの敗因

規模が大きくなると、ビューだけでもlayoutやelement数が増えるよね。
1つのファイルにif入れたり、コントローラーからsetするのも限界があるし。
（ソースが汚くなって見づらいから、ファイルを分けた方が視認性が良くなる

>>673
findしたデータをpaginateするんじゃなくて、paginateにSQLを渡すイメージ
じゃないと、findで余計なデータをメモリに持っちゃうじゃん

http://book.cakephp.org/ja/view/1237/カスタムしたクエリによるページ付

ごめんURLおかしかったかも
http://book.cakephp.org/ja/view/1237/%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%81%97%E3%81%9F%E3%82%AF%E3%82%A8%E3%83%AA%E3%81%AB%E3%82%88%E3%82%8B%E3%83%9A%E3%83%BC%E3%82%B8%E4%BB%98%E3%81

>>677-678
ありがとうございます。参考にします。

>>673
672を書いたものですけど、勘違いされてるようなのでもう少し詳しく書くと

モデル :
function methodName($user_id)
{
return array(
'fields' => array('...'),
'conditions' => array('ModelName.user_id' => $user_id),
'order' => array('Hoge.id DESC'),
);
}

コントローラ :
function index(){
$this->paginate = $this->ModelName->methodName($this->Auth->user('id'));
$this->set('data', $this->paginate());
}

みたいな感じです
あなたがいうモデルでfind組み立てて、コントローラでpaginateに代入し、ビューに渡すという流れです

>>680
せっかく説明していただいたのに申し訳ないのですが、希望は違います。
findだけで済む箇所とpaginateまで生成したい箇所があるので、
コントローラーでそれを操作したいと思い、>>670のように質問しました。

680さんのは基本的なオプション指定だけをモデルに書いて
それをpaginateに渡すイメージですが、そうではありません。

なるほど。こちらの勘違いでした。すみません。

以下が妥当かと。

モデル:
public function getFind($paginate=true)
{
$criteria = array(
'fields' => array(...),
'order' => 'Word.id DESC',
);

if ($paginate)
return $criteria;
else
return $this->find('all', $criteria);
}

コントローラ:
public function ページネーションするアクション()
{
$this->paginate = $this->ModelName->getFind();
$this->set('models', $this->paginate());
}

public function ページネーションしないアクション()
{
$models = $this->ModelName->getFind(false);
$this->set(compact('models'));
}

>>682
ありがとうございます。ぜひ参考にさせていただきます。

viewとcontrollerで共通の処理はどこに置けばいいのかね？
今はhelperに書いてcontrollerからも読み込むようにしてるけど普通？

>>684
興味なのだが、viewとcontroller共通の処理って何？
その2つで共通なら、逆にmodelに書くべきと思うが。

cakephp初心者です。

コントローラクラス内で各メソッドがデータを共有操作できるメンバー変数のようなものはもてないでしょうか？
例えば、indexが呼ばれるたびに1加算されて表示されるようなことがしたいです。以下の方法はダメでした

public $ii = 0;
fanction index() {
　　echo $ii;
　　$ii++;
}

$iiのデータが共有されるのは全ユーザではなく、ユーザ単位である必要があります。

厳密には共通の処理じゃなくて、viewでpackしたものをcontrollerでunpackするような処理なんだけどな
modelも違うかな…そもそも設計間違ってるのか

>>686
セッション

>685
質問元と違うが、controllerの方でパンくずリストを登録して、viewの方で表示する場合など

・画像が投稿されているか否か調べる
・投稿されていたらその画像を表示。そうでなければno_image.gifを表示

という2つの処理をするだけでもviewに書いていくと汚くなるんだよな・・・
だからヘルパー作るかコントローラーでfind後に再処理する方が良いと思う

フォームで送信された値を参照するときにつかう　$this->data と $this->paramsの違いがよくわかりません。
これらは違いがあるのでしょうか？

リクエストがPOST　→ $this->data
リクエストがGET　→ $this->params

え、POSTだけどparams使ってるわ
間違いなの？

ヘルパーってビューがプログラムで汚れそうなときに使えるのか
ifとか

URLの
コントローラー名/アクション名/引数
の引数の部分にファイル名を渡したら、.jpgなどの部分だけ削除されてコントローラーが受け取ってしまう
どうすれば拡張子の部分も受け取れますか？URLエンコードしても同じだった

>>690
そういうのはafterFindでいいんじゃね？

>>696
どういう風に>>690をafterFindするんだ？

>693
bakeしてみたコントローラ見てみるとif ($this->data) などという風に使われている。「出来るから間違いじゃない」という意味では間違いじゃないんだろうが、CakePHPの規約としてはdata使うようになってるみたいだね。
(cookbookだかチュートリアルのどこかにフォームのデータを一元化する為にdataを使うのが正しい、というような事が書いてあった希ガス）

>>697
696じゃないけど、viewに渡すデータ自体の画像の部分をno_image.gifに置き換えちゃうってことじゃないの？
そうすればデータには必ず画像が入ってるからviewはすっきりする。
ただ、MVCの役割を考えるとそこでやるべきかどうかは考えた方がいいかもね。

>>664 なんですが、
>>665で言われてる結合する、というのがよくわからないんです。
find の第2引数で 'joins' というのがありますが、
これだと 'conditions' でそれぞれのテーブルの対応するフィールドの値を入れてやって関連づけを行わないといけないですよね？
SQL はほとんどわからないので、的外れなことを言ってるかもしれませんが、
2つのテーブルを関連性などなしで単純に全て混ぜてしまって作成日で降順をかける、なんてことは可能でしょうか？
詳しく解説などされているサイトなど教えてもらえると助かります。