イントロダクション

Laravelは入力されたデータに対するバリデーションの様々なアプローチを提供しています。Laravelの基本コントローラークラスはパワフルでバラエティー豊かなバリデーションルールを使いHTTPリクエストをバリデーションするために便利な手法を提供している、ValidatesRequestsトレイトをデフォルトで使用しています。

クイックスタート

パワフルなバリデーション機能を学ぶために、フォームバリデーションとユーザーにエラーメッセージを表示する完全な例を見てください。

ルート定義

まず、app/Http/routes.phpファイルに以下のルートを定義してあるとしましょう。

// ブログポストを作成するフォームの表示…
Route::get('post/create', 'PostController@create');

// 新しいブログポストを保存…
Route::post('post', 'PostController@store');

もちろん、GETのルートは新しいブログポストを作成するフォームをユーザーへ表示し、POSTルートで新しいブログポストをデータベースへ保存します。

コントローラー作成

次に、これらのルートを処理する簡単なコントローラーを見てみましょう。今のところstoreメソッドは空のままです。

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class PostController extends Controller
{
    /**
     * 新ブログポスト作成フォームの表示
     *
     * @return Response
     */
    public function create()
    {
        return view('post.create');
    }

    /**
     * 新しいブログポストの保存
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        // ブログポストのバリデーションと保存…
    }
}

バリデーションロジック

これで新しいブログポストに対するバリデーションロジックをstoreメソッドに埋め込む準備ができました。アプリケーションの基本コントローラー(App\Http\Controllers\Controller)クラスを調べてみれば、ValidatesRequestsトレイトを使っているのが分かるでしょう。このトレイトは全てのコントローラーに対して、便利なvalidateメソッドを提供しています。

validateメソッドはHTTPリクエストとバリデーションルールを受け取ります。バリデーションに適合するとそのまま続けてコードが実行されます。しかし、バリデーションに失敗すると例外が投げられ、適当なエラーレスポンスが自動的にユーザーに送り返されます。伝統的なHTTPリクエストの場合はリダイレクトが生成され、AJAXリクエストの場合はJSONレスポンスが送られます。

validateメソッドをもっとよく理解するため、storeメソッドに取り掛かりましょう。

/**
 * 新しいブログポストの保存
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $this->validate($request, [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // ブログポストは有効なので、データベースに保存する…
}

ご覧の通り、HTTPリクエストと希望のバリデーションルールをvalidateメソッドに渡しているだけです。繰り返しますが、バリデーションに失敗すれば、適当なレスポンスが自動的に生成されます。バリデーションに合格すれば、コントローラーは普通に実行されます。

ネストした属性の注意点

HTTPリクエストに「ネスト」したパラメーターが含まれている場合、バリデーションルールは「ドット」記法により指定します。

$this->validate($request, [
    'title' => 'required|unique:posts|max:255',
    'author.name' => 'required',
    'author.description' => 'required',
]);

バリデーションエラー表示

ではやって来たリクエストの入力が指定したバリデーションルールに当てはまらなかった場合はどうなるんでしょう? 既に説明した通り、Laravelは自動的にユーザーを以前のページヘリダイレクトします。付け加えて、バリデーションエラーは全部自動的にフラッシュデータとしてセッションへ保存されます。

GETルートのビューへエラーメッセージを明示的に結合する必要がないことにも注目してください。これはつまり、Laravelはいつもセッションデータの中にエラーの存在をチェックしており、見つけた場合は自動的に結合しているからです。つまり、全リクエストの全ビューで、いつでも$errors変数は利用できるのが、重要なポイントです。いつでも$erroes変数が定義されていると仮定でき、安全に利用できるのです。$errorsIlluminate\Support\MessageBagのインスタンスです。このオブジェクトの詳細は、このドキュメントの後半で説明しています。

この例では、バリデーションに失敗すると、エラーメッセージをビューで表示できるように、コントローラーのcreateメソッドにリダイレクトされることになります。

<!-- /resources/views/post/create.blade.php -->

<h1>ポスト作成</h1>

@if (count($errors) > 0)
    <div class="alert alert-danger">
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif

<!-- ポスト作成フォーム -->

フラッシュエラーメッセージのカスタマイズ

バリデーション失敗時にセッションへフラッシュデータとして保存されるバリデーションエラーのフォーマットをカスタマイズしたい場合は、基本コントローラーのformatValidationErrorsをオーバーライドしてください。Illuminate\Contracts\Validation\Validatorクラスをファイルにインポートするのを忘れないでください。

<?php

namespace App\Http\Controllers;

use Illuminate\Foundation\Bus\DispatchesJobs;
use Illuminate\Contracts\Validation\Validator;
use Illuminate\Routing\Controller as BaseController;
use Illuminate\Foundation\Validation\ValidatesRequests;

abstract class Controller extends BaseController
{
    use DispatchesJobs, ValidatesRequests;

    /**
     * {@inheritdoc}
     */
    protected function formatValidationErrors(Validator $validator)
    {
        return $validator->errors()->all();
    }
}

AJAXリクエストとバリデーション

この例ではアプリケーションにデータを送るために伝統的なフォームを使いました。しかし、多くのアプリケーションでAJAXリクエストが使用されています。AJAXリクエストにvalidateメソッドを使う場合、Laravelはリダイレクトレスポンスを生成しません。代わりにバリデーションエラーを全部含んだJSONレスポンスを生成します。このJSONレスポンスは422 HTTPステータスコードで送られます。

他のバリデーションアプローチ

Validatorを自分で作成

ValidatesRequests トレイトのvalidateメソッドを使いたくなければ、Validatorファサードを使い、バリデーターインスタンスを自分で作成してください。このファサードのmakeメソッドで、新しいインスタンスを生成できます。

<?php

namespace App\Http\Controllers;

use Validator;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class PostController extends Controller
{
    /**
     * 新ポストの保存
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);

        if ($validator->fails()) {
            return redirect('post/create')
                        ->withErrors($validator)
                        ->withInput();
        }

        // ブログポストの保存…
    }
}

makeメソッドの第1引数は、バリデーションを行うデータです。第2引数はそのデータに適用するバリデーションルールです。

リクエストがバリデーションを通過できなかった後に、セッションにエラーメッセージをフラッシュデータとして保存するためにwithErrorsメソッドを使ってください。このメソッドを使うと、簡単にユーザーに情報を表示できるようにするため、リダイレクトの後でビューに対し$errors変数を自動的に共有します。withErrorsメソッドはバリデーターかMessageBag、PHPの配列を受け取ります。

名前付きエラーバッグ

1ページの中に複数のフォームを入れている場合は、特定のフォームのエラーメッセージを受け取れるように、MessageBagへ名前を付けてください。withErrorsの第2引数に名前を渡すだけです。

return redirect('register')
            ->withErrors($validator, 'login');

$errors変数を使い、名前を付けたMessageBagインスタンスへアクセスできます。

{{ $errors->login->first('email') }}

バリデーション後のフック

バリデターにはさらに、バリデーションが終了した時点で実行するコールバックを付け加えられます。これにより、追加のバリデーションを行い、さらにエラーメッセージコレクションにエラーメッセージを追加することが簡単にできます。バリデターインスタンスのafterメソッドを使ってみましょう。

$validator = Validator::make(...);

$validator->after(function($validator) {
    if ($this->somethingElseIsInvalid()) {
        $validator->errors()->add('field', 'このフィールドで何か間違いが起こった!');
    }
});

if ($validator->fails()) {
    //
}

フォームリクエストバリデーション

より複雑なバリデーションのシナリオでは、「フォームリクエスト」を生成したほうが良いでしょう。フォームリクエストは、バリデーションロジックを含んだカスタムリクエストクラスです。フォームリクエストクラスを作成するには、make:request Artisan CLIコマンドを使用します。

php artisan make:request StoreBlogPostRequest

生成されたクラスは、app/Http/Requestディレクトリーへ設置されます。では、バリデーションルールを少しrulesメソッドへ追加してみましょう。

/**
 * リクエストに適用するバリデーションルールを取得
 *
 * @return array
 */
public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

では、どのようにバリデーションルールを実行するのでしょうか?必要なのは、コントローラーのメソッドで、このリクエストをタイプヒントで指定することです。やって来たフォームリクエストはコントローラーメソッドが呼び出される前にバリデーションを行います。つまり、コントローラーにバリデーションロジックを取っ散らかす必要はありません。

/**
 * ブログポストの保存
 *
 * @param  StoreBlogPostRequest  $request
 * @return Response
 */
public function store(StoreBlogPostRequest $request)
{
    // やって来たリクエストは正しい…
}

バリデーションに失敗すると、前のアドレスにユーザーを戻すために、リダイレクトレスポンスが生成されます。エラーも表示できるように、フラッシュデーターとしてセッションに保存されます。もしリクエストがAJAXリクエストであれば、バリデーションエラーを表現するJSONを含んだ、422ステータスコードのHTTPレスポンスがユーザーに返されます。

フォームリクエスト権限

フォームリクエストクラスはauthorizeメソッドも用意しています。このメソッドでは認証されているユーザーが、指定されたリソースを更新する権限を実際に持っているのかを確認します。たとえばユーザーがブログポストのコメントを更新しようとしているなら、本人のコメントなのでしょうか? 調べてみましょう。

/**
 * ユーザーがこのリクエストの権限を持っているかを判断する
 *
 * @return bool
 */
public function authorize()
{
    $commentId = $this->route('comment');

    return Comment::where('id', $commentId)
                  ->where('user_id', Auth::id())->exists();
}

上例の中のrouteメソッド呼び出しに注目してください。このメソッドで、例えば{comment}パラメーターのような、呼びだされているルートのURIパラメーター定義にアクセスさせてくれます。

Route::post('comment/{comment}');

authorizeメソッドがfalseを返すと、403ステータスコードのHTTPレスポンスが自動的に返され、コントローラーメソッドは実行されません。

アプリケーションの他の場所で認証のロジックを行おうと設計しているのでしたら、シンプルにauthorizeメソッドからtrueを返してください。

/**
 * ユーザーがこのリクエストの権限を持っているかを判断する
 *
 * @return bool
 */
public function authorize()
{
    return true;
}

フラッシュデータとして保存されるエラー形式のカスタマイズ

バリデーションが失敗した時にフラッシュデーターとして保存されるバリデーションエラーの形式をカスタマイズしたければ、基本コントローラー(App\Http\Requests\Request)のformatErrorsをオーバーライドしてください。Illuminate\Contracts\Validation\Validatorクラスをファイルの先頭でインポートするのを忘れないでください。

/**
 * {@inheritdoc}
 */
protected function formatErrors(Validator $validator)
{
    return $validator->errors()->all();
}

エラーメッセージのカスタマイズ

フォームリクエストにより使用されているメッセージはmessageメソッドをオーバーライドすることによりカスタマイズできます。このメソッドから属性/ルールと対応するエラーメッセージのペアを配列で返してください。

/**
 * 定義済みバリデーションルールのエラーメッセージ取得
 *
 * @return array
 */
public function messages()
{
    return [
        'title.required' => 'タイトルが必要です。',
        'body.required'  => 'メッセージが必要です。',
    ];
}

エラーメッセージの操作

Validatorのインスタンスに対しmessagesメソッドを呼びだせば、エラーメッセージを操作するのに便利な様々なメソッドを持つMessageBagインスタンスが取得できます。

指定フィールドの最初のエラーメッセージ取得

指定したフィールドの最初のエラーメッセージを取得するには、firstメソッドを使います。

$messages = $validator->errors();

echo $messages->first('email');

指定フィールドの全エラーメッセージ取得

指定したフィールドの全エラーメッセージを配列で取得したい場合は、getメソッドを使います。

foreach ($messages->get('email') as $message) {
    //
}

全フィールドの全エラーメッセージ取得

全フィールドの全メッセージの配列を取得したい場合は、allメソッドを使います。

foreach ($messages->all() as $message) {
    //
}

指定フィールドのメッセージ存在確認

if ($messages->has('email')) {
    //
}

エラーメッセージのフォーマットを指定し取得

echo $messages->first('email', '<p>:message</p>');

全エラーメッセージをフォーマット指定し取得

foreach ($messages->all('<li>:message</li>') as $message) {
    //
}

カスタムエラーメッセージ

必要であればバリデーションでデフォルトのメッセージの代わりに、カスタムエラーメッセージを使うことができます。カスタムメッセージを指定するにはいくつか方法があります。最初の方法はValidator::makeメソッドの第3引数として、カスタムメッセージを渡す方法です。

$messages = [
    'required' => ':attributeフィールドは必須です。',
];

$validator = Validator::make($input, $rules, $messages);

この例中のattributeプレースホルダーはバリデーション対象のフィールドの名前に置き換えられます。バリデーションメッセージ中で他のプレースホルダーを使うこともできます。例を見てください。

$messages = [
    'same'    => ':attributeと:otherは一致している必要があります。',
    'size'    => ':attributeはぴったり:sizeである必要があります。',
    'between' => ':attributeはminから:maxの間である必要があります。',
    'in'      => ':attribute以降のタイプのどれかである必要があります。 :values',
];

指定フィールドにカスタムメッセージ指定

時々特定のフィールドに対するカスタムエラーメッセージを指定したい場合があります。「ドット」記法を使用し行います。属性名が最初で、続いてルールをつなげます。

$messages = [
    'email.required' => 'あなたのメールアドレスを教えてもらう必要があります!',
];

言語ファイルでカスタムメッセージ指定

多くの場合、Validatorに直接カスタムメッセージを渡すよりは言語ファイルに指定したいですよね。ならばresources/lang/xx/validation.php言語ファイルのcustom配列にメッセージを追加してください。

'custom' => [
    'email' => [
        'required' => 'あなたのメールアドレスを教えてもらう必要があります!',
    ],
],

使用可能なバリデーションルール

使用可能な全バリデーションルールとその機能の一覧です。

受け入れ 日付 JSON 全指定フィールド存在時必須
アクティブなURL 日付形式 最大値 指定フィールド非存在時必須
(日付)後 相違 MIMEタイプ(ファイル) 全指定フィールド非存在時必須
アルファベット 桁指定数値 最小値 同一
アルファベット記号 桁範囲指定数値 非内包 サイズ
アルファベット数字 メールアドレス 数値 文字列
配列 存在(データベース) 正規表現 タイムゾーン
(日付)前 画像(ファイル) 必須 一意(データベース)
範囲 内包 指定フィールド値一致時必須 URL
論理 整数 指定フィールド値非一致時必須  
確認 IPアドレス 指定フィールド存在時必須  

accepted

そのフィールドがyeson1trueであることをバリデートします。これは「サービス利用規約」同意のバリデーションに便利です。

active_url

フィルドがPHPの機能であるcheckdnsrrを通して、有効なURLであるかをバリデートします。

after:日付

フィールドの値が与えられた日付以降であるかバリデーションします。日付はPHPのstrtotime関数で処理されます。

'start_date' => 'required|date|after:tomorrow'

strtotimeにより評価される日付文字列を渡す代わりに、その日付と比較する他のフィールドを指定することもできます。

'finish_date' => 'required|date|after:start_date'

alpha

フィールドが全部アルファベット文字であることをバリデートします。

alpha_dash

フィールドが全部アルファベット文字とダッシュ(-)、下線(_)であることをバリデートします。

alpha_num

フィールドが全部アルファベット文字と数字であることをバリデートします。

array

フィールドが配列タイプであることをバリデートします。

before:日付

フィールドが与えられた日付より前であることをバリデートします。日付はPHPのstrtotime関数で処理されます。

between:min,max

フィールドが指定された最小値最大値の間のサイズであることをバリデートします。sizeルールと同様の判定方法で、文字列、数値、ファイルは評価されます。

boolean

フィールドが論理値として有効であることをバリデートします。受け入れられる入力は、truefalse10"1""0"です。

confirmed

フィールドがそのフィールド名+_confirmationフィールドと同じ値であることをバリデートします。例えば、バリデーションするフィールドがpasswordであれば、同じ値のpassword_confirmationフィールドが入力に存在していなければなりません。

date

パリデーションされる値はPHP関数のstrtotimeを使用し確認されます。

date_format:フォーマット

バリデーションされる値がフォーマット定義と一致するか、PHP関数のdate_parse_from_formatを使用し確認されます。バリデーション時にはdatedate_formatどちらかを使用しなくてはならず、両方はできません。

different:フィールド

フィールドが指定されたフィールドと異なった値を指定されていることをバリデートします。

digits:

フィールドが数値で、の桁数であることをバリデートします。

digits_between:最小値,最大値

フィールドが整数で、桁数が最小値から最大値の間であることをバリデートします。

email

フィールドがメールアドレスとして正しいことをバリデートします。

exists:テーブル,カラム

フィールドの値が、指定されたデータベーステーブルに存在することをバリデートします。

基本的なExistsルールの使用法

'state' => 'exists:states'

カスタムカラム名の指定

'state' => 'exists:states,abbreviation'

さらにクエリーへWHERE節として追加される条件を追加することも可能です。

'email' => 'exists:staff,email,account_id,1'

"WHERE"節にNULLNOT_NULLを渡すことも可能です。

'email' => 'exists:staff,email,deleted_at,NULL'

'email' => 'exists:staff,email,deleted_at,NOT_NULL'

image

フィールドで指定されたファイルが画像(jpg、png、bmp、gif、svg)であることをバリデートします。

in:foo,bar...

フィールドが指定されたリストの中の値に含まれていることをバリデートします。

integer

フィールドが整数値であることをバリデートします。

ip

フィールドがIPアドレスの形式として正しいことをバリデートします。

json

フィールドが有効なJSON文字列であることをバリデートします。

max:

フィールドが最大値として指定された以下であることをバリデートします。sizeルールと同様の判定方法で、文字列、数値、ファイルが評価されます。

mimes:foo,bar,...

フィールドで指定されたファイルが拡張子のリストの中のMIMEタイプのどれかと一致することをバリデートします。

mimesルールの基本的な使用法

'photo' => 'mimes:jpeg,bmp,png'

拡張子だけを限定する必要があるとしても、このルールはファイルのMIMEタイプに基づき、ファイルの内容を読み、MIMEタイプを推測することでバリデーションを行います。

MIMEタイプと対応する拡張子の完全なリストは、http://svn.apache.org/repos/asf/httpd/httpd/trunkmime.types.htmlで確認できます。

min:

フィールドが最小値として指定された以上であることをバリデートします。sizeルールと同様の判定方法で、文字列、数値、ファイルが評価されます。

not_in:foo,bar,...

フィールドが指定されたリストの中の値に含まれていないことをバリデートします。

numeric

フィールドは数値であることをバリデートします。

regex:正規表現

フィールドが指定された正規表現にマッチすることをバリデートします。

注目: regexパターンを使用する場合はルールをパイプ(縦棒)で区切らず、配列で指定する必要があります。特に正規表現に縦棒を含んでいる場合に該当します。

required

フィールドが入力に存在しており、かつ空でないことをバリデートします。フィールドは以下の要件がtrueの場合に「空」であると判断されます。

  • 値がnullである。
  • 値が空文字列である。
  • 値が空の配列か、空のCountableオブジェクトである。
  • 値がパスのないアップロード済みファイルである。

required_if:他のフィールド,,...

引数で指定された他のフィールドフィールドが、のどれかを持っている場合に、このフィールドが入力されていることをバリデートします。

required_unless:他のフィールド,,...

引数で指定された他のフィールドフィールドが、のどれとも一致しない場合に、このフィールドが入力されていることをバリデートします。

required_with:foo,bar,...

引数で指定されたフィールドのうち、どれかが存在している場合のみ、フィールドが入力されていることをバリデートします。

required_with_all:foo,bar,...

引数で指定されたフィールドのうち、全てが存在している場合のみ、フィールドが入力されていることをバリデートします。

required_without:foo,bar,...

フィールドは、指定された他のフィールドのうちどれかが存在しない場合のみ、この項目が入力されていることをバリデートします。

required_without_all:foo,bar,...

フィールドは、指定された他のフィールド全部が存在しない場合のみ、この項目が入力されていることをバリデートします。

same:フィールド

フィールドが、指定されたフィールドと同じ値であることをバリデートします。

size:

フィールドは指定されたと同じサイズであることをバリデートします。文字列の場合、は文字長です。数値項目の場合、は整数値です。ファイルの場合、はキロバイトのサイズです。

string

フィルードは文字列タイプであることをバリデートします。

timezone

timezone_identifiers_list PHP関数の値に基づき、フィールドがタイムゾーンとして識別されることをバリデートします。

unique:テーブル,カラム,除外ID,IDカラム

フィールドは指定されたデータベースで一意であることをバリデートします。columnオプションが指定されない場合、フィールド名が使用されます。

カスタムカラム名の指定

'email' => 'unique:users,email_address'

カスタムデータベース接続

場合により、バリデーターにより生成されるデータベースクエリーに、カスタム接続を設定する必要があるかもしれません。上記のバリデーションルール、unique:usersではクエリーに対し、デフォルトデータベース接続が使用されます。これをオーバーライドするにはテーブル名に続け、ドット記法で接続を指定してください。

'email' => 'unique:connection.users,email_address'

指定されたIDのuniqueルールを無視する

uniqueチェックで指定したIDを除外したい場合があります。たとえばユーザー名、メールアドレス、それと住所の「プロフィール更新」の状況を考えてください。もちろん、メールアドレスは一意であることを確認したいと思います。しかし、もしユーザーが名前フィールドだけ変更し、メールフィールドを変更しなければ、そのユーザーが既にそのメールアドレスの所有者として登録されているために起きるバリデーションエラーを避けたいと思うでしょう。他のユーザーによって既に使用されているメールアドレスがユーザーにより指定された場合のみ、バリデーションエラーが起きてもらいたいでしょう。uniqueルールに無視するユーザーのIDを指定するには、第3パラメーターとして指定してください。

'email' => 'unique:users,email_address,'.$user->id

テーブルで使用している主キーがidではない場合、第4パラメーターとして指定子ます。

'email' => 'unique:users,email_address,'.$user->id.',user_id'

追加のWHERE節を付け加える

さらにクエリーの"where"節として追加の検索条件を付け加えることもできます。

'email' => 'unique:users,email_address,NULL,id,account_id,1'

上のルールでは、account_id1のレコードのみuniqueチェックに使用されます。

url

PHPのfilter_var関数により、URLが正しいかをバリデートします。

条件付きでルールを追加する

ある状況ではそのフィールドが入力配列の中に存在する場合のみ、バリデーションを実行したいことがあると思います。これを簡単に行うには、sometimesルールを追加してください。

$v = Validator::make($data, [
    'email' => 'sometimes|required|email',
]);

上の例ではemailフィールドが、$data配列の中に存在している場合のみバリデーションが実行されます。

複雑な条件のバリデーション

時々もっと複雑な条件のロジックによりバリデーションルールを追加したい場合もあります。たとえば他のフィールドが100より大きい場合のみ、指定したフィールドが入力されているかをバリデートしたいときなどです。もしくは2つのフィールドのどちらか一方が存在する場合は、両方共に値を指定する必要がある場合です。こうしたルールを付け加えるのも面倒ではありません。最初にValidatorインスタンスを生成するのは、固定ルールの場合と同じです。

$v = Validator::make($data, [
    'email' => 'required|email',
    'games' => 'required|numeric',
]);

ゲームコレクターのためのWebアプリケーションだと仮定しましょう。ゲームコレクターがアプリケーションに登録する時に、100ゲーム以上所有しているのであれば、なぜそんなに多く持っているのか理由を説明してもらいます。たとえば中古ゲーム店を運営しているのかも知れませんし、ただ収集家なのかも知れません。この条件付きの要求を追加するためにValidatorインスタンスへ、sometimesメソッドを使用してください。

$v->sometimes('reason', 'required|max:500', function($input) {
    return $input->games >= 100;
});

sometimesメソッドの最初の引数は条件付きでバリデーションを行うフィールドの名前です。2つ目の引数は追加したいルールです。3つ目の引数にクロージャーが渡され、trueを返したらそのルールは追加されます。このメソッドにより複雑な条件付きのバリデーションが簡単に作成できます。一度に多くのフィールドに、条件付きバリデーションを追加することもできます。

$v->sometimes(['reason', 'cost'], 'required', function($input) {
    return $input->games >= 100;
});

注目: クロージャーに渡される$inputパラメーターはIlluminate\Support\Fluentのインスタンスで、フィールドと入力値にアクセスするためのオブジェクトです。

カスタムバリデーションルール

Laravelは様々な役に立つバリデーションルールを提供しています。しかし自分自身の特別なルールも使いたいですよね。カスタムバリデーションルールを追加する一つの方法は、Validator ファサードextendを使う方法です。カスタムバリデーションルールを追加するために、サービスプロバイダーの中でこのメッセージを使ってみましょう。

<?php

namespace App\Providers;

use Validator;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * アプリケーションサービスの初期処理
     *
     * @return void
     */
    public function boot()
    {
        Validator::extend('foo', function($attribute, $value, $parameters, $validator) {
            return $value == 'foo';
        });
    }

    /**
     * サービスプロバイダー登録
     *
     * @return void
     */
    public function register()
    {
        //
    }
}

カスタムバリデーターのクロージャーは4つの引数を取ります。$attributeはバリデーションをしているフィールド、$valueはその値、$parametersはルールに渡された引数、最後はValidatorインスタンスです。

クロージャーの代わりにextendメソッドへクラスとメソッドを渡すこともできます。

Validator::extend('foo', 'FooValidator@validate');

エラーメッセージの定義

カスタムルールに対するエラーメッセージを定義する必要もあります。インラインでカスタムエラーの配列を使うか、バリデーション言語ファイルにエントリーを追加するどちらかで行えます。このメッセージは属性とエラーメッセージを指定するだけの一次配列で、「カスタマイズ」した配列を入れてはいけません。

"foo" => "入力は不正です!",

"accepted" => ":attributeは受け入れられません。",

// その他のバリデーションメッセージ

カスタムバリデーションルールを作成する場合、エラーメッセージのカスタムプレースフォルダーも定義したいことがあります。前記の方法でカスタムバリデターを作成し、それからValidatorファサードのreplacerメソッドを呼びだしてください。これはサービスプロバイダーbootメソッドの中で行います。

/**
 * アプリケーションサービスの初期起動処理
 *
 * @return void
 */
public function boot()
{
    Validator::extend(...);

    Validator::replacer('foo', function($message, $attribute, $rule, $parameters) {
        return str_replace(...);
    });
}

暗黙の拡張

バリデートする属性が存在していない場合か、requiredルールで定義している「空」の場合、カスタム拡張したものも含め、通常のバリデーションルールは実行されません。たとえばintegerルールはnull値に対して実行されません。

$rules = ['count' => 'integer'];

$input = ['count' => null];

Validator::make($input, $rules)->passes(); // true

属性が空であってもルールを実行するということは、その属性が必須であることを暗黙のうちに示しています。このような「暗黙の」拡張を作成するには、Validator::extendImplicit()メソッドを使います。

Validator::extendImplicit('foo', function($attribute, $value, $parameters, $validator) {
    return $value == 'foo';
});

注意: 「暗黙の」拡張は、単にその属性が必須であるとほのめかしているだけです。属性が存在しない場合や空のときに、実際にバリデーションを失敗と判断するかどうかは、みなさん次第です。