CakePHP1.3.6：scaffoldにバリデーション(Validation）を適用する。

CakePHPを勉強し始めて、Strutsが登場した頃の感覚がよみがえるのだが、決定的に違うのが、モデル（DAO:Data Access Object）にバリデーションを実装する点。
Strutsだと、印象としては画面の入力に対してバリデーションを行い、コントローラーでさばく。StrutsはMVC2モデルの代表的なフレームワークだが、そこでいう「モデル」はビジネスロジックを意味していて、DAOについては明確な規程はない。これに対して、CakePHPでいう「モデル」は、ビジネスロジックより下位のDAOをさしていて、JavaEEでいうところのEntity Beanに近い印象。

アーキテクチャ的には、コントローラーの下位にDAOを持ってきて、ビジネスロジックからデータアクセスを切り離すことには賛成で、会社で利用していたフレームもそのように設計していた。そうすることで、開発の分担が楽になる。
このとき、Struts的なバリデーションのハンドルだと、どうしてもコントローラーとその周辺の結合が強い感覚がある（極端な例になるが、過去にバリデーションを「ビジネスロジック」だと勘違いしたSEリーダーが、コントローラー・インスタンスをビジネスロジックに引き渡すという設計をしてしまったことがある）が、CakePHPのように割り切ってDAOにバリデーションを設定すると、この結合を断ち切ることができる。
バリデーションの多くは、テーブルカラムに関わるルールと密接に関係しているから、この方がリーズナブルのように感じる。

その端的な例が、scaffoldにバリデーションを適用できることと思う。

モデルの修正

先の例のモデルにバリデーションを設定する。

<?php 

class Customer extends AppModel {
	public $name = 'Customer';	
	public $validate = array(
				'name'=>array(
					'rule' => 'notEmpty',
					'message' =>'入力してください')
	);
}

?>

コントローラーの作成

コントローラーには何も変更はない。

<?php

class CustomersController extends AppController{
	public $name = 'Customers';
	public $layout = 'myznala_scaffold';
	public $scaffold;
	
}
?>

確認

以下は、addアクションにおいて、nameフィールド未入力のまま登録ボタンを押したところ。
キチンとエラーメッセージが出力されている。おまけにラベル脇に赤い「*」まで出てくれる。