2013の8日目です。昨日は、@LandscapeSketchさんの「FuelPHP開発でローカルとWebで構造が変わっても対応できる小技」でした。FuelPHPを更に使ってみて使えるなと思った拡張ValidationRuleの書き方とCore拡張の小技タイトル長っwCMS系のサイト構築は大体どのフレームワークでも問題ないのですが、基幹業務チックな機能要件があると、様々なモデルの組み合わせで入力値の検証をしたりだとか、項目間において依存性のあるチェックだとかが頻発します。PHPで基幹システム作らない方が・・・というご意見もごもっともで、そのうちもっとナウい言語にシフトしていきたいと思います。本題に戻るとFuelPHPはその辺が結構柔軟で、やりようによってはいくらでも対応できるので、一年半ぐらい実プロジェクトで使ってきましたが困ることは特になかったです。いえば、ORMでrelatedしてrows_limitするとあばばばってなりますが、クエリビルダとORMの勘所も掴んだので特に問題ありません。1.おさらい公式ドキュメント(日本語訳)デフォルトの入力検証含め、こちらに書いてある内容でほとんどの入力値の検証は可能です。'users.username');以下のようにして書くと、わざわざパラメータをデリミタで区切らなくても引数として渡すことができます。デリミタつけなくても渡せます3.独自バリデーションはバリデーションクラス作らなきゃダメですか?答えはノー。再利用性のあるもの(汎用的な独自バリデーション)はクラスにしておいた方が後々使い回しがききますが、例えばログイン検証なんかは再利用しませんよね?バリデーションクラスを作らずに独自ルールを定義するにはClosureを使います。'ログインに失敗しました。$val;}検証ルールにClosureを使う場合の落とし穴Closureで複数のルールを定義するとValidation::active()->set_messageで定義したメッセージがおかしなことになります。以下のサンプルを見てください。検証に失敗する2つのルールをClosureで定義します。});この検証を実行すると以下のようなエラーが出力されます。2後に定義した方のメッセージが先に定義したclosureのメッセージを上書きしてしまうんですね。公式ドキュメントを読むとそれらしいことが書いてあるのですが、こういう場合はClosureのルールに名前をつけてあげるといいらしいです。}]);見てわかるとおりClosureのルールをキーとClosureの連想配列でadd_ruleに渡してあげます。するとFuelPHPの中で「このClosureのルールで検証に失敗したらこのメッセージを表示する」というような関連づけが行われるようになります。4.Core拡張の小技ついでの小ネタ。拡張バリデーションを定義する際、デフォルトのルールにないけど汎用的な検証を行うというケースがあると思います。汎用的な独自ルール数カ所から呼ばれるならこれでもよいかもしれません。__DIR__.'/classes/core/view.php',));これでadd_callableしなくてもバリデーション定義に汎用ルールが使えるようになります。同じ要領で汎用的なViewの表示処理やデータ整形などもViewクラスを拡張するとDRYできるようになります。}}そんなこんなで「もうバリデーションなんて怖くないぞ」という感じにまとまりました。最後にコミュニティも盛り上がり、各地で実績が増え、弊社でもFuelPHPが定着化してきました。私自身PHP歴は2年弱、FuelPHPは1年半とPHPを初めて間もなくFuelPHPと出会いました。状態だったのですが、FuelPHP選んでよかったです(笑)明日は、@kenji_sさんの「AspectMockでFuelPHPのアプリを100%テスト可能にする」です。康幸@ya-sasaki道端で踊れるDeveloper。アプリケーションアーキテクト、ソフトウェアアーキテクト(と名乗ってみたい)。