menu
書いてる野郎
orebike@gmail.com
AppModelクラスを継承してつくるので、基本的なメソッドはある。 なので個々で使うラッパーメソッドをじゃんじゃん実装していく形。
controllerからは素のmodelの基本メソッドを呼び出すということはほぼ無い。 そのような粒度の処理をcontrollerに書かない。 かならずオリジナルのメソッドを介す。
CakePHPのfindで吐き出されるデータはすべて連想配列でメソッドが備わっていない。
操作対象の情報を引数にして操作するという形を取る。自分は2011-08現在大体変更したい対象のidと変更内容を渡して内部で引き直すという処理にしている。連想配列そのものを渡すのは整合性で考えるとよくない気がする
戻り値は欲しい値そのもの、もしくはメソッドの実行結果の成否(極力bool値)とする。DBも更新するし、そのリターンも利用するという設計にはしない。両方欲しいなら別途取得するメソッドを実装する。
文字列や数値、用途に合わせた特殊なリターンをする場合はgetHoge、find-first系と同様のリターンをする場合はfindByHoge、find-all系と同様のリターンをする場合はfindAllByHogeとする。
CakePHPのmodelはrailsのように生成系はクラスメソッドで個々のデータ操作はインスタンスメソッドみたいにわかれてない。 CakePHPのmodelはかならずnewされてから使用される前提になっているのでクラスメソッドは実装しない。
View欲するものをモデルはリターンしたくなるが、こらえてPHP言語要素でリターン。viewがJSONが欲しいからってJSONをリターンしない。 形式を決めるのはviewやcontrollerの仕事
内部で使う設定値もモデル同様に生成時にconstructで内部のメンバにモデル名そのもので格納してしまう
class Hoge{ function __construct(){ parent::__construct; $this->FUGA = Configure::read('fuga'); } }
単純に言えばSELECT句の項目を足すだけの機能。1.3から使えるっぽい。 書き方も柔軟というかそのままというか
var $virtualFields = array( hoge => "count(Piyo.gold)" );
みたいに書けばいいだけだ。hogeの部分がフィールドとして宣言されて
SELECT ,,,,,,,,,,,,,,, COUNT(Piyo.gold) AS hoge
のような記述がSELECT句に追記される。
ここはスカラー値ならなんでも放り込むことができる。
findをオーバーライドしても同様のことを実現できるがどっちのほうがいいのだろう。
find後に呼び出されるフックメソッド
public function afterFind($result, $primary){ return $result; }
通常にfindされた場合はprimaryがtrueになっている。そして$resultはそれがfind-allだろうがfind-firstだろうがどっちでも配列の形(通常のfind-all形式)で来る。
primaryがfalseの場合とはアソシエーションによって再帰的にfindされた場合でこの時は$resultにはfind-first形式で格納されている
CakePHPにはfind絡みで情報を挟み込むチャンスがいくつかあるのでこいつを使う
つけ方 | 条件 | memo |
---|---|---|
アソシエーションでくっつける | 基本PKのID絡み | findに透過的に適用される。再帰取得が柔軟になっている。PKのIDしかくっつけられない |
バーチャルフィールドでくっつける | findに | |
joinsでくっつける | 他テーブルからの結合での値引っ張りはかなり柔軟にできる。透過的に書くのは結構難しい | |
afterFindでくっつける | PHP操作になるので巨大な集合演算には向かない | |
単に手動でくっつける |