バリデーション on ララジャパン

【Under the hood】エラーバッグの構造

Mon, 05 Jun 2023 01:50:26 +0900

普段、エラーバッグからエラーを取得する際、$errors->first(’name’)などとしますが、この時裏ではどんな処理が行われているかご存知でしょうか？私自身、全然意識せずに使っていましたが、調べてみると実はdefaultという名前付きエラーバッグからエラーを取得している事が分かりました。

前回の記事、名前付きエラーバッグによるエラー管理の執筆時にエラーバッグの構造について調べたのでまとめます。久々にUnder the hoodシリーズ（？）です。前回の記事の内容が多く含まれているのでまだの方は先にそちらを読むことをオススメします。

$errorsの構造

どう言うことか？$errorsの構造を紐解きながら説明します。エラー発生時にblade側でdd($errors)とすると以下の様な出力が確認できます。

Illuminate\Support\ViewErrorBag {#1285 ▼
  #bags: array:1 [▼
    "default" => Illuminate\Support\MessageBag {#1286 ▼    // ← key が default
      #messages: array:1 [▼
        "name" => array:1 [▼
          0 => "名前を入力してください。"
        ]
      ]
      #format: ":message"
    }
  ]
}

これを見て分かることは

$errorsの実態はViewErrorBagのインスタンスである
ViewErrorBagの$bagsプロパティにMessageBagがdefaultというキーで格納されている
エラーメッセージはMessageBagの$messagesプロパティに格納されている

つまり、$errors->first(’name’) とした時は、bagsプロパティの、defaultキーの、（MessageBagの）messagesプロパティの、nameキーの最初のエラーを取得している訳ですね。想像してたより深い構造をしています。

$errors->first(...)の処理を追う

構造からデータへアクセスする際のイメージが掴めたので実際のコードを追ってみましょう。$errors->first(…)とした時、$errorsはViewErrorBagのインスタンスなのだから、ViewErrorBagにfirst()メソッドが定義されているのだろう、と普通は思いますよね。ところが、ViewErrorBagにはそんなメソッドがありません。代わりに以下のマジックメソッドがcallされています。

vendor/laravel/framework/src/Illuminate/Support/ViewErrorBag.php

...
    /**
     * Dynamically call methods on the default bag.
     *
     * @param  string  $method
     * @param  array  $parameters
     * @return mixed
     */
    public function __call($method, $parameters)
    {
        return $this->getBag('default')->$method(...$parameters);
    }
...

マジックメソッド __call() についての詳しい解説はPHPのドキュメントを確認して頂きたいのですが、簡潔に説明すると、

クラスに存在しないメソッドがcallされた場合に実行されるメソッド
第一引数（$method）は実行しようとしたメソッド名
第二引数（$parameters）は実行しようとしたメソッドに渡す予定だった引数

なので例えば、$errors->first(’name’) 実行時は$method が first、　$parameters が [’name’]となります。getBag()は指定のkeyのMessageBagを$bagsから取得するメソッドです。従って、$errors->first(…) はdefaultというキーに紐づいた MessageBagクラスのfirst()をcallしているという事ですね。

名前付きエラーバッグの場合

今度は名前付きエラーバッグの場合の処理を追ってみましょう。前回の記事のおさらいになりますが、名前付きエラーバッグからエラーを取得する際は$errors->エラーバッグ名->first(…) などとします。例えば、エラーバッグ名がuserなら、

$errors->user->first('name');

です。

このコードを見ると、userプロパティがあるのかな？と思いがちですが、（Again！）そんなプロパティはViewErrorBagに存在しません。今度は__get()というマジックメソッドがcallされます。

vendor/laravel/framework/src/Illuminate/Support/ViewErrorBag.php

...
    /**
     * Dynamically access a view error bag.
     *
     * @param  string  $key
     * @return \Illuminate\Contracts\Support\MessageBag
     */
    public function __get($key)
    {
        return $this->getBag($key);
    }
...

getBag() は前項でも出てきましたね。ここでは紐づいたMessageBagを返しているだけの様です。

まとめ

通常のエラーバッグと名前付きエラーバッグ、どちらもエラー参照時にはgetBag()にてMessageBagを取得していることが分かりました。違いは、通常のエラーバッグ時はハードコードされたdefaultというキーを使用しているのに対し、名前付きエラーバッグは任意のキーを使用しているという点のみで、処理自体に違いはありません。冒頭で、通常のエラーバッグがdefaultという名前付きエラーバッグである、と言ったのはそういう意味です。なので実は以下の様にエラーを参照することもできます（意味は全く無いですが）

$errors->default->first('name');

名前付きエラーバッグによるエラー管理

Wed, 24 May 2023 08:56:03 +0900

１つのページに複数のフォームが存在する場合、エラーの管理が煩雑になりがちです。そんな時は名前付きエラーバッグを使ってフォーム毎にエラーを分けると管理しやすいです。

煩雑になってしまう例

複数のフォームがある場合にエラー管理が煩雑になる、とはどんな時でしょうか？例を用いて解説します。

以下の様な会員情報の編集ページがあったとします。

フォームが２つあり、それぞれ別のルートにPOSTされます。

ここでプランナーさんから

「バリデーションエラー発生時に警告文をフォーム毎に文言を変えて表示したい！」

とリクエストが来たとします。つまり、ユーザ情報フォームに関する何かしらのエラーがあれば以下を表示

そして、会社情報フォームに関する何かしらのエラーがあれば以下を表示

何かしらのエラーがあれば、、、と言う条件はフォームが１つであれば簡単で

@if ($errors->any())
... 警告文
@endif

とできますが、フォームが複数ある場合はどうすれば良いでしょうか？ sessionに判別用の値をセットする？それともリダイレクト元のルートで判別する？やり方は色々あると思いますが、名前付きエラーバッグを使うとスマートにできます。

名前付きエラーバッグとは？

その名の通り、エラーバッグに任意の名前を付けたものです。（ここで言うエラーバッグとは、blade側でエラーを参照する際に使う $errors です）

フォーム毎にエラーバッグの名前を分けて付けることで、エラーを分けて管理できるようになります。

エラーバッグに名前をつける

エラーバッグに名前を付けるにはバリデーション時にvalidateWithBag()を使用します。例えば、前項のフォームのバリデーションで以下のようにしています。

ユーザ情報フォーム側では、エラーバッグ名をuserとして第一引数に指定しています。

$validated = $request->validateWithBag(
    'user',                                       // ←エラーバッグ名
    ['name' => 'required'],
    ['name.required' => '名前を入力してください。']
);

会社情報フォーム側では、エラーバッグ名をcompanyとして指定しています。

$validated = $request->validateWithBag(
    'company',                                    // ←エラーバッグ名
    ['company_name' => 'required'],
    ['company_name.required' => '会社名を入力してください。']
);

また、withErrors()を使ってリダイレクトにエラーをセットする際は第二引数にエラーバッグ名を指定します。

return back()->withErrors($validator, 'user')->withInput();

名前付きエラーバッグからエラーを参照する

エラーバッグ名の指定ができたので、今度はblade側でエラーを参照してみましょう。任意の名前のエラーバッグからエラーを参照する際は、 $errors->エラーバッグ名->first(…)などとします。従って、

// ユーザ情報フォームのエラーを取得する場合、
{{ $errors->user->first('name') }}

// 会社情報フォームのエラーを取得する場合、
{{ $errors->company->first('name') }}

// errorディレクティブを使う場合は第二引数にエラーバッグ名を指定
@error('name', 'user')
    {{ $message }}
@enderror

また、前項の警告文の様に、ユーザ情報フォームに何かしらのエラーがあるか判別するには

@if ($errors->user->any())
...
@endif

が使えます。

他の項目に依存する項目のバリデーション

Wed, 15 Mar 2023 06:05:35 +0900

バリデーションの話は尽きないです。過去にもいくつか取り上げました。今回もちょっと頭をひねった話です。

入力例

まずは入力例から、

ユーザーの登録の入力画面で、メルマガの購読をするならドロップダウンで１週間に受信したい回数を指定します。上のキャプチャでは見えないけれど、ドロップダウンで１回、２回、３回の選択が出てきます。メルマガの購読のチェックボックスをオフにしたら、javascriptで回数のドロップダウンの選択を無効としてもいいですね。

この画面の入力値のバリデーションとして、以下のようなコントローラのコードとします。

class DemoController extends Controller
{
    public function create(Request $request)
    {
        $options = [
            0 => '-- 選択してください --',
            1 => '１回',
            2 => '２回',
            3 => '３回',
        ];

        return view('demo2')->with(compact('options'));
    }

    public function store(Request $request)
    {
        $validated = $request->mergeIfMissing([
            'subscribe' => 'N', // メルマガ購読がオフだと値が返ってこないので、ここで値を設定
        ])->validate([
            'email'      => 'required|email',
            'subscribe'  => 'required|in:Y,N', // メルマガ購読？
            'frequency'  => 'required_if:subscribe,Y|integer|in:1,2,3', //購読するなら受信回数をチェック
        ], ['frequency.in' => '選択してください']);

        dd($validated);
    }
}

登録ボタンを押して実行してみましょう！

メルマガ購読のチェックボックスをオン（subscribe = ‘Y’）にしたら、必ず受信回数の選択が必要となり期待通りのエラーが表示されます。上のfrequencyのルールでは、

required_if:subscribe,Yは、「メルマガを購読する」（subscribe = 'Y'）がオンとなり、requiredとなりfrequencyの値（０）があるので正
integerでは、値（０）は整数ゆえに正
in:1,2,3では、値（０）は１でも２でも３でもないので誤

となりエラーです。

さて、今度はメルマガ購読をオフ（subscribe = ‘N’）にして、投稿してみます。

「メルマガを購読する」はオフなのに、どうしてこれもエラーとなるのでしょう？先と違ってrequired_if:subscribe,Yではrequiredとなりませんが、その結果は誤でもありません。しかし最後のルールin:1,2,3では前回と同様に誤となりエラーなります。

その証拠に、今度はメルマガ購読オフで、１回を選択するとエラーとはなりません。

以前習ったbailを使っても同じです。required_if:subscribe,Yのルールの結果が誤となるわけでないので。

            'frequency'  => 'bail|required_if:subscribe,Y|integer|in:1,2,3', //購読するなら受信回数をチェック

exclude_if

一体どうすればよいのでしょうか。そこで登場するのが、exclude_ifのルールです。

            'frequency'  => 'exclude_if:subscribe,N|required_if:subscribe,Y|integer|in:1,2,3', //購読するなら受信回数をチェック

メルマガ購読がオフ（subscribe = ‘N’）なら、exclude_if:subscribe,Nで他のルールは適用されなく、以下のようにエラーとなりません。

nullable

exclude_ifがややこしいと思うなら、これはどうでしょう？

「– 選択してください –」の選択値を０でなくnullとします。また、frequencyのルールにおいて、exclude_ifの代わりにnullableと追加します。

class DemoController extends Controller
{
    public function create(Request $request)
    {
        $options = [
            null => '-- 選択してください --',　// 0でなくnullです。
            1 => '１回',
            2 => '２回',
            3 => '３回',
        ];

        return view('demo2')->with(compact('options'));
    }

    public function store(Request $request)
    {
        $validated = $request->mergeIfMissing([
            'subscribe' => 'N', // メルマガ購読がオフだと値が返ってこないので、ここで値を設定
        ])->validate([
            'email'      => 'required|email',
            'subscribe'  => 'required|in:Y,N', // メルマガ購読？
            'frequency'  => 'nullable|required_if:subscribe,Y|integer|in:1,2,3', // nullableが入っています。
        ], ['frequency.in' => '選択してください']);

        if ($validated['subscribe'] === 'N') {
            $validated['frequency'] = 0; // nullでなく0とする
        }

        dd($validated);
    }
}

匿名関数

まだややこしいと思うならこれはどうでしょう？ルールの匿名関数を使用して「メルマガを購読する」がオンのときだけ値の数字のチェックとしました。

class DemoController extends Controller
{
    public function create(Request $request)
    {
        $options = [
            0 => '-- 選択してください --',
            1 => '１回',
            2 => '２回',
            3 => '３回',
        ];

        return view('demo2')->with(compact('options'));
    }

   public function store(Request $request)
    {
        $validated = $request->mergeIfMissing([
            'subscribe' => 'N',
        ])->validate([
            'email'      => 'required|email',
            'subscribe'  => 'required|in:Y,N',
            'frequency'  => [
                'required_if:subscribe,Y',
                'integer',
                function($attribute, $value, $fail) {
                    if (request('subscribe') === 'Y') {
                        if (! in_array($value, [1,2,3])) {
                            $fail('選択してください');
                        }
                    }
                }
            ]
        ]);

        dd($validated);
    }
}

チェックボックスの入力値 - mergeIfMissing()

Sat, 09 Jul 2022 00:21:25 +0900

以前の投稿「FormRequestで入力値を補正」でチェックボックスがオフのときの値の補正に関して説明しました。今度はFormRequestを使わないときの補正の仕方です。

このような入力画面があるとします。

それを受けるコントローラのメソッドを以下とすると、

...
    public function update(Request $request, Customer $customer)
    {
　　    $validated = $request->validate([
              'active_flag' => ['nullable'],
              'email'       => ['required', 'email', 'unique:customer,email'],
              'name'        => ['required'],
              'name_kana'   => ['required'],
　　　　]);

        dd($validated);
    }
...

このような配列が返ってきます。

[
    'active_flag' => 'Y',
    'email' => 'test@example.com',
    'name'  => 'テスト太郎',
    'name_kana' => 'てすとたろう',
]

しかし、先のチェックボックス「有効」がオフだとすると、

[
    'email' => 'test@example.com',
    'name'  => 'テスト太郎',
    'name_kana' => 'てすとたろう',
]

と、active_flagの項目はリクエストには存在しません。チェックボックスがオフだとブラウザはサーバーに何も返さないからです。

しかし、それをコントローラで判断してDBに無効（この場合N）を保存したいです。

そのような場合は、RequestのメソッドのmergeIfMissing()を使います。オフのときの値を引数として与えます。複数の項目の指定も可能です。

...
    public function update(Request $request, Customer $customer)
    {
        $request->mergeIfMissing(['active_flag' => 'N']); // デフォルトの値を設定！

        $validated = $request->validate([
              'active_flag' => ['required', 'In:Y,N'], // 必須と値を確認！
              'email'       => ['required', 'email', 'unique:customer,email'],
              'name'        => ['required'],
              'name_kana'   => ['required'],
　　　　]);

        dd($validated);
    }
...

値は補正されて、期待通りにNが入ってきます。上のバリデーションルールで見られるように、値が必須であること、値がYあるいはNであることもチェックできます。

[
    'active_flag' => 'N',
    'email' => 'test@example.com',
    'name'  => 'テスト太郎',
    'name_kana' => 'てすとたろう',
]

配列値の入力のためのFormRequest（２）エラーを見やすく

Sun, 12 Sep 2021 12:42:49 +0900

前回は１行１項目で３行の入力フォームの話でした。今回は難度をアップして１行３項目で３行の入力フォームの話です。

複数行・複数項目の入力フォーム

今回のフォームはこんな感じです。前回より複雑でしょう。

コントローラは、前回と同様ですが、FormRequestはItemsRequestとします。

app/Controllers/Form2Controller.php

namespace App\Http\Controllers;

use App\Http\Requests\ItemsRequest;
use Illuminate\Http\Request;

class Form2Controller extends Controller
{
    /**
     * Show the form for creating a new resource.
     *
     * @return \Illuminate\Http\Response
     */
    public function create()
    {
         return view('form2');
    }

    /**
     * Store a newly created resource in storage.
     *
     * @param  App\Http\Requests\ItemsRequest  $request
     * @return \Illuminate\Http\Response
     */
    public function store(ItemsRequest $request)
    {
       ddd($request->validated());
    }
}

ブレードは、

resources/views/form2.blade.php

...
<div class="container-fluid">
  <div class="row">
    <div class="col-md-12 col-lg-12 mt-2">
      <div class="card card-primary">

        <div class="card-header">
          <h3 class="card-title">複数行のフォーム</h3>
        </div>

        <form method="POST" action="{{ route('form2.store') }}" class="form-horizontal" novalidate="">
          @csrf
          <div class="card-body">
            @error('names')
              <div class="invalid-feedback d-block">{{ $message }}</div>
            @enderror
            <div class="table-responsive">
              <table class="table table-bordered table-hover table-sm">
                <thead>
                  <tr>
                    <th>アイテム名</th>
                    <th class="col-2">価格</th>
                    <th class="col-1">個数</th>
                  </tr>
                </thead>
                <tbody>

                  @for ($i = 0; $i < 3; $i++)
                    <tr>
                      <td>
                        <input class="form-control" maxlength="255" name="names[]" type="text" value="{{ old('names.'.$i) }}">
                        @error('names.'.$i)
                          <span class="invalid-feedback d-block">{{ $message }}</span>
                        @enderror
                      </td>
                      <td>
                        <input class="form-control" maxlength="10" name="prices[]" type="text" value="{{ old('prices.'.$i) }}">
                        @error('prices.'.$i)
                          <span class="invalid-feedback d-block">{{ $message }}</span>
                        @enderror
                      </td>
                      <td>
                        <input class="form-control" maxlength="5" name="quantities[]" type="text" value="{{ old('quantities.'.$i) }}">
                        @error('quantities.'.$i)
                        <span class="invalid-feedback d-block">{{ $message }}</span>
                        @enderror
                      </td>
                    </tr>

                  @endfor
                </tbody>
              </table>
            </div>
          </div>

          <div class="card-footer">
            <button class="btn btn-primary float-right mr-2" type="submit">保存</button>
          </div>
        </form>
      </div><!-- card -->
    </div>
  </div><!-- row -->
</div>
...

FormRequestは、

app/Http/Requests/ItemsRequest.php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Contracts\Validation\Validator;
use Illuminate\Validation\ValidationException;

class ItemsRequest extends FormRequest
{
    protected function prepareForValidation()
    {
        $names = $prices = $quantities = [];

        // nullを削除するために入力データを作成しなおす
        foreach($this->names as $i => $name) {
            if ($name === null) {
                continue;
            }

            array_push($names, $name);
            array_push($prices, $this->prices[$i]);
            array_push($quantities, $this->quantities[$i]);
        }

        $this->merge([
            'names'      => $names,
            'prices'     => $prices,
            'quantities' => $quantities,
        ]);
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'names'        => 'required|array', // 必ず１行の入力が必要
            'names.*'      => 'nullable|string',
            'prices.*'     => 'required_with:names.*|integer',
            'quantities.*' => 'required_with:names.*|integer|min:1',
        ];
    }

    public function attributes()
    {
        return [
            'names.*'      => 'アイテム名',
            'prices.*'     => '価格',
            'quantities.*' => '個数',
        ];
    }

    public function messages()
    {
        return [
            'names.required'             => '必ず１つの入力が必要です',
            'prices.*.required_with'     => '「アイテム名」が入力されているときは「価格」は必須です.',
            'prices.*.integer'           => '「価格」は整数の入力が必要です.',
            'quantities.*.required_with' => '「アイテム名」が入力されているときは「個数」は必須です.',
            'quantities.*.integer'       => '「個数」は整数の入力が必要です.',
            'quantities.*.min:1'         => '「個数」は最低１です.',
        ];
    }
}

エラーの出力はこんな感じです。

エラーの出力を見やすくする

先のエラーの出力、個数や価格の列の幅が短いので醜いですね。

考えついたのは、エラーのテキストを一緒にして１行すべてを使って表示しては。ということで、エラーを加工が必要です。Laravelにはしっかりそのための関数もあるのです。

ItemRequest.phpに以下のように、failedValidation()なる関数を追加します。

app/Http/Requests/ItemsRequest.php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Contracts\Validation\Validator;
use Illuminate\Validation\ValidationException;

class ItemsRequest extends FormRequest
{
...
    /**
     * Override the parent function
     *
     * @param  \Illuminate\Contracts\Validation\Validator  $validator
     * @return void
     *
     * @throws \Illuminate\Validation\ValidationException
     */
    protected function failedValidation(Validator $validator)
    {
        $errorsPerRow = [];

        foreach ($validator->errors()->getMessages() as $field => $messages) {
            $i = explode('.', $field)[1] ?? null; // 例えば、name.1なら1を取り出す

            $errorsPerRow['row.'.$i][] = $messages[0]; // 各行でのすべてのエラーを配列に
        }

        foreach ($errorsPerRow as $key => $messages) {
            $validator->errors()->add($key, implode(' ', $messages)); //　各行でのエラーを１つにまとめる
        }

        throw (new ValidationException($validator))
            ->errorBag($this->errorBag)
            ->redirectTo($this->getRedirectUrl());
    }
}

上の関数は、バリデーションが失敗したときにコールされる関数で、関数内で、各行のすべての項目のエラーを合わせて、row.0などのようなキーにエラーメッセージを割り当てて、新たなエラーを作成します。

そしてそれを、ブレードで以下のように出力できるようにします。

...
        <form method="POST" action="{{ route('form2.store') }}" class="form-horizontal" novalidate="">
          @csrf
          <div class="card-body">
            @error('names')
              <div class="invalid-feedback d-block">{{ $message }}</div>
            @enderror
            <div class="table-responsive">
              <table class="table table-bordered table-hover table-sm">
                <thead>
                  <tr>
                    <th>アイテム名</th>
                    <th class="col-2">価格</th>
                    <th class="col-1">個数</th>
                  </tr>
                </thead>
                <tbody>

                  @for ($i = 0; $i < 3; $i++)
                    <tr>
                      <td>
                        <input class="form-control" maxlength="255" name="names[]" type="text" value="{{ old('names.'.$i) }}">
                       </td>
                      <td>
                        <input class="form-control" maxlength="10" name="prices[]" type="text" value="{{ old('prices.'.$i) }}">
                       </td>
                      <td>
                        <input class="form-control" maxlength="5" name="quantities[]" type="text" value="{{ old('quantities.'.$i) }}">
                       </td>
                    </tr>
                    @error('row.'.$i)
                    <tr>
                      <td colspan="3">
                        <span class="invalid-feedback d-block">{{ $message }}</span>
                      </td>
                    </tr>
                    @enderror
                  @endfor
                </tbody>
              </table>
            </div>
          </div>

          <div class="card-footer">
            <button class="btn btn-primary float-right mr-2" type="submit">保存</button>
          </div>
        </form>
...

各項目のエラー表示を削除して、 @error(‘row.’.$i)で行ごとのエラーの表示としています。

結果は以下のように表示が改善されたエラー出力となります。

最後に

いろいろな形態の入力フォームがあるなか、前回も今回も追加専用のフォームの話でしたが、もちろんコードを変更すれば編集のフォームともなります。

配列値の入力のためのFormRequest

Tue, 07 Sep 2021 07:25:55 +0900

配列値の入力、つまり複数行に同じ入力項目を持つフォームの話です。お客様の登録などのフォームとは違って、バリデーションや画面でのエラーの表示など複雑な部分が多いです。しかし、コントローラで対応するより、FormRequestを使うとすっきりしたコードとなります。

配列値の入力フォーム

各行の入力項目が１つのケースから作成してみます。以下のような画面です。行数は固定で、最大３つまでのメールアドレスの入力が可能です。

コントローラのコードは、極力シンプルにして、投稿が成功したらバリデートした値を出力します。

app/Http/Controllers/FormController.php

namespace App\Http\Controllers;

use App\Http\Requests\EmailsRequest;
use Illuminate\Http\Request;

class FormController extends Controller
{
    /**
     * Show the form for creating a new resource.
     *
     * @return \Illuminate\Http\Response
     */
    public function create()
    {
         return view('form');
    }

    /**
     * Store a newly created resource in storage.
     *
     * @param  App\Http\Requests\EmailsRequest  $request
     * @return \Illuminate\Http\Response
     */
    public function store(EmailsRequest $request)
    {
       ddd($request->validated());
    }
}

ブレードは、

resources/views/form.blade.php

...
<div class="container-fluid">
  <div class="row">
    <div class="col-md-12 col-lg-12 mt-2">
      <div class="card card-primary">

        <div class="card-header">
          <h3 class="card-title">複数行のフォーム</h3>
        </div>

        <form method="POST" action="{{ route('form.store') }}" class="form-horizontal" novalidate="">
          @csrf
          <div class="card-body">
            @error('emails')
              <div class="invalid-feedback d-block">{{ $message }}</div>
            @enderror            
            <div class="table-responsive">
              <table class="table table-bordered table-hover table-sm">
                <thead>
                  <tr>
                    <th>メールアドレス</th>
                  </tr>
                </thead>
                <tbody>
                  @for ($i = 0; $i < 3; $i++)
                  <tr>
                    <td>
                      <input class="form-control" maxlength="255" name="emails[]" type="text" value="{{ old('emails.'.$i) }}">
                      @error('emails.'.$i)
                        <span class="invalid-feedback d-block">{{ $message }}</span>
                      @enderror
                    </td>
                   </tr>
                  @endfor
                </tbody>
              </table>
            </div>
          </div>

          <div class="card-footer">
            <button class="btn btn-primary float-right mr-2" type="submit">保存</button>
          </div>
        </form>
      </div><!-- card -->
    </div>
  </div><!-- row -->
</div>
...

そして、FormRequestは、

app/Http/Requests/EmailsRequest.php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class EmaisRequest extends FormRequest
{
    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'emails.*' => 'nullable|email|distinct', // nullableとしているのは空行を許すため
        ];
    }

    public function messages()
    {
        return [
            'emails.*.email'    => '不正なメールです',
            'emails.*.distinct' => '重複の入力があります'
        ];
    }
}

実際に入力するとエラーはこんな感じで出力されます。

そしてバリデートされた値はこんな感じです。

しかし、これではDBに保存するときにいちいちnullを外す必要ありますね。これもFormRequestで処理したいです。

入力値の加工

FormRequestで入力値を加工するには、以下のようにprepareForValidation()を追加して処理します。

app/Http/Requests/EmailsRequest.php

...
class EmailsRequest extends FormRequest
{
    protected function prepareForValidation()
    {
        $emails = collect($this->emails)
            ->filter(function ($email) {
                return $email !== null; //ここでnull値を削除
            })->all();

        $this->merge([
            'emails' => $emails,
        ]);
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'emails'   => 'required|array', //入力を必須とする
            'emails.*' => 'nullable|email|distinct',
        ];
    }

    public function messages()
    {
        return [
            'emails.required'   => '必ず１つの入力が必要です',
            'emails.*.email'    => '不正なメールです',
            'emails.*.distinct' => '重複の入力があります'
        ];
    }
}

最低１つの入力を条件とするために、‘emails’ => ‘required|array’, もrules()も追加しています。

さて、先の投稿でバリデートされたデータは、今度は以下のようにnullの値はなくなりました。

そして、何も入力がなく投稿された場合は以下のようなエラーとなります。

ちなみに、最低２つの入力を条件としたいときは、ルールを、‘emails’ => ‘required|array|min:2’, とすればよいです。

「どちらかに入力してください」のバリデーション

Sun, 13 Dec 2020 01:58:11 +0900

入力画面のバリデーションでちょいと頭をひねったケースです。２つの入力項目があり、どちらかが必須なのだけれど両方の入力は禁止という場合です。まず、具体的な例を見てみましょう。

簡単化しましたが、要はお客さんに配るクーポンのレコードの作成です。

注目してもらいたのは「割引」の項目で、２つの入力場所があります。ひとつは割引額で円で入力、もうひとつは割引率で%で入力です。

コントローラのコードはこんな感じです。新規のDBレコード作成の部分だけですけれど。

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class CouponController extends Controller
{
    /**
     * Show the form for creating a new resource.
     *
     * @return \Illuminate\Http\Response
     */
    public function create()
    {
  		return view('coupon.create');
    }

    /**
     * Store a newly created resource in storage.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\Response
     */
    public function store(Request $request)
    {
    	$rules = [
            'code'            => 'required|alpha_numeric',
            'discount_amount' => 'nullable|required_without:discount_rate|integer|gt:0',
    	    'discount_rate'   => 'nullable|required_without:discount_amount|integer|gt:0|lte:100',
    	];

    	$validated = $request->validate($rules);

        // DBに保存のコードがここに入る
    }
...

discount_amount（割引額）と discount_rate（割引率）のバリデーションに注目してください。nullableは両方とも空になるかもしれないゆえに必要です。

次の、required_withoutは指定する項目が空のとき（つまりnull）はバリデーションの対象の項目が必須となる、ということです。両方の項目でお互いの項目を指定しているのは、両方が空となっては困るからです。つまり、どちらかの入力が必須となります。

よさそうですね。

と思いきや、この問題は両方に値を入れてもパスしてしまうことです。

その問題に対応するために思いついたのは、以下のようにバリデーションに匿名の関数を使用します。

...
   	$rules = [
            'code'            => 'required|alpha_num',
            'discount_amount' => [
                'nullable',
                'required_without:discount_rate',
                function ($attribute, $value, $fail) {
                    if (request('discount_rate')) {
                        $fail("割引額あるいは割引率どちらかだけ入力してください");
                    }
                },
                'integer',
                'gt:0',
            ],
    		'discount_rate'   => 'nullable|required_without:discount_amount|integer|gt:0|lte:100',
    	];
...

request()のヘルパーがここで役に立ちます。バリデーション対象以外の項目の値を簡単に取得できます。

最後に、今回の「どちらかに入力してください」のケースはそう起こることではないと思いますが、UIを変えてクリエイティブな対応も可能と思います。例えば、以下のように割引額と割引率をラジオボタンとすると、それぞれに対応する値の入力項目は２つでなく１つになり常に必須とすることできます。もちろん、それはそれでバリデーションのルールが簡単になるかどうかは保証なしですけれど。

入力フォームで@error

Sun, 22 Nov 2020 11:03:46 +0900

今回は、またしても新規のLaravelのバージョン対しての私のキャッチアップの話です。もちろん、存在は知っていたのですが、最近まで使用する機会がありませんでした。ブレードで使われる@errorの話なのですが、調べたら登場したのはなんとLaravelバージョン5.8、現在のバージョンが8.xなので遠い昔のように思えます。しかし、5.8がリリースされたのはつい去年のことです。Laravelのバージョン形態が変わってから、どんどん更新が早まっていくように感じられます。

@if vs @error

まず、バリデーションエラー表示において、どう@ifから@errorへ進化したかを比較してみます。

@ifを使用すると、

<label for="title">投稿のタイトル</label>

<input id="title" type="text" class="@if ($errors->has('title') is-invalid @endif">

@if ($errors->has('title')
    <div class="alert alert-danger">{{ $errors->first('title') }}</div>
@endif

これが、@errorを使用すると、

<label for="title">投稿のタイトル</label>

<input id="title" type="text" class="@error('title') is-invalid @enderror">

@error('title')
    <div class="alert alert-danger">{{ $message }}</div>
@enderror

両者とも意味は同じですが、@errorの方がすっきりして意味がわかりやすいですね。

配列の入力があるフォームで@error

さて、先の例と違って、以下のような配列フォームではどう@errorを使うことができるでしょう？

まず、エラー表示のもととなるコントローラのバリデーションは、

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class FormController extends Controller
{
    public function create()
    {
    	return view('form.create');
    }

    public function store(Request $request)
    {
    	$rules = [
            'name.*'  => 'nullable',
            'price.*' => 'nullable|required_with:name.*|integer|gt:0',
    	];

        $messages = [
            'price.*.required_with' => '入力してください',
            'price.*.integer'       => '整数で入力してください',
            'price.*.gt'            => '０超の整数で入力してください',
        ];

    	$validated = $request->validate($rules, $messages);

        // DBに保存...
   }
...

配列だから、name.のように、項目名にが使用されていることに注意してください。 nullableは、空(null)の入力でもOKという意味です。

使用されるブレードは、

@extends('layouts.app')

@section('content')
<div class="container">
  <div class="row justify-content-center">
    <div class="col-md-8">
      <div class="card">
        <div class="card-header">出費</div>

        <div class="card-body">
          <form method="POST" action="{{ route('form.store') }}">
            @csrf

            <div class="table-responsive">
              <table class="table table-bordered table-hover table-sm">
              <thead>
                <tr>
                <th class="">アイテム名</th>
                <th class="">金額</th>
                </tr>
              </thead>
              <tbody>
                @for($i = 0; $i < 5; $i++)
                  <tr>
                    <td>
                      <input type="text" class="form-control @error('name.'.$i) is-invalid @enderror" name="name[]" value="{{ old('name.'.$i) }}">
                      @error('name.'.$i)
                        <span class="invalid-feedback" role="alert">
                          <strong>{{ $message }}</strong>
                        </span>
                      @enderror
                    </td>
                    <td>
                      <input type="text" class="form-control @error('price.'.$i) is-invalid @enderror" name="price[]" value="{{ old('price.'.$i) }}">
                      @error('price.'.$i)
                        <span class="invalid-feedback" role="alert">
                          <strong>{{ $message }}</strong>
                        </span>
                      @enderror
                    </td>
                  </tr>
                @endfor
              </tbody>
              </table>
            </div>

            <div class="row justify-content-center">
              <button type="submit" class="btn btn-primary">
                  保存
              </button>
            </div>
          </form>
        </div>
      </div>
    </div>
  </div>
</div>
@endsection

@error(‘price.’.$i)と、price1でなくprice.1となっていることに注意してください。Laravelでは、price.1は指定の配列値で、price[1]と同じことです。同様に、old()でもold(‘price.’.$i)とprice.1となっています。

FormRequestで入力値を補正（２）

Sat, 10 Oct 2020 01:20:11 +0900

FormRequestで入力値を補正を以前紹介しましたが、今度はちょっと違う補正の紹介です。何が違うというと、今度はバリデーションの後でなくバリデーション前に入力値を変えます。入力項目とDBに保存する項目の形態が違うときにとても便利です。とりあえず、それが必要なケースの説明から。

まず、DBに保存するのは、start_at（開始日時）とend_at（終了日時）の日時タイプ（mysqlならDATETIME）の２つ項目とします。しかし、両方の項目ともに日付は同じという仮定。いくつかのUIのバリエーションが考えられますが、私が考えたのは以下。

つまり、入力項目は、日付、開始時刻（数字）、終了時刻（数字）の３つの入力項目です。

日付はjquery-uiでカレンダーからの選択も可能（以下）であるし、時刻もドロップダウン、とすることもできますね。

画面から入ってくるのは、date, start_hr, end_hrの３つの値なのですが、さて、これらの入力値をバリデーションにかけて、DBには、start_atとend_atの２つの項目に保存するには、どうしたらよいでしょうか？

そこで登場するのが、FormRequestです。

まず、以下のコマンドでFormRequestファイルを、app/Http/Requestsのディレクトリに作成します。

$ php artisan make:request EventRequest

作成されたファイルを以下のように編集します。

app/Http/Requests/EventRequest.php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class EventRequest extends FormRequest
{
    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'start_at'     => 'required|date|date_format:Y-m-d H:i:s',
            'end_at'       => 'required|date|date_format:Y-m-d H:i:s|after:start_at',
        ];
    }

    public function messages()
    {
        return [
            'date_format' => '不正な日時のフォーマットです',
        ];
    }

   public function attributes()
    {
        return [
            'start_at' => '開始日時',
            'end_at'   => '終了日時',
        ];
    }

    /**
     * Prepare the data for validation.
     *
     * @return void
     */
    protected function prepareForValidation()
    {
        // ここでDBに収納する項目を作成
        $this->merge([
            'start_at' => sprintf('%s %02d:00:00', $this->date, $this->start_hr),
            'end_at'   => sprintf('%s %02d:59:59', $this->date, $this->end_hr),
        ]);
    }
}

ここ、preparedForValidation()の関数において、入力値を、start_atとend_atの入力値に変換しています。DBではそれらの項目はDateTimeのタイプなので、時間だけでなく分や秒も足すこと必要です。

コントローラのメソッドでは、以下のようにコールします。store()の引数が、通常のRequestでなくEventRequestとなっていることに注意を。

app/Http/Controllers/EventController.php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Http\Requests\EventRequest;

class EventController extends Controller
{
...
    /**
     * Store
     *
     * @param  \App\Http\Requests\EventRequest $request
     * @return \Illuminate\Http\RedirectResponse
     */
    public function store(EventRequest $request)
    {
        dd($request->all());
...

実行すると、dd()の出力は、

array:6 [▼
  "_token" => "npq1EPLTVvthufpgQiIpXIkxpwMPEsEEIBIzYf5A"
  "date" => "2020-10-08"
  "start_hr" => "8"
  "end_hr" => "17"
  "start_at" => "2020-10-08 08:00:00"
  "end_at" => "2020-10-08 17:59:59"
]

FormRequestでルールを共有

Tue, 24 Mar 2020 04:28:31 +0900

世界中大変なことになっていますね。私が住んでいるところも、子供たちの学校は４月いっぱい休み、レストランやバーはテイクアウトのみとなっています。それらのビジネスに携わっている人たちは本当に困っていると思います。逆に、私を含めてこのブログを読んでくれる人たちは、インターネットのおかげで忙しくなっているくらいと思います。その有難さを胸に、日々精進と行きましょう！

今回は、またもやFormRequestの話で、１つのコントローラーにおいてあるいは複数のコントローラでどうバリデーションのルールを共有の仕方を考えてみます。

ルールを共有する必要性

ルールをコントローラ間で共有する必要があるのは、重複の定義をせずに一か所で管理をして間違いを防ぎたいからです。

会員レコードを例にとると、

ユーザー画面での会員登録ユーザー画面で名前や住所などの会員情報更新ユーザー画面でパスワード変更さらに、管理画面ではユーザー画面と同様に、新規、更新、パスワード更新の機能が必要となります。

つまり、少なくともユーザー画面と管理画面で２つのコントローラーが必要で、それぞれの入力画面に異なるFormRequestを作成すれば６つ必要となります。そして、それぞれにルールの定義があるわけですが、いくつかは明らかに同じものを定義することになります。将来の管理性を考えるとどうかしたいですね。

ルールの共有の仕方

ルールを共有するにはいくつかのやり方ありますが、ここでは、以前書いた以下のブログを利用してみます。

コントローラー中でのルールの共有

そこでは、１つのコントローラ内でのルールの共有していますが、今度はFormRequest内でルールを共有します。そのために、先に書いた６つのFormRequestを作成する代わりに、１つのFormRequestを作成してそれを複数のコントローラのメソッドで共有とします。

まず、以前のコードを以下に再掲載します。

namespace App\Http\Controllers;
 
use Illuminate\Http\Request;
use Illuminate\Validation\Rule;
 
use App\User;
 
class UserController extends Controller
{
    public function rule($action, User $user = null)
   {
        // 共有するルール　kana, mailcode, phone_with_dashはカスタムバリデーター
        $rules = [
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
        ];
 
       // 共有しないルール
       switch ($action) {
            case 'store':　// レコード作成のためのルールを追加
                $rules['password']      = 'required|min:8|max:20|confirmed';
                $rules['email']         = 'required|email|unique:users';
                break;
 
            case 'update': // レコード編集のためのルールを追加
                $rules['email'] = [
                    'required',
                    'email',
                    Rule::unique('users')->ignore($user->id), //現在のレコード以外のレコードで重複がないかチェック
                ];
                break;
        }
 
        return [
            // rules
            $rules,
            // messages
            [
                'password.min' => '8から20文字長でお願いします',
                'password.max' => '8から20文字長でお願いします'
            ]
            // attributes
        ];
    }
...
    public function store(Request $request)
    {
        $request->validate(...$this->rules('store'));
        ...
    }
...
    public function update(Request $request, User $user)
    {
        $request->validate(...$this->rules('update', $user));
        ...
    }
...
}

FormRequestを使用すると、rules()の部分がUserFormRequestに移って、

...
    public function store(UserFormRequest $request)
    {
        ...
    }
...
    public function update(UserFormRequest $request, User $user)
    {
        ...
    }
...
}

となりますが、問題は、上と違って$actionや$userなどのパラメータを渡すことができません。どうしたらよいでしょう？

そこで登場するのが、$this->route()のメソッドです。UserFormRequestの中で、以下のようにそれらの情報が取り出せます。名前付きのルートがわかれば、それで条件分岐できます。

        $route= $this->route()->getName(); // 現在のrouteの名前を取得
        $user = $this->route('user'); // update(UserFormRequest $request, User $user)の$userを取得

以下が、UserFormRequestのコードです。

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UserFormRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rule()
    {
        $route= $this->route()->getName(); // 現在のrouteの名前を取得
        $user = $this->route('user'); // update(UserFormRequest $request, User $user)の$userを取得

        // 共有するルール　kana, mailcode, phone_with_dashはカスタムバリデーター
        $rules = [
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
        ];
 
       // 共有しないルール
       switch ($route) {
            case 'user.store':　// レコード作成のためのルールを追加
                $rules['password']      = 'required|min:8|max:20|confirmed';
                $rules['email']         = 'required|email|unique:users';
                break;
 
            case 'user.update': // レコード編集のためのルールを追加
                $rules['email'] = [
                    'required',
                    'email',
                    Rule::unique('users')->ignore($user->id), //現在のレコード以外のレコードで重複がないかチェック
                ];
                break;
        }
 
        return $rules;
    }

    public function messages()
    {
        return [
                'password.min' => '8から20文字長でお願いします',
                'password.max' => '8から20文字長でお願いします'
        ];
    }
}

FormRequestで入力値を補正

Fri, 13 Mar 2020 23:59:58 +0900

FormRequestの続きです。FormRequestは、ユーザーの入力をチェックしてくれるだけでなく、入力値も変えてくれることができます。

例えば、フォームにおいて以下のようなチェックボックスがあったとき、

	<div class="form-group row">
		<label for="subscribe" class="col-md-4 col-form-label text-md-right">メルマガを購読？</label>

		<div class="col-md-6">
			<input id="subscribe" type="checkbox" class="form-control" name="subscribe" value="Y">
		</div>
	</div>

チェックをオンにすれば、リクエストにはY（Yesの意味）の値が返ってきますが、チェックがオフなら何も値が返ってきません。それゆえに、例えばチェックなしをDBにN（Noの意味）として保存したいなら、どうしましょう？

私のFormRequestの継承元のFormRequestのLaravelのコードを見ると、以下のようなメソッドがあります。

vendor/laravel/framework/src/Illuminate/Foundation/Http/FormRequest.php

...
    /**
     * Get data to be validated from the request.
     *
     * @return array
     */
    public function validationData()
    {
        return $this->all();
    }
...

このメソッドを上書きして、

app/Http/Requests/UserRequest.php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UserRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'name'  => 'required',
            'email' => 'required|email',
            'subscribe' => 'string',　// これを忘れずに！
        ];
    }

    public function validationData()
    {
        $all = parent::validationData();

        //値がないなら、'N'を入れる
        if (! $this->has('subscribe')) {
            $all['subscribe'] = 'N';
        }

        return $all;
    }
}

ルールにおいては、チェックボックスの項目（subscribe）のルールが必ず必要です。

こうすれば、

namespace App\Http\Controllers;

use App\Http\Requests\UserRequest;

class UserController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth');
    }

    public function edit()
    {
    	$user = auth()->user();

    	return view('user_edit')->with(compact('user'));
    }

    public function update(UserRequest $request)
    {
        dd($request->validated()); // デバッグ文を入れる

    	auth()->user()->update($request->validated());

    	return redirect()->route('home');
    }
}

フォームでsubmitすると、上で入れたデバッグ文の実行は、

array:3 [▼
  "name" => "kenji"
  "email" => "kenji@lotsofbytes.com"
  "subscribe" => "N"
]

と返してくれます。

FormRequestを使う

Mon, 09 Mar 2020 11:58:03 +0900

コントローラーのファイルが大きくなってきたな、と思ったら、FormRequestを使ってみようかと真剣に考え始めました。まずは、FormRequestとは何ものかの紹介からです。

FormRequestを使わないコントローラ

FormRequestを使わないコントローラというのは、例えば以下のコードに代表されます。

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class UserController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth'); //認証したユーザーのみがアクセス可能
    }

    public function edit()
    {
    	$user = auth()->user();　// 認証したユーザーの情報を取得

    	return view('user_edit')->with(compact('user'));
    }

    public function update(Request $request)
    {
       // リクエストのバリデーション
    	$validated = $request->validate([
    		'name'  => 'required',
    		'email' => 'required|email',
    	]);

        // DBの情報を更新
    	auth()->user()->update($validated);

        // ホーム画面へリダイレクト
    	return redirect()->route('home');
    }
}

このコントローラを使用する、routeは以下のように定義されます。

routes/web.php

Route::get('/', function () {
    return view('welcome');
});

Auth::routes();

Route::get('/home', 'HomeController@index')->name('home');

Route::get('/user/edit', 'UserController@edit')->name('user.edit');
Route::put('/user/edit', 'UserController@update')->name('user.update');

よく見て欲しいのは、UserController::update()のメソッド。リクエストの入力値をバリデートして、バリデーションをパスした入力値をそのまま、EloquestのUserオブジェクト(auth()->user)のupdate()に渡して更新です。

ちなみに、このコントローラは、ログインしたユーザーが自分の情報を編集するためです。Laravelのデフォルトのプロジェクトにはユーザー認証のコードがついてきますが、この機能はありません。

FormRequestを使用したら

まず、コマンドラインから、FormRequestの作成です。

$ php artisan make:request UserRequest

これで、UserRequest.phpが作成されます。それを以下のように編集します。

app/Http/Requests/UserRequest.php

amespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UserRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true; // すでにUserController::__construct()でチェックしてあるので、true
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'name'  => 'required',
            'email' => 'required|email',
        ];
    }
}

見ての通り、コントローラにあったバリデーションルールが移動されています。

コントローラの方は、

namespace App\Http\Controllers;

use App\Http\Requests\UserRequest; //ここで宣言

class UserController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth');
    }

    public function edit()
    {
    	$user = auth()->user();

    	return view('user_edit')->with(compact('user'));
    }

    public function update(UserRequest $request)
    {
    	auth()->user()->update($request->validated());　// １行になりました

    	return redirect()->route('home');
    }
}

FormRequestを使うことでコントローラのコードの行数は減りました。しかし、FormRequestの定義のファイルが増えて全体のコードの行数は増えたことも事実。今回のような、簡単なコードではあまり得したことにはならない感じですね。ない方がわかりやすいとも思えます。しかし、もしバリデーションルールがもっとたくさんあったら、FormRequestはベターなのは明らかです。コードが複雑になったらリファクターして新規の関数を作成するのと同じかな。

しかし、FormRequestを使うことに関して他の利点はなんでしょう？次回からそれらの利点を探ってみます。

編集のブレード

参考として、作成したブレードファイルも掲載します。resources/views/auth/register.blade.phpをもとにしましたが、Eメールの入力において、type=“email”のところ、type=“text”にしています。バリデーションエラーの表示をテストしたかったためです。

resources/views/user_edit.blade.pohp

@extends('layouts.app')

@section('content')
<div class="container">
    <div class="row justify-content-center">
        <div class="col-md-8">
            <div class="card">
                <div class="card-header">{{ __('Register') }}</div>

                <div class="card-body">
                    <form method="POST" action="{{ route('user.edit') }}">
                        @csrf
                        @method('PUT')

                        <div class="form-group row">
                            <label for="name" class="col-md-4 col-form-label text-md-right">{{ __('Name') }}</label>

                            <div class="col-md-6">
                                <input id="name" type="text" class="form-control @error('name') is-invalid @enderror" name="name" value="{{ old('name', $user->name) }}" required autocomplete="name" autofocus>

                                @error('name')
                                    <span class="invalid-feedback" role="alert">
                                        <strong>{{ $message }}</strong>
                                    </span>
                                @enderror
                            </div>
                        </div>

                        <div class="form-group row">
                            <label for="email" class="col-md-4 col-form-label text-md-right">{{ __('E-Mail Address') }}</label>

                            <div class="col-md-6">
                                <input id="email" type="text" class="form-control @error('email') is-invalid @enderror" name="email" value="{{ old('email', $user->email) }}" required autocomplete="email">

                                @error('email')
                                    <span class="invalid-feedback" role="alert">
                                        <strong>{{ $message }}</strong>
                                    </span>
                                @enderror
                            </div>
                        </div>

                        <div class="form-group row mb-0">
                            <div class="col-md-6 offset-md-4">
                                <button type="submit" class="btn btn-primary">
                                    {{ __('Register') }}
                                </button>
                            </div>
                        </div>
                    </form>
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

値がないときにバリデーションを実行するには

Sun, 17 Nov 2019 01:25:11 +0900

バリデーションの話です。バリデーションのルールには、implicitルールというのがあり、入力値の項目が存在しない、あるいは値が空のときに、実行されるルールです。

ルールと言えば、numericとかのように値があってのexplicitのルールが直感的ですが、値がないときのルールとは何でしょう？

ぱっと思いつかないかもしれませんが、頻繁に使うrequiredは、値がないときのimplicitルールです。必須なのだから、値がなくてもバリデーションを実行しなければなりません。

Implicitルールが必要なケースは意外にもあります。例えば、以下の管理画面における会員編集の画面。

ここでは、有効のチェックボックスがオン（有効）ですが、これをオフ（無効とする）として投稿するとチェックボックスの入力値はありません。しかし、例えば、会員を無効にするには、未支払いの注文があってはいけない、というルールがあるとすると、これはimplicitルールを作成しないとそのルールを強制することはできません。

このカスタムルールを作成してみましょう。

$ php artisan make:rule MemberDeactivateRule

作成されたファイルを編集します。

app/Rules/MemberDeactivateRule.php

namespace App\Rules;

use App\Models\Member;

use Illuminate\Contracts\Validation\ImplicitRule;

class MemberDeactivateRule implements ImplicitRule
{
    protected $member;

    /**
     * Create a new rule instance.
     * @param  \App\Models\Member $member
     * @return void
     */
    public function __construct(Member $member)
    {
        $this->member = $member;
    }

    /**
     * Determine if the validation rule passes.
     *
     * @param  string  $attribute
     * @param  mixed  $value
     * @return bool
     */
    public function passes($attribute, $value)
    {
        // チェックボックスをオンとすると、'Y'を返すとする。
        if ($value == 'Y') {
            return true;
        }

        // チェックボックスがオフなら、
        // 未払いの注文があるかどうかをチェックして、エラーとする
　　　　 if ($member->checkUnpaid()) {
            return false;
        }
        
        return true;
    }

    /**
     * Get the validation error message.
     *
     * @return string
     */
    public function message()
    {
        return '未払いの注文があります';
    }
}

通常のカスタムルールと違うのは、カスタムルールのクラスの実装にImplicitRuleのインターフェースを使用していることです、通常は、ImplicitRuleの代わりにRuleのクラスを使用します。

最後に、コントローラで、このカスタムルールを使用したバリデーションは、以下のようになります。

...
$request->validate(['active_flag' => new MemberDeactivateRule($member)]);

バリデーションルール、bail

Sat, 02 Nov 2019 01:47:35 +0900

今回は、知っていたけれどあまり使っていない、ことの話です。Laravelの入力バリデーションのことなのですが、忘れずに書いておいてより使うようにしたいです。

Laravelの入力のバリデーションでは複数のルールがあると、それらルールすべてが適用されます。

例えば、入力項目は年齢で、ルールは入力値は数字（整数）であり、かつ10歳以上とします。

$php artisan tinker
Psy Shell v0.9.9 (PHP 7.2.16 — cli) by Justin Hileman
>>> $input = ['age' => '9'];
=> [
     "age" => "9",
   ]
>>> $rule = ['age' => 'integer|gte:10'];
=> [
     "age" => "integer|gte:10",
   ]
>>> validator($input, $rule)->errors()->all();
=> [
     "The age must be greater than or equal 10.",
   ]

入力値が９歳なら、上のようにエラーとなります。エラーは配列で返ります。

さて、ここで入力値を、数字でなく英字としてみます。

>>> $input = ['age' => 'abc'];
=> [
     "age" => "9",
   ]
>>> $rule = ['age' => 'integer|gte:10'];
=> [
     "age" => "integer|gte:10",
   ]
>>> validator($input, $rule)->errors()->all();
=> [
     "The age must be an integer.",
     "The age must be greater than or equal 10.",
   ]

あれ、と思うのは最初の数字のルールで、ルールの適用が止まらないことです。これはLaravelの作者によると、すべてのルールの結果を見せたい、という仕様らしい。

しかし、最初のエラーだけを画面に表示するのは大半のケースです。さらに、例ば、ルールにおいて、2番目のルールがDBのチェックを必要すると、1番目のルールに通らなかったら、わざわざ時間がかかる2番目のDBのクエリの実行は必要はありません。

そういう場合は、bailをルールの最初に置くと、

>>> $rule = ['age' => 'bail|integer|gte:10'];
=> [
     "age" => "bail|integer|gte:10",
   ]
>>> validator($input, $rule)->errors()->all();
=> [
     "The age must be an integer.",
   ]

2番目のルールは実行されません。

このbailの登場は、5.6からのようですが、最新の5.5でも対応しています。

コントローラー中でのルールの共有（3) データをDBに保存

Sun, 28 Apr 2019 22:12:23 +0900

前回において、理想のバリデーションの関数、rules()を作成できたところで、今回は、そのバリデーションチェックを通過した入力データをDBに保存するところを見てみます。

なんのことはなく、$request->validate()がそのデータを返してくれるので、以下のように、返ってきた連想配列値をそのまま、create()あるいはupdate()に引数として渡せばいいのです。簡単ですね！

namespace App\Http\Controllers;
 
use Illuminate\Http\Request;
use Illuminate\Validation\Rule;
 
use App\User;
 
class UserController extends Controller
{
    public function rule(User $user = null)
   {
        // 共有するルール　kana, mailcode, phone_with_dashはカスタムバリデーター
        $rules = [
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
            'password'    => 'sometimes|required|min:8|max:20|confirmed',
            'email'       => [
                    'required',
                    'email',
                    Rule::unique('users')->ignore(optional($user)->id), //重複がないかチェック
                ]
        ];
 
        return [
            // rules
            $rules,
            // messages
            [
                'password.min' => '8から20文字長でお願いします',
                'password.max' => '8から20文字長でお願いします'
            ]
            // attributes
        ];
    }
...
    public function store(Request $request)
    {
        $validated = $request->validate(...$this->rules());
        User::create($validated);
    }
...
    public function update(Request $request, User $user)
    {
        $validated = $request->validate(...$this->rules($user));
        $user->update($validated);
    }
...
}

しかし、ここで１つ問題です。画面には入力項目、住所２として、address2があります。項目は必須ではないので、上の例ではこれが保存されません。

これを解決するには、以下のようにルールにsometimesを使用して項目を作成すればいいですね。

...
    public function rule(User $user = null)
   {
        // 共有するルール　kana, mailcode, phone_with_dashはカスタムバリデーター
        $rules = [
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'address2'    => 'sometimes|required',
            'phone'       => 'required|phone_with_dash',
            'password'    => 'sometimes|required|min:8|max:20|confirmed',
            'email'       => [
                    'required',
                    'email',
                    Rule::unique('users')->ignore(optional($user)->id), //重複がないかチェック
                ]
        ];
 
        return [
            // rules
            $rules,
            // messages
            [
                'password.min' => '8から20文字長でお願いします',
                'password.max' => '8から20文字長でお願いします'
            ]
            // attributes
        ];
    }
...

コントローラー中でのルールの共有（２）sometimes

Sun, 21 Apr 2019 10:01:29 +0900

前回で披露したコントローラー中でのルールの共有のメソッドrules()では、新規レコード作成と既存レコードの編集における入力項目の違いを、$actionの引数をswitchで分岐して対応しました。今回は、sometimesを使用してそれらの必要性をなくします。

sometimesは、入力項目があるときのみに、それ以降のルールを適応するルールです。tinkerを使ってテストしてみましょう。

通常は、

>>> $input = [];
=> []
>>> $rules = ['email' => 'required|email'];
=> [
     "email" => "required|email",
   ]
>>> validator($input, $rules)->errors()->all();
=> [
     "必ず指定してください",
   ]

とエラーとなるところ、sometimesを使用すると、

>>> $input = [];
=> []
>>> $rules = ['email' => 'sometimes|required|email'];
=> [
     "email" => "sometimes|required|email",
   ]
>>> validator($input, $rules)->errors()->all();
=> []
>>>

とemailの項目が入力にないのにエラーとはなりません。

これを利用して前回のrules()の定義を書き変えてみます。

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Validation\Rule;

use App\User;

class UserController extends Controller
{
    public function rule(User $user = null)
   {
        // 共有するルール　kana, mailcode, phone_with_dashはカスタムバリデーター
        $rules = [
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
            'password'    => 'sometimes|required|min:8|max:20|confirmed',
            'email'       => [
                    'required',
                    'email',
                    Rule::unique('users')->ignore(optional($user)->id), //重複がないかチェック
                ]
        ];

        return [
            // rules
            $rules,
            // messages
            [
                'password.min' => '8から20文字長でお願いします',
                'password.max' => '8から20文字長でお願いします'
            ]
            // attributes
        ];
    }
...
    public function store(Request $request)
    {
        $request->validate(...$this->rules());
        ...
    }
...
    public function update(Request $request, User $user)
    {
        $request->validate(...$this->rules($user));
        ...
    }
...

前回と変わったのは、関数の引数の$actionとその値によるswitchによる分岐がなくなっています。新規作成時しか必要でない、passwordの項目に、sometimesを使用して、その項目がないときはルールを適用しないようにしています。また、emailの重複のチェックにおいては、以下のようにヘルパーのoptional()を使用して、新規には存在しない$userの値でundefinedのエラーが出ないようにしています。

Rule::unique(‘users’)->ignore(optional($user)->id)

最後に、sometimes|requiredは以下のようにfilledに置き換えることも可能です。filledに関してはこちらも参考にしてください。

‘password’ => ‘filled|min:8|max:20|confirmed’

コントローラー中でのルールの共有

Mon, 15 Apr 2019 23:45:08 +0900

１つのコントローラの中で、バリデーションに使用するルールをメソッド間で共有したい、とは誰しも思うこと。私もLaravelを習得して以来、管理性が高くしかもすっきりとした方法を求め続けていました。前回で紹介したカスタムルールの登場で、これは使えるんじゃない、という方法を見つけましたので、ここにて披露です。

欲しいもの

いくつか条件あります。

１．コントローラー内でルールを指定したい

これはどちらかというと実用性より好みの問題かもしれませんが、Form Requestのように違うファイルとして定義するのではなく、コントローラー内で定義することにより、あちこちのファイルを見に行くのではなくコントローラーのファイル内で使用されるルールを見たいためです。たいていのコントローラーは、そうたいした数のルールがあるわけでもないので、Form Requestを使用する必要もないです。

２．コントローラーのメソッド内でルールを指定したくない

これは管理性大いにあります。以下のようにそれぞれのメソッド内で重複してルールを定義するのは間違いが起こるもとです。もちろん、これが今回のルールの共有の大きな要因でもあります。

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Validation\Rule;

use App\User;

class UserController extends Controller
{
...
    public function store(Request $request)
    {
        $request->validate([
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
            'email'       => 'required|email|unique:users',
            'password'    => 'required|min:8|max:20|confirmed',
        ]);
        ...
    }
...
    public function update(Request $request, User $user)
    {
        $request->validate([
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
　　　　　　　　　　'email'       => [
                'required',
                'email',
                Rule::unique('users')->ignore($user->id), //現在のレコード以外のレコードで重複がないかチェック
             ],
        ]);
        ...
    }
...
}

解決方法　その１

上の条件にかなうものとしては、コントローラー内の一箇所にルールーを指定することになります。まず、考えたのは、インスタンス変数を使用すること、

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Validation\Rule;

use App\User;

class UserController extends Controller
{
    protected  $rules = [
        'shared' => [ // kana, mailcode, phone_with_dashはカスタムバリデーター
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
        ],

        'store' => [
            'email'       => 'required|email|unique:users',
            'password'    => 'required|min:8|max:20|confirmed',
       ],

       'update' => [
　　　　    'email'       => [
                'required',
                'email',
                Rule::unique('users')->ignore($user->id), //現在のレコード以外のレコードで重複がないかチェック
             ],
       ]
    ];
...
    public function store(Request $request)
    {
        $request->validate($this->rules['shared'] + $this->rules['store']);
        ...
    }
...
    public function update(Request $request, User $user)
    {
        $request->validate($this->rules['shared'] + $this->rules['update']);
        ...
    }
...
}

いい感じ？

しかし問題あります。

Rule::unique(‘users’)->ignore($user->id)

これ、$rulesの変数の宣言時に、このような初期化はできないし、$userを渡すこともできません。update()のメソッド内でその初期化をする必要あります。

...
    public function update(Request $request, User $user)
    {
        $thus->rules['update']['email'][] = Rule::unique('users')->ignore($user->id);
        $request->validate($this->rules['shared'] + $this->rules['update']);
        ...
    }
...

せっかくコントローラーの先頭で一箇所で定義しようと思ったのに、これは良くないですね。

欲しかった解決方法

初期化が問題なら、クラスのインスタンス変数の代わりに、Form Requestにあるように、rules()という名前でコントローラーの関数にしてはどうでしょう、ということで以下になりました。

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Validation\Rule;

use App\User;

class UserController extends Controller
{
    public function rule($action, User $user = null)
   {
        // 共有するルール　kana, mailcode, phone_with_dashはカスタムバリデーター
        $rules = [
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
        ];

       // 共有しないルール
       switch ($action) {
            case 'store':　// レコード作成のためのルールを追加
                $rules['password']      = 'required|min:8|max:20|confirmed';
                $rules['email']         = 'required|email|unique:users';
                break;

            case 'update': // レコード編集のためのルールを追加
                $rules['email'] = [
                    'required',
                    'email',
                    Rule::unique('users')->ignore($user->id), //現在のレコード以外のレコードで重複がないかチェック
                ];
                break;
        }

        return [
            // rules
            $rules,
            // messages
            [
                'password.min' => '8から20文字長でお願いします',
                'password.max' => '8から20文字長でお願いします'
            ]
            // attributes
        ];
    }
...
    public function store(Request $request)
    {
        $request->validate(...$this->rules('store'));
        ...
    }
...
    public function update(Request $request, User $user)
    {
        $request->validate(...$this->rules('update', $user));
        ...
    }
...
}

rules()の関数には、２つの引数があります。最初の$actionはメソッド名で、それにより返す連想配列$rulesを特定し、次の$userは編集で必要とされる値（ここでは重複のチェックのためにレコードid）を取得のためが目的です。

関数の引数は状況に応じて自由に変えてください。以下は、前回に紹介したカスタムルールの例ですが、同じ入力画面からの違う項目のdate_startの値を取得しています。

   public function rules($action, Request $request)
    {
        // store
        $rules = [
            'date_start'    => 'date',
            'date_end'      => [
                'date',
                'after_or_equal:date_start',
                new RestrictPeriodRule($request->date_start), 6)
            ],
        ];

        return [$rules];
    }

最後に、rules()が返す配列は、$request->validate()の引数にマッチする、rules、messages、attributesとなりますが、必要に応じてrulesだけでもＯＫです。このように不特定数の引数があるときは、コールするときに、 $request->validate(…$this->rules(‘store’))のようにphp5.6より登場した3つのドットを使って渡します。

カスタムルールオブジェクト

Mon, 01 Apr 2019 09:44:21 +0900

5.5より前のバージョンのLaravelでプログラムをしていたひとたちに取っては、5.5で登場したルールオブジェクトは神の恵みと言ってもいいくらい。カスタムバリデーションを作成するために、Validator::extendはどこに宣言するの？とか、グローバルでどう作成したバリデーションを共有するの？とか、取り掛かる前に悩んでいたのがウソのよう。新登場のルールオブジェクトのおかげで、カスタムルールの作成が楽しくなりました。

カスタムルールが必要となるときは、たくさんあります。なぜなら既存のバリデーションでは簡単にいかないルールが世の中にたくさんあるからです。

例えば、登録したユーザーのリストが欲しいとして、開始日を指定して今日までに登録したユーザーのみとします。しかし、開始日は今日から2か月までしか遡れない、とします。以下のようなカレンダーで開始日をしてもらいますが、開始日が2か月以上前ならバリデーションでチェックしてエラーを表示としたいです。

このバリデーションには既存のバリデーションのafter_or_equalが使えます、しかし渡すパラメータには、「今日マイナス2か月」が必要です。もちろん前もって計算して渡すこともできます。

Psy Shell v0.9.9 (PHP 7.2.16 — cli) by Justin Hileman
>>> $from = \Carbon\Carbon::today()->subMonth(2)->toDateString();
=> "2019-01-29"
>>> $input = ['start_date' => '2019-01-01'];
=> [
     "start_date" => "2019-01-01",
   ]
>>> validator($input, ['start_date' => 'required|date|after_or_equal:$from'])->errors()->all();
=> []
>>> validator($input, ['start_date' => "required|date|after_or_equal:$from"])->errors()->all();
=> [
     "start dateは2019-01-29以後の日付が必要です",
   ]
>>>

しかし、もしかしたら2か月でなく3ヶ月となるかもしれないし、一般的なバリデーションがあってもいいですね。こんな感じで呼び出したいです。

['start_date' => ['required', 'date', new RestrictPeriodRule(2)]];

そこで、ルールオブジェクトの出番です。

まず、コマンドでルールのファイルを作成します。

$ php artisan make:rule RestrictPeriodRule

中身を以下のように編集します。

appRulesRestrictPeriodRule.php

<?php

namespace App\Rules;

use Carbon\Carbon;
use Illuminate\Contracts\Validation\Rule;

class RestrictPeriodRule implements Rule
{
    protected $months;
    protected $start;

    /**
     * Create a new rule instance.
     *
     * @return void
     */
    public function __construct($months)
    {
        $this->months = $months;
    }

    /**
     * Determine if the validation rule passes.
     *
     * @param  string  $attribute
     * @param  mixed  $value
     * @return bool
     */
    public function passes($attribute, $value)
    {
        $this->start = Carbon::today()
                  ->subMonth($this->months)
                  ->toDateString();

        return ($value >= $this->start);
    }

    /**
     * Get the validation error message.
     *
     * @return string
     */
    public function message()
    {
        return $this->start.'以降を指定してください';
    }
}

出来たところでテストしてみましょう。

Psy Shell v0.9.9 (PHP 7.2.16 — cli) by Justin Hileman
>>> $input = ['start_date' => '2019-01-01'];
=> [
     "start_date" => "2019-01-01",
   ]
>>> validator($input, ['start_date' => ['required', 'date', new App\Rules\RestrictPeriodRule(2)]])->errors()->all();
=> [
     "2019-01-29以降を指定してください",
   ]
>>>

Laravel 5.6で追加されたバリデーション

Sat, 23 Mar 2019 00:58:11 +0900

私が使用しているLaravelのバージョンは5.5、ついこの前にリリースされたと思いきや、なんと8/30/2017のことらしくもう1年半以上も経過。LTSということで2年間の長期サポートだからのんびりとしていたら、もうこの夏でサポートの期限切れです。キャッチアップ、ということで去年の2月にリリースされた5.6バージョン（しかし、もうサポートされていない）に追加されたバリデーションをチェックします。

これが、5.6のバリデーションの一覧です。ブルーでハイライトしているのが5.5にはなく5.6に追加されたバリデーションです。

追加されたもので、すぐに使えそうなものは、

Greater Than gt Greater Than Or Equal　gte Less Than　lt Less Than Or Equal　lte

早速使ってみましょう。validator()はLaravelのヘルパーですが、こちらも読んでください。

Psy Shell v0.9.9 (PHP 7.1.14 — cli) by Justin Hileman
>>> $input = ['quantity' => 5];
=> [
     "quantity" => 5,
   ]
>>> validator($input, ['quantity' => 'required|integer|gt:4'])->errors()->all();
=> []
>>> validator($input, ['quantity' => 'required|integer|gt:5'])->errors()->all();
=> [
     "The quantity must be greater than 0.",
   ]
>>> validator($input, ['quantity' => 'required|integer|gte:5'])->errors()->all();
=> []
>>> validator($input, ['quantity' => 'required|integer|lt:6'])->errors()->all();
=> []
>>> validator($input, ['quantity' => 'required|integer|lte:5'])->errors()->all();
=> []

ちなみに、これらがない5.5では、以下のようにmin, max, not_inを組み合わせて同じようなバリデーションが可能です。

>>> validator($input, ['quantity' => 'required|integer|min:5'])->errors()->all();
=> []
>>> validator($input, ['quantity' => 'required|integer|min:5|not_in:5'])->errors()->all();
=> [
     "The selected quantity is invalid.",
   ]

しかし、このメッセージでわかりにくいので、

>>> validator($input, ['quantity' => 'required|integer|min:5|not_in:5'], ['not_in' => 'The quantity must be greater than :input.'])->errors()->all();
=> [
     "The quantity must be greater than 5.",
   ]

と、カスタムメッセージを与える必要あります。面倒ですね。

バリデーションの実例：条件付きの必須

Sun, 07 Oct 2018 09:55:41 +0900

今回は、他の項目により対象の項目が必須となるかどうかのルールを紹介します。

required_if required_unless required_with required_with_all required_without required_without_all

バリデーションの実例：更新

Sun, 07 Oct 2018 05:31:08 +0900

以下のリンクの記事掲載のコードに更新があります。

バリデーションの実例：基本データタイプバリデーションの実例：特殊データタイプバリデーションの実例：日付バリデーションの実例：定数値を引数とする条件バリデーションの実例：他の項目の値を引数とする条件バリデーションの実例：DBの情報を引数とする条件

入力には項目があり値がある（nullや空でない）という仮定として、チェックのルールにrequiredを追加して、以下のテストを削除しました。すっきりしてわかりやすくなったと思います。

            [['field' => null],    false],
            [['field' => ''],      true],
            [['field' => ' '],     true], // space

しかし、acceptedのように空の値が重要なときには上のテストは省かれていません。

バリデーションの実例：項目の存在、項目の値の存在

Sun, 02 Sep 2018 05:17:50 +0900

今回は、指定の項目の存在、その項目の値の存在を判定するルールを紹介します。これらのルールは主に他のルールと混合して使用します。

nullable present filled required

required以外は、ややわかりづらいルールなので表にしてみました。結果がtrueとなる条件です。値が「なし」というのは、空の文字列（半角の空白文字があるならトリムします）あるいはnullのことです。

ルール	項目	値
nullable	あってもなくても	あってもなくても
present	あり	あってもなくても
filled	あってもなくても	あり
required	あり	あり

以下の実例では、nullable|stringのように他のルールとの混合の例としています。また比較のために、stringだけのテストも掲載しました。

バリデーションのあれこれ

Sun, 05 Aug 2018 05:15:42 +0900

バリデーションの実例をちょっと休んで、実際にバリデーションを実行する部分を見てみます。お客さんのプロジェクトで最近この辺を詳しく見る機会があったので、皆さんと共有です。

一般的にはコントローラで使わるのですが、以下のようにいくつかあります。

リクエストのvalidate()メソッド

まず、代表的（5.5の時点で）なのがLaravelのドキュメンテーションの例としても使われている、Requestオブジェクトのメソッド、validate()。

...
public function store(Request $request)
{
    $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // The blog post is valid...
}

このvalidateでは、それだけで与えられたルールの配列をもとに入力値、この場合、$request->all()を判定して、問題があるなら、エラーメッセージと入力値とともに前のページに戻ります。

しかし、驚くことに、これはRequestのクラスのメソッドではありません！メソッドの形をしたマクロで、以下のファイルで定義されています（このマクロに関しては将来投稿を作成する予定です）。

vendor/laravel/framework/src/illuminate/Foundation/Providers/FoundationServiceProvider.php

<?php

namespace Illuminate\Foundation\Providers;

use Illuminate\Http\Request;
use Illuminate\Support\AggregateServiceProvider;

class FoundationServiceProvider extends AggregateServiceProvider
{
    /**
     * The provider class names.
     *
     * @var array
     */
    protected $providers = [
        FormRequestServiceProvider::class,
    ];

    /**
     * Register the service provider.
     *
     * @return void
     */
    public function register()
    {
        parent::register();

        $this->registerRequestValidate();
    }

    /**
     * Register the "validate" macro on the request.
     *
     * @return void
     */
    public function registerRequestValidate()
    {
        Request::macro('validate', function (array $rules, ...$params) {
            validator()->validate($this->all(), $rules, ...$params);

            return $this->only(collect($rules)->keys()->map(function ($rule) {
                return str_contains($rule, '.') ? explode('.', $rule)[0] : $rule;
            })->unique()->toArray());
        });
    }
}

コントローラのValidatesRequestsトレイトのvalidate()メソッド

先の例を使えば、以下のようになります。

...
public function store(Request $request)
{
    $this->validate($request,
        [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
       ]);
...
}

validate()の第１引数にリクエストのオブジェクトを渡します。こちらも、$request->all()を判定して、問題があるなら、エラーメッセージと入力値とともに前のページに戻ります。

このvalidateは、ValidateRequestsのトレイトのメソッドで、以下のようにコントローラの親クラスで宣言されています。

app/Http/Controllers/Controller.php

namespace App\Http\Controllers;

use Illuminate\Foundation\Bus\DispatchesJobs;
use Illuminate\Routing\Controller as BaseController;
use Illuminate\Foundation\Validation\ValidatesRequests;
use Illuminate\Foundation\Auth\Access\AuthorizesRequests;

class Controller extends BaseController
{
    use AuthorizesRequests, DispatchesJobs, ValidatesRequests;
}

Validatorクラス

上の２つが存在しなかった時代からLaravelをやってきている人たちにはこのやり方は馴染みあります。上の２つに比べてコードが長くなるものの、何をやっているか明確になります。

...
    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();
        }

        // Store the blog post...
    }

バリデーターのオブジェクトを作成してから、判定作業(fails())を実行して、エラーならリダイレクトです。

validator()ヘルパー

最後に、Validator::make()を簡略化したヘルパー、validator()があります。

...
    public function store(Request $request)
    {
        $validator = validator($request->all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);

        $validator->validate();
...

$validator->validate();これ、どこかで見たような。そう、最初のvalidateのマクロの定義の中で使用されています。

このようにバリデーションの実行にいろいろやり方があるのは、Laravelが進化を続けている証拠ですね。

バリデーションの実例：DBの情報を引数とする条件

Sun, 29 Jul 2018 05:10:01 +0900

今回は、引数にDBの情報を指定するバリデーションルールです。今回はデータベースを伴うテストなので、use RefreshDatabase;のトレイトや、factory()->create()が使用されています。

exists unique

後者の方は、会員登録では必須のバリデーションです。会員編集の方でも自分のレコードを外す引数を指定すれば使用可能です。しかし、Laravel 5.5からのRuleの登場で、よりわかりやすい形でも指定できます。これらは皆、今回のテストに含まれています。

バリデーションの実例：他の項目の値を引数とする条件

Sun, 22 Jul 2018 04:08:56 +0900

今回は、引数にフォームの他の項目名を指定するバリデーションルールです。

confirmed different in_array same

個人的には、最初のconfirmed以外は使用したことないですね。in_arrayでは引数として指定する項目が配列であることを示すために、field2.*のように指定する必要あることに注意してください。

さて、他の項目の値を引数としては使わないのですが、入力値が配列のときに、それらの値に重複がないというチェックもここに掲載します。他に入れるところがないというのですが、本当は。配列という投稿を作成してもよいかもしれませんね。

distinct

バリデーションの実例：定数値を引数とする条件

Sun, 15 Jul 2018 07:22:29 +0900

入力値のデータタイプの判定のバリデーションから、今度は条件で判定するバリデーションに移っていきます。条件で判定するバリデーションには、その条件で使用される引数の指定が必要となります。引数には、

文字列や数字の定数値（例：min, maxなど）
同じフォームの他の項目名（例：same、differentなど）
DBの情報（例：exists、unique）

が指定されます。

今回は、最初の引数タイプ、定数値を引数とする条件の以下のバリデーションのテストを掲載します。

digits digits_between size between min max in not_in regex

また、前回紹介した日付のバリデーションの以下も定数値を引数とする条件に含まれますね。

date_format, date_equals, after, after_or_equal, before, before_or_equal

今回の注意点は、size, between, min, maxにおいて、入力値を文字列でなく数値として扱うには、numericあるいはintegerのルールの指定が必要なことです。例えば、integer|between:3,10なルールになります。

バリデーションの実例：日付

Sat, 07 Jul 2018 07:11:01 +0900

今回は日付関連のバリデーションを掲載します。

date date_format date_equals after after_or_equal before before_or_equal

date以外、今回は皆ルールの指定にはパラメータが必要となります。

バリデーションの実例：特殊データタイプ

Sun, 01 Jul 2018 05:57:20 +0900

特殊データタイプとしてのチェックとして以下のテストを掲載します。以下からのリンクだけでなく、この投稿にも掲載してあります。

alpha alpha_dash alpha_num accepted active_url email ip timezone url

今回、まず注意する必要があるのは、alpha, alpha_dash, alpha_numです。これらの「アルファ」は通常の半角英字と仮定してしまいますが、実際はそれぞれの言語でのアルファベット、という意味で、英語ではなく一般的に言語の文字列という意味です。つまり、日本語なら何でもＯＫということになります。ログインなどに使用する半角英数字のアルファベットのバリデーションには、これでなくユーザー定義が必要となりますね。

それから、emailのバリデーション、日本のユーザーに対応するならRFC非準拠のメールアドレス（「.」を「..」などのように連続で使用することや@マークの直前で使用）は対応していません。これも、ユーザー定義のバリデーションが必要となります。

バリデーションの実例：基本データタイプ

Sun, 24 Jun 2018 01:22:59 +0900

基本データタイプのチェックとして以下のテストを掲載します。以下からのリンクだけでなく、この投稿にも掲載してあります。

boolean integer numeric string array json

dateも入れようかと思いましたが、その他の日付関連のバリデーションとともに掲載します。

以下の掲載で説明が必要な部分は、ブーリアンです。入力値がfalseなのにどうしてtrueを返すのか？データをチェックしているのでなく、データがブーリアンタイプであるかをチェックしている、と考えてください。

それから、配列のテストで、どうして空の[]がrequiredによりエラーとなりますが、jsonの{}はエラーとならないのかは謎です。

バリデーションの実例

Sun, 17 Jun 2018 05:54:57 +0900

新しい連載を始めます。

Laravelは、出来合いのヘルパーやバリデーションがあり便利です。もの凄くたくさんあり覚えらないというほどの数ではないですが、すべてを頭の中で保持しておくのも大変です。また、こういう使い方では結果はどうなるのとか、実際に実行してみないとわからないことあります。

例えば、バリデーションのalphaは、文字列がすべて英字からなる（本当？）かをチェックします。このバリデーションを、ログイン名のチェックとかに使うとします。しかし、大文字でもＯＫなのとか、空白文字が入ってもＯＫなのとか、日本語の入力はどうなのとか、調べないとわからないことあります。Laravelのドキュメントではそこまで細かくは説明していません。

前回で説明したようにtinkerで簡単にチェックすることも可能ですが、面倒だなと思うときに、実例を素早く見ることができれば便利だと思いません？

そこで今回から、そんな便利な実例特集を連載する予定です。まず、その１つを見てください。以下は、Laravelのバリデーションのacceptedのユニットテストです。

実例の使い方

先に掲載したコードは、github.comのgistを使用しています。gistは、一般的にスニペットと言われる、コピペ専用が目的のgitのレポジトリです。gitでコード管理するのと同様、cloneやforkの利用も可能です。

上のコードを実際にテストしてみたいなら、ララベル5.5のプロジェクトを作成して、そのプロジェクトのルートのディレクトリで、以下を実行してください。

$ git clone git@gist.github.com:cf781699c05c73d07fdbff8489052ef8.git tests/Unit/Validations/Accepted

コマンドラインで指定したURLは、

gistの画面において、embedのドロップダウンのリストから、Clone via SSHを指定して、表示されたURLを使います。以下の画面では、赤いボックスのところをクリックしてコピーできます。

コマンドの実行は、以下のように、tests/Unit/Validations/Acceptedのディレクトリを作成して、テストのファイルを作成してくれます。

tests/Unit
├── ExampleTest.php
└── Validations
    └── Accepted
        ├── 0.md
        └── AcceptedTest.php

ダウンロードしたところで、テストを実行してみましょう。

$ vendor/bin/phpunit --filter AcceptedTest
PHPUnit 6.5.8 by Sebastian Bergmann and contributors.

.........                                                           9 / 9 (100%)

Time: 201 ms, Memory: 12.00MB

OK (9 tests, 9 assertions)

と９つテストがすべて成功の結果を表示してくれます。

phpunitのデータプロバイダー

先のテストの実行では、９つのテストが成功、とありましたが、９つのテストなるゆえは、上のコードのprovider_acceptedの関数内に９つのデータ配列があるからです。

このユニットテストでは、phpunitのデータプロバイダー機能を使用しています。その機能では、コメントに入れる情報で、どこからデータを受け取るかを指定します。

    /**
     * @test ←　関数がテストの関数であることを指定
     * @dataProvider provider_accepted　←　この関数からデータを取ってくることを指定
     */
    public function accepted($input, $expected)
    {
     ..

provider_accepted()では、

例えば、最初のデータ

[[‘field’ => null], false]

は、

[‘field’ => null]　が　accepted()の最初のパラメの$input

となり、

falseが、$expected

となります。

テストの実行では、９つのデータ配列があるので、データを変えて9回のテストの実行となります。そして、さらにいろいろテストしたいなら、そのデータと期待する結果をそこに追加すればよいだけです。

バリデーションの実例の連載開始

ということで、次回からバリデーションの実例を投稿していきます。まずは、Laravelにある規定のバリデーションですが、それだけでなくユーザー定義のバリデーションもアップしていく予定です。

バリデーション (9) 配列のDistinctと暗黙の拡張

Tue, 01 Nov 2016 21:51:12 +0900

配列のDistinctバリデーション

前回の例題とした商品オプションに、オプション名に同じ値が入ることを禁じるバリデーションを追加します。

これには、配列プレースホルダー .* ともに laravel 5.2 で追加された distinct バリデーションが利用できます。よく考えられていますね。

$rules = [
  'option_id'     => 'required',
  'option_name.*' => 'required_with:option_id.*|distinct',
  'unit_price.*'  => 'required_with:option_id.*|integer|min:0',
  'inventory.*'   => 'required_with:option_id.*|integer|min:0',
];

空の入力に対するdistinct？

ところで、ここまで「オプション名」は必須入力であることを前提としてきましたが、商品オプションが１つだけなら「オプション名」は空のまま「販売単価」と「在庫数」だけ入力できるようにしたい、という要望が現場から上がってくるかもしれません。

もう少し仕様追求すると、商品オプションが２つ以上であっても、先頭（とは限らないかもしれません）の１つは空でよいかもしれません。

このために空の入力が１個まで可というバリデーションルールを追加するとロジックが複雑化します。required_with を外したとき distinct が空文字列もあわせて重複チェックしてくれれば話が簡単ですね。こんなふうに・・・

３つの入力欄のうち２つを空にした場合のリクエストは次のようになります。

Array
(
    [option_name] => Array
        (
            [11] => 
            [12] => 
            [13] => オレンジ
        )

option_name のキー 11 と 12 は同じ値（空文字列）なのだから重複チェックにかかりそうなものです。

しかしこのバリデーションはそんな都合よく機能しません。

distinct バリデーションは、option_name 全体ではなく、配列の値それぞれに働きます。キー 11 の値は配列内で重複してるか？キー 12 の値は・・・と。

そして、バリデーションの原則は値が入力された項目にのみ働きます。このケースでは、そもそもキー 11 と 12 は調査されることなく、キー 13 の値が配列内で重複してるかだけが調べられ、重複なしと判定されるのです。

そう、リクエストが空でも働くのは、required 系バリデーションだけでした。

暗黙の拡張 implicitRules

ここまでくると次の展開が読めましたか？

この課題は解決には、distinct が required と同様に 空リクエストに対してもバリデーションが働く 必要があり、これを実現するのが 暗黙の拡張 ルールです。

この暗黙の拡張を「暗黙の必須」と読んでしまうと理解を間違えます。空リクエストに対するバリデーション、それ以上でも以下でもありません。

暗黙の拡張ルールを作るには、Validator::extendImplicit() メソッドを使います。通常の拡張ルールとして登録されると同時に、暗黙の拡張ルールの名前を収めた配列 $implicitRules にルール名が追加されます。

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

ということは、Validator を継承して作成した customValidaor クラスでは、直接 $implicitRules にルール名を追加することで暗黙の拡張を作ることができます。

以下は、空文字列を含んだ重複判定ができる distinct_with_blank バリデーションの作成例です。

class CustomValidator extends \Illuminate\Validation\Validator {

    public function __construct($translator, $data, $rules, $messages = [])
    {
        parent::__construct($translator, $data, $rules, $messages);

        // 暗黙の拡張に追加
        $this->implicitRules[] = 'DistinctWithBlank';
    }

    /**
     * 空文字列も含む重複判定 distinct_with_blank
     * @param  string $attribute
     * @param  string $value
     * @param  array  $parameters
     * @return true
     */
    public function validateDistinctWithBlank($attribute, $value, $parameters)
    {
        // 標準distinctを呼ぶだけ
        return parent::validateDistinct($attribute, $value, $parameters);
    }

これを用いて option_name.* から required_with を外すと、最初のルール定義は次のようになります。無事に、オプション名の空は１つだけ許可されるようになりました。

$rules = [
  'option_id'     => 'required',
  'option_name.*' => 'distinct_with_blank',
  'unit_price.*'  => 'required_with:option_id.*|integer|min:0',
  'inventory.*'   => 'required_with:option_id.*|integer|min:0',
];

この他にも、DB上の重複をチェックする unique に対し、空入力でも機能する unique_with_blank も状況によっては（DB定義がNULL OKではないなど）ニーズがあるかもしれませんね。

バリデーション (8) 配列をバリデーションする

Sun, 23 Oct 2016 10:47:45 +0900

laravel 5.2 で、バリデーションルールに配列を表す .* というプレースホルダーが使えるようになりました。

例えば、次のような商品オプションのバリデーションを考えます。

入力行の追加UIやドラッグ＆ドロップによるソートはjQueryなどで実装することにします（laravel から離れるので解説は省きます）

この場合、項目数がいくつになるかわからないので、エレメントの属性名を name=“option_name[{{$id}}]" などとし、配列を返すように作りますよね。

リクエストは次のようなものになるでしょう。配列のキーは編集データに依存しますので不定です（ここでは仮に 11, 12, 13 としました）

print_r($request->all());

Array
(
     [option_id] => Array
        (
            [11] => Y
            [12] => Y
            [13] => Y
        )

    [option_name] => Array
        (
            [11] => ホワイト
            [12] => ブラック
            [13] => オレンジ
        )

    [unit_price] => Array
        (
            [11] => 1000
            [12] => 1200
            [13] => 980
        )

    [inventory] => Array
        (
            [11] => 30
            [12] => 20
            [13] => 15
        )
)

最低必要なバリデーションとしては、「保存」が少なくとも１つチェックされることと、「保存」がチェックされた行は必須入力となること、そして「販売単価」と「在庫数」の数値判定です。

苦労していた配列のバリデーションですが、5.2 からは次のようなルール定義が可能になったのです。

$rules = [
  'option_id'     => 'required',
  'option_name.*' => 'required_with:option_id.*',
  'unit_price.*'  => 'required_with:option_id.*|integer|min:0',
  'inventory.*'   => 'required_with:option_id.*|integer|min:0',
];

$messages = [
  'option_id.required' => '保存するレコードを少なくとも１つ選択してください',
];

「オプション名」、「販売単価」、「在庫数」のルール定義には属性名に .* を加えることで、配列の値それぞれにバリデーションが適用されるようになります。

「保存」がチェックされた行だけ入力が必要なので、required_with の引数も option_id.* となります。一方で「保存」の必須チェックは配列全体の required です。

配列部分のエラーは array_dot() による配列ドット記法で返ってきますので、Bladeテンプレートのエラーメッセージ表示は次のような書き方になります。

{{ $errors->first("unit_price.$id") }}

laravel 4 や 5.1 以前での配列バリデーション

後出しジャンケンでの自慢話となってしまいますが、私たちのプロジェクトでは lavavel 4 のころから配列に対するバリデーションを、5.2 と同じルールの書き方で処理してきました。

もともと laravel のバリデーションでは、リクエストは配列のまま処理されるでのはなく、array_dot によるドット記法の一次元データに変換されて内部処理されていました。

例えば次のように、配列のキーが固定されてる入力フォームの場合ならば、

<input type="text" name="name[last]" value="{{ old('name.last') }}">
<input type="text" name="name[first]" value="{{ old('name.first') }}">

Array
(
     [name] => Array
        (
            [last] => 山田
            [first] => 太郎
        )
)

以下のようにドット記法でルールを定義することで、配列データもバリデーションできたのです。

$rules = [
  'name.last'  => 'required',
  'name.first' => 'required',
];

最初に、「5.2 で .* というプレースホルダーに対応した」と書き、配列バリデーションそのものに対応したと書かなかった意味がここにあります。このプレースホルダーの変換を自分で対応すれば、5.1 以前や 4 でも同様の処理ができるわけです。

定義するルール：

$rules = [
  'option_id'     => 'required',
  'option_name.*' => 'required_with:option_id.*',
  'unit_price.*'  => 'required_with:option_id.*|integer|min:0',
  'inventory.*'   => 'required_with:option_id.*|integer|min:0',
];

変換後のルール：

$rules = [
  'option_id'      => 'required',
  'option_name.11' => 'required_with:option_id.11',
  'option_name.12' => 'required_with:option_id.12',
  'option_name.13' => 'required_with:option_id.13',
  'unit_price.11'  => 'required_with:option_id.11|integer|min:0',
  'unit_price.12'  => 'required_with:option_id.12|integer|min:0',
  'unit_price.13'  => 'required_with:option_id.13|integer|min:0',
  'inventory.11'   => 'required_with:option_id.11|integer|min:0',
  'inventory.12'   => 'required_with:option_id.12|integer|min:0',
  'inventory.13'   => 'required_with:option_id.13|integer|min:0',
];

この変換は次のような関数で対応できます。ベースコントローラかトレイトに入れて、バリデーション直前にルールの変換を挿入してみてください。

/**
 * 配列バリデーションルールの変換
 * @param \Illuminate\Http\Request $request
 * @param array                    $rules
 * @param array                    $messages
 */
public static function setArrayRules($request, &$rules, &$messages)
{
    foreach($rules as $field => $rule)
    {
        // field文字列は foo.* か？
        if (!preg_match('/^(.+)\.\\*$/', $field, $m)) continue;

        // fooはリクエストに存在して配列か？
        $name = $m[1];
        if (!($req = $request->get($name)) || !is_array($req)) continue;

        foreach(array_keys($req) as $i)
        {
            // rulesに foo.$i を複写
            $rules["$name.$i"] = str_replace('*', $i, $rule);

            // messagesにfoo.$i.barがあれば複写
            foreach($messages as $key => $message)
            {
                if (!preg_match("/^$name\.\\*\.(.+)$/", $key, $m)) continue;
                $messages["$name.$i.{$m[1]}"] = $message;
            }
        }
        unset($rules[$field]);
    }
}

p.s.

上で紹介した setArrayRules() では、次のような配列の記述には対応してません。もし必要とするならばご自身で考えてみてくださいね。

Bladeソース:

<input type="text" name="option[{{$id}}][name]" value="old("opton.$id.name")">

バリデーションルール:

 'option.*.name' => 'required_with:option_id.*',

バリデーション (7) エラーメッセージのリプレーサー

Tue, 18 Oct 2016 20:11:25 +0900

等号を含む日付の最大最小

日付の最大最小 after, before の比較はなぜか等号を含みません。英単語の意味を厳格にプログラム仕様に落とし込んだようですが、実際の使い勝手としては等号を含んでほしかったところです。

これを等号を含むように拡張してしまうと、前回の min, max を拡張したのと違って意味が変わってしまいます。そこで、start, end を新たに作成して追加してみましょう。

'start_date' => 'date|start:today',      // 今日を含んでそれ以降
'end_date'   => 'date|start:start_date', // 開始日を含んでそれ以降

最低限の追加で済むように、内部で標準バリデーションの after, before を呼び出すようにします。標準が等号を含まないのですから、普通に考えると after に与えられた引数を -1（秒）し、before の引数を +1（秒）するのがわかりやすいでしょう。

しかし、これらの引数は日付そのものだけではなく、上に示したように比較対象の属性名が与えられることがありますから、加減算をするには属性名から参照先の日付を取得するコードを自分で書かなければなりません。

そこで発想を逆転して、検査する入力値の日付を +1（秒）して after に、-1（秒）して before に与えることにします。意味を考えると分かりづらいですが、相対的なものなので正負を逆転しただけです。

作成したバリデーションルールは次のとおりです。

public function validateStart($attribute, $value, $parameters)
{
    $value = date('Y-m-d H:i:s', strtotime($value.' +1 sec'));

    return parent::validateAfter($attribute, $value, $parameters);
}

public function validateEnd($attribute, $value, $parameters)
{
    $value = date('Y-m-d H:i:s', strtotime($value.' -1 sec'));
/*
    // 比較相手が 日付のみ場合は 23:59:59を補完する
    if ((($date = $this->getValue($parameters[0])) || ($date = $parameters[0]))
        && !preg_match('/:/', $date))
    {
        $parameters[0] = date('Y-m-d 23:59:59', strtotime($date));
    }
*/
    return parent::validateBefore($attribute, $value, $parameters);
}

validateEnd() のコメントされたコード部分は、Datetime と Date を比較したときに起きる問題の補正です。

例えば、DBレコードの販売期間が Datetime で、出荷期間が Date のときなど、異なる日付型の間で比較が必要な場合には有効にしてください。補正は end のみに必要で、start には必要ありません。

$tests = [
    ['2016-10-10', '2016-10-10 10:00:00'],
    ['2016-10-10 10:00:00', '2016-10-10'],
];
foreach($tests as $i => $date) {
    printf("%d => %d %d\n", 
    $i, ($date[0] >= $date[1]), ($date[0] <= $date[1]));
}

結果

0 => 0 1 // ('2016-10-10' >=' 2016-10-10 10:00:00') == FALSE は正しい！
1 => 1 0 // ('2016-10-10 10:00:00' <= '2016-10-10 23:59:59'に補正が必要

メッセージへの引数の展開

さて、前回、比較対象の属性名を引数に持てるように拡張した min, max において、エラーメッセージの引数部分が、バリデーション言語ファイルの定義通りの日本語に展開されませんでした。今回追加作成した start, end にいたっては、英文字の属性名にすら展開されません。この問題を解決しましょう。

今、バリデーション言語ファイルが次のように定義されているとします。

resources/lang/ja/validation.php

'after'  => ':attributeが:dateより前',
'before' => ':attributeが:dateより後',
'max' => [
  'numeric' => ':attributeが:maxよりも大きい',
],
'min' => [
  'numeric' => ':attributeが:minよりも小さい',
], 

// 追加

'start'  => ':attributeが:dateより前',
'end'    => ':attributeが:dateより後',

// 項目名

'attibutes' => [
  'end_date'   => '終了日',
  'start_date' => '開始日',
  'unit_cost'  => '仕入単価',
  'unit_price' => '販売単価',
],

このとき、それぞれのルールに対するエラーメッセージは次のように展開されます。

区分	ルール	エラーメッセージ	課題
標準	'unit_price' => 'min:0'	販売単価が0より小さい
拡張	'unit_cost' => 'max:unit_price'	仕入単価がunit_priceより大きい	日本語にはならない
標準	'end_date' => 'before:start_date'	終了日が開始日より後
追加	'end_date' => 'end:start_date'	終了日が:dateより後	属性名への展開すらない

属性名を引数に取れるように拡張した min, max で英文字の属性名が展開できるのは、数値が与えられたときの標準の展開がそのまま適用されているためです。

カスタムプレースホルダー

エラーメッセージの中の :attribute や :min, :date はプレースホルダーと呼ばれます。

カスタムのプレースホルダーを追加するには、サービルプロバイダーの boot メソッドの中で、Validator::replacer() メソッドを呼び出します。

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

もしくは、Validator を継承した CustomVlidator クラスでは、addReplacer() メソッドか、複数のリプレーサーを配列にしてまとめて登録できる addReplacers() メソッドで登録できます。

$this->addReplacer('foo', function($message, $attribute, $rule, $parameters) {
    return str_replace(...);
});

リプレーサーの中身は簡単な文字列置換です。

与えられたエラーメッセージ（$message）に対して、プレースホルダー文字列（":min" や ":date" など）を引数の文字列（$parameters[0]）に置き換えるコードを記述します。

引数（$parameters[0]）は与えられた最小値の値や、比較相手の英文字の属性名です。これを日本語に展開するには、バリデーション言語ファイルの $attributes 配列から対応語を参照する getAttribute() メソッドを使います。

以下、CustomValidator クラスのコンストラクタで min, max, start, end にリプレーサーを登録するサンプルです。共通部分が多いのでクロージャを変数に代入し、setReplacers() でまとめて配列登録しました。

これで、エラーメッセージは期待通りすべて日本語に展開されるようになりました。

<?php

namespace App\Services;

class CustomValidator extends \Illuminate\Validation\Validator
{
    public function __construct($translator, $data, $rules, $messages = [])
    {
        parent::__construct($translator, $data, $rules, $messages);

        // 汎用（ルールと同名）
        $replacer = function($message, $attribute, $rule, $parameters) {
            return str_replace(':'.$rule, $this->getAttribute($parameters[0]), $message);
        };
        // 日付
        $date = function($message, $attribute, $rule, $parameters) {
            return str_replace(':date', $this->getAttribute($parameters[0]), $message);
        };

        $this->addReplacers([
            'min' => $replacer, 'max' => $replacer, 'start' => $date, 'end' => $date
        ]);
    }

バリデーション (6) 他の属性の値を参照

Sat, 15 Oct 2016 19:30:29 +0900

日付の最大最小 after, before では、引数に値（日付）を与えるだけでなく、比較対象の属性の名前を与えることができます。むしろ具体的な日付を引数にすることのほうがまれでしょう。

'date_start' => 'date|before:today',
'date_end'   => 'date|after:date_start',

このような使い方は、数値型の最大最小 min, max でも使用したいこともありますよね？

例えば、次のような関係です。

'unit_price' => 'required|integer|min:0',
'unit_cost'  => 'required|integer|min:0|max:unit_price',

標準バリデーションの min と max を拡張して、比較対象の属性名を引数に持てるようにしてみましょう。

getValue()

バリデーションクラスにルールを登録するときの雛形は次のようなものでした。一見すると引数には、ルールを定義した属性に関する情報しか与えられません。

/**
 * 追加バリデーション
 * @param  string  $attribute  検査する属性名
 * @param  string  $value      入力された値
 * @param  array   $parameters 引数の配列
 * @return boolean
 */
public function validateHoge($attribute, $value, $parameters)
{
  //
}

しかし、バリデーションクラスにはリクエストされたすべての属性に関する情報が与えれていて、他の属性に入力された値も getValue() で得ることができます。getValue() の引数は属性名です。

よって、次のバリデーションは必ず TRUE を返します。

public function validateHoge($attribute, $value, $parameters)
{
   return ($value == $this->getValue($attribute));
}

min と max の拡張

min, max の引数は、属性の型が何であろうと必ず数値を取ります。

そこで、引数が数値（is_numeric）でないときを限定し、引数を属性名とした値が存在するならそれを新たなしきい値としました。

/**
 * 最小値 min
 * @param string $attribute
 * @param string $value
 * @param array $parameters	0 => 比較する属性名
 * @return true
 */
protected function validateMin($attribute, $value, $parameters)
{
    if (!is_numeric($parameters[0]) && 
        !is_null($val = $this->getValue($parameters[0])))
    {
        $parameters[0] = $val;
    }
 
    return parent::validateMin($attribute, $value, $parameters);
}

/**
 * 最大値 max
 * @param string $attribute
 * @param string $value
 * @param array $parameters	0 => 比較する属性名
 * @return true
 */
protected function validateMax($attribute, $value, $parameters)
{
    if (!is_numeric($parameters[0]) &&
        !is_null($val = $this->getValue($parameters[0])))
    {
        $parameters[0] = $val;
    }
 
    return parent::validateMax($attribute, $value, $parameters);
}

＊　＊　＊　＊

さて、拡張した最大最小バリデーションですが、このままではエラーメッセージが与えられた引数の属性名のままとなり、言語ファイルによる置き換えが行われません。

本来の最大最小が与えられた引数そのものを、メッセージのプレースホルダー :max と置き換えることしか想定していないからです。この部分の解決については次回にまとめる予定です。

バリデーション (5) 最大値と最小値

Mon, 10 Oct 2016 19:42:42 +0900

バリデーション言語ファイルを編集するときにお気づきと思いますが、Laravel標準バリデーション Max と Min は（他に Size、Between も）調査対象の属性の型でその挙動を変えます。

'max' => [
    'numeric' => ':attributeの値が:maxを超えています',
    'file'    => ':attributeのサイズが:max kBを超えています',
    'string'  => ':attributeの文字数が:maxを超えています',
    'array'   => ':attributeの個数が:maxを超えています',
],
'min' => [
    'numeric' => ':attributeの値が:minに足りません',
    'file'    => ':attributeのサイズが:min kBに足りません',
    'string'  => ':attributeの文字数が:minに足りません',
    'array'   => ':attributeの個数が:minに足りません',
],

ここで問題となるのは、文字列型が入力した文字数カウントとの比較になることです。文字列比較の大小によるバリデーションは存在してません。

例えば日付型の属性に対する開始日のつもりで Min を指定しても、文字数判定となり、期待したバリデーションにはなりません。

'date_start' => 'date|min:'.date('Y-m-d'),    // 開始日判定にはならない

日付の最大値と最小値

日付型の属性の前後関係の判定には、専用の after と before が用意されています。しかも、引数の文字列は strtotime で処理されるので次のような指定が可能です。

'date_start' => 'date|after:today',    // 今日より大（明日以降）
'date_end'   => 'date|befor:+1 year',  // １年以内

または属性名を引数に持つことができるので、期間指定のバリデーションに使うことが出来ます。

'date_end'   => 'datetime|after:date_start',

ただし、after, befor の比較は等号を含みませんので注意が必要です。

数値型のカスタムバリデーション

例えば1以上の整数（自然数）を判定するカスタムバリデーション natural_number を作成した場合、それを min や max で大小判定したときは、正しく数値として判定されるでしょうか？

結論を言えば、カスタムバリデーション natural_number は（そのままでは）、入力された値が数値であっても、文字列として判断され、文字数でカウントされてしまいます。

'quantity' => 'requied|natural_number|max:10', // 10桁（ 10億）まで可

では、数値として認められるにはどのようにしたら良いのでしょうか。

vender の Validation.php でコードを追うと、getSize() メソッドにおいて次のように型判定されていることがわかります。

1	入力値が数値（`is_numeric`）でバリデーションに `numeric` か `integer` があれば、その値を返す
2	入力値が配列（`is_array`）なら配列の個数を返す
3	入力値が `File` インスタンスならファイルサイズを kB で返す
4	それ以外は文字数（`mb_strlen`）を返す

数値として判定されるには、入力された値が数値であるかどうかだけでなく、バリデーションに numeric か integer が含まれなければなりません。これでは他のどんなルールであっても数値と判定されることはないのです。

numericRules

この数値と判断されるためのバリデーションルールは、変数 $numericRules で定義されていました。

protected $numericRules = ['Numeric', 'Integer'];

カスタムバリデーションとして数値型のルールを自作した場合には、これにルール名を追加すればよいわけです。

変数 $numericRules を protected で再定義して上書きするか、コンストラクタで必要分だけ追加します。……再定義する場合は Numeric と Integer を忘れずに。

public function __construct($translator, $data, $rules, $messages = [])
{
    parent::__construct($translator, $data, $rules, $messages);

    $this->numericRules[] = 'NatrualNumber';
}

/**
 * 自然数 natural_number
 *
 * @param string $attribute		検査する属性名
 * @param string $value			検査する値
 * @return bool
 */ 
public function validateNaturalNumber($attribute, $value)
{
    if ($this->validateInteger($attribute, $value))
    {
        return ($value > 0);
    }

    return false;
}

バリデーション (4) DateとDatetime

Mon, 10 Oct 2016 13:59:04 +0900

Laravel 標準の Date バリデーションは、次のときに TRUE を返します。

OR		値がPHPの `DateTime` クラスのインスタンスである
AND	値が `strtotime` で理解できる文字列である
`date_parse` で年月日を返す
`checkdate` で年月日が妥当である

文字列の具体例でまとめると以下のようになります。

	文字列	バリデーション	MySQL保存
例01	now	FALSE
例02	+1 day	FALSE
例03	next Thursday	FALSE
例04	2016-09-30 + 1day	TRUE	×
例05	30 September 2016	TRUE	×
例06	2016-09-30	TRUE	◯
例07	20160930	TRUE	◯
例08	2016/09/30	TRUE	◯
例09	09/30/2016	TRUE	×
例10	09-30-2016	FALSE
例11	30/09/2016	FALSE
例12	2016-09-30 10:10:00	TRUE	◯

date_parse を通すため例01〜例03のような論理指定は弾かれますが、例04のような記述では前半部分が年月日の配列値を返すためバリデーションは通ります。また、アメリカ式の月日年（例09）が通って、ヨーロッパ式の日月年（例11）は弾かれます（これは環境のタイムゾーンに影響されるでしょう）。

いずれにせよ、バリデーションに通ってもそのままデータベースに保存できるとは限りません。データベース保存を前提にするなら、ISO-8601 の “YYYY-MM-DD” 書式に限定したほうが何かと都合が良いですね。

date_format による ISO-8601限定

入力され日付のフォーマットを限定するために date_format が用意されています。引数は date_parse_from_format を通して処理されます。 date と date_format は両方を同時に使用することはできません。

'date'     => 'date_format:Y-m-d',
'datetime' => 'date_format:Y-m-d H:i:s',

Date と Datetime の拡張

データベースの保存フィールドで Date と Datetime を区別し、入力フォームのインターフェースもこの２つしかないならば、date_format を使用せずに、date バリデーションを拡張してしまうこともできます。

書式を正規表現で限定してからオリジナルのバリデーションを通せばよいでしょう。

    /**
     * date (without datetime)
     *
     * @param string $attribute
     * @param string $value
     * @return true
     */
    protected function validateDate($attribute, $value)
    {
        // YYYY-MM-DD に限定する
        if (!preg_match('/^[0-9]+-[0-9]+-[0-9]+$/', $value)) return false;

        return parent::validateDate($attribute, $value);
    }

    /**
     * datetime
     *
     * @param string $attribute
     * @param string $value
     * @return bool
     */
    public function validateDatetime($attribute, $value)
    {
        // YYYY-MM-DD hh:mm に限定する
        if (!preg_match('/^[0-9]+-[0-9]+-[0-9]+ ([0-9]+):([0-9]+)/', $value, $m)) return false;

        return parent::validateDate($attribute, $value);
    }

validateDete() は標準の置き換えなので protected 宣言ですが validateDatetime() は追加関数として public で宣言しています。

日付入力のフォームインターフェイス

入力バリデーションとして Date と Datetime を用意したならば、入力フォームもそれに対応しなければなりませんが、HTML5 の日付フォームはブラウザの対応に依存し、非対応な環境を無視したとしてもユーザーインターフェイスが人によって異なりサポートが難しいものです。

私たちのプロジェクトの管理画面では、Bootstrapベースの SmartAdmin を導入してインターフェイスの統一を図っています。

SmartAdmin の日付フォームは jQuery UI Datepicker と Bootstrap Timepicker の組み合わせを採用していますが、HTML5の datetime や datetime-local には対応してません。スクリプトを書くことで datetime 属性（厳密には datetime-local 属性）の入力フォームを実現する必要があります。

bladeソース（の概念）と対応するjQueryスクリプト

<div class="input-group-datetime">
  <input type="hidden" name="date_start" value="{{ old('date_start') }}">
  <input class="datepicker">
  <input class="timepicker">
</div>

$('.input-group-datetime').on('change', 'input:visible', function() {
  // 日付または時刻が変更された
  var $parent = $(this).parents('.input-group-datetime'),
    dt = $parent.find('.datepicker').val(),
    tm = $parent.find('.timepicker').val();
  if (dt && !tm) {
    // 時刻が空なら00:00で補完
    tm = '00:00';
    $parent.find('.timepicker').val(tm);
  }
  if (!dt) {
    // 日付が空なら時刻も削除
    $parent.find('.timepicker').val('');
  }
  // 日時を合成して値を格納
  $parent.find(':hidden').val((dt) ? dt + ' ' + tm + ':00' : '');
});

バリデーション (3) 既存バリデーションの置き換え

Mon, 15 Aug 2016 10:27:51 +0900

Laravelには最初から利用可能なバリデーションルールが多数存在していますが、そのいくつかは実用にならなかったり、自分好みに挙動を変えたりしたいこともあります。

CustomValidator クラスは標準 Validator を継承していますので、これらを置き換えて上書きすることが可能です。

vendor/laravel/framework/src/Illuminate/Validation/Validator.php

ここから関数宣言をコピーして、前回作成した CustomValidator クラスのファイルに貼り付けて編集します。引数はそれぞれの関数によって異なりますし、宣言が public ではなく protected であることに注意してください。

email

標準の email バリデーションは実在してるメールアドレスがエラー判定になることがあります。これを解決するために正規表現による判定に置き換えてみたものです。

    /**
     * email
     *
     * @param string $attribute
     * @param string $value
     * @return true
     */
    protected function validateEmail($attribute, $value)
    {
        return (preg_match("/^([*+!.&#$|\'\\%\/0-9a-z^_`{}=?~:-]+)@(([0-9a-z-]+\.)+[0-9a-z]{2,10})$/i", $value));
    }

管理画面では、メール送信者の指定などで名前付きメールアドレスの入力を容認する場面もあります。ついでに email_with_name を作成しておきましょう。

クラスメソッドとして関数を書いていますので、内部で他のバリデーションルールを呼び出して使用することができます。ここでは先に上書きした email を使用するので $this->validateEmail() で呼び出していますが、標準ルールを呼び出すなら parent::validateEmail() となります。

    /**
     * email_with_name
     *
     * @param string $attribute
     * @param string $value
     * @return true
     */
    public function validateEmailWithName($attribute, $value)
    {
        if (preg_match('/<(.*)>$/', $value, $m)
        {
            $value = $m[1];
        }

        return $this->validateEmail($attribute, $value);
    }

alpha, alpha_dash, alpha_num

これらアルファベット系の標準バリデーションは、全角英数字の文字コードを通します。

半角のasciiコードだけの入力許可に絞るため、これらも正規表現によるバリデーションルールに置き換えます。

/**
 * alpah
 *
 * @param string $attribute
 * @param string $value
 * @return true
 */
protected function validateAlpha($attribute, $value)
{
    return (preg_match("/^[a-z]+$/i", $value));
}

/**
 * alpah_dash
 *
 * @param string $attribute
 * @param string $value
 * @return true
 */
protected function validateAlphaDash($attribute, $value)
{
    return (preg_match("/^[a-z0-9_-]+$/i", $value));
}

/**
 * alpah_num
 *
 * @param string $attribute
 * @param string $value
 * @return true
 */
protected function validateAlphaNum($attribute, $value)
{
    return (preg_match("/^[a-z0-9]+$/i", $value));
}

ただし、ユーザが入力した全角英数に対してただエラーを返すようなユーザーインターフェースは褒められたものではありませんね。

入力を受け付けてからphpで半角に変換するという方法もありますが、私たちはjQueryスクリプトで入力前に変換する方法を選択しています。

jQueryスクリプトの例:

			var toHankaku = function (strVal){
				// 半角変換
				var halfVal = strVal.replace(/[！-～]/g, function(tmpStr) {
					// 文字コードをシフト
					return String.fromCharCode(tmpStr.charCodeAt(0) - 0xFEE0);
				});

				// 文字コードシフトで対応できない文字の変換
				halfVal = halfVal.replace(/”/g, "\"")
					.replace(/[ｰー―－‐]/, "-")
					.replace(/’/g, "'")
					.replace(/‘/g, "`")
					.replace(/￥/g, "\\")
					.replace(/　/g, " ")
					.replace(/?/g, "~");

				return halfVal;
			};

			$("input.en").change(function() {
				var $this = $(this);
				$this.val(toHankaku($this.val()));
			});

バリデーション (2) CustomValidatorを追加

Sun, 14 Aug 2016 11:35:17 +0900

カスタムバリデーションのクラスを追加するには、サービスプロバイダーで次のようにクラスを登録します。

追加するクラスの名前や位置はどのようなものでもかまいせん。ここでは、ディレクトリパス app/Services に CustomVaidator.phpを作成し、AppServiceProvider に登録することにします。

app/Providers/AppServiceProvider.php

<?php

namespace App\Providers;
 
use Validator;
use Illuminate\Support\ServiceProvider;
use App\Services\CustomValidator;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
         Validator::resolver(function($translator, $data, $rules, $messages)
        {
            return new CustomValidator($translator, $data, $rules, $messages);
        });
    }
 
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }
}

次に、標準の Validator を継承する CustomValidator を作成します。前回 AppServiceProvier.php に直接登録したバリデーションルールを、こちらに移します。

app/Service/CustomValidator.php

<?php

namespace App\Services;

class CustomValidator extends \Illuminate\Validation\Validator 
{
    /**
     * kana
     *
     * @param string $attribute
     * @param string $value
     * @return bool
     */
     public function validateKana($attribute, $value)
     {
        // かな、半角空白、全角空白、全角記号を許可
        return preg_match("/^[ぁ-んー 　！-＠［-｀｛-～]+$/u", $value);
     }
}

こうして専用のバリデーションクラスを作成すると、それぞれのバリデーションルールは通常のメソッドとして実行できるようになり、ユニットテストの作成も容易になります。

$bool = CustomValidator::validateKana('kana', $request->get('kana'));

前回との重複になりますが、エラーメッセージをバリデーション言語ファイルの「Validation Language Lines」グループに追加します。

'unique' => ':attribute に指定された値はすでに存在しています',
'url'    => ':attribute のフォーマットが正しくありません',
 
// カスタムバリデーション
 
'kana'   => ':attribute は全角のひらがなで入力してください',

これでふりがなバリデーションをどこでも利用できるようになりました。

'name_kana' => 'required|kana',

次回から、このクラスにいろいろなルールを登録していきましょう。

ところで、ふりがなに「カタカナ」を強要するサイト設計が多いことに苛立つのは私だけでしょうか？無駄にカタカナを入力するとIMEの辞書学習が汚れ、その後の漢字変換のリズムが崩れるのです。名簿などの入力作業をすると誰でも体験できるでしょう。
カタカナルールは昔ながらの紙文化の遺物なのでしょう。手書きならばそのほうが識別しやすいに違いないですが、電子データにその配慮は必要ありませんよね。

バリデーション（１）Validatorファサードのextend

Tue, 19 Jul 2016 10:28:50 +0900

はじめまして。ブログ主筆khino氏と同じプロジェクトで仕事をしてます。彼とは別テーマを平行して掲載しますので、これまで順番に読み進めていた方にはちょっと読みにくくなるかもしれませんが、ご容赦ください。

私の最初のテーマはカスタムバリデーションルールです。このシリーズでは、Validatorファサードの基本的な使い方から始めて、より複雑なルールの定義の仕方や、laravel 5.2で追加された配列定義のカスタムバリデーションまで紹介する予定です。

まずは、Validatorファサードのextendを利用する方法から。

コントローラやモデルに依存しない一般的なルールの追加は、サービスプロバイダーの中で定義するのが一般です。

app/Providers/AppServiceProvider.php

<?php

namespace App\Providers;

use Validator;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
         Validator::extend('kana', function($attribute, $value, $parameters, $validator) {
            // 半角空白、全角空白、全角記号、全角かなを許可
            return preg_match("/^[ぁ-んー 　！-＠［-｀｛-～]+$/u", $value);
        });    
    }

    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }
}

例は全角ひらがなだけを許可するバリデーションですが、見たとおり正規表現による判定を行っています。カスタムバリデーションを使いこなす前に、正規表現を使いこなさなければなりませんが、それはまた別に勉強してくださいね。

エラーメッセージはバリデーション言語ファイルに追加しておきましょう。追加するのは「Validation Language Lines」のグループの末尾です。

resouces/lang/ja/validation.php に追加

    'unique' => ':attribute に指定された値はすでに存在しています',
    'url'    => ':attribute のフォーマットが正しくありません',

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

    'kana'   => ':attribute は全角のひらがなで入力してください',

「Custom Validation Language Lines」のグループは、属性名とルールの組み合わせでメッセージを独自のものにすると言う意味での「カスタム」です。

    'custom' =>[
        'password'  => [
            'alpha_num' => 'パスワードは10文字以上40文字以下の英数字で入力してください',
            'between'   => 'パスワードは10文字以上40文字以下の英数字で入力してください',
        ],
    ],

また、言語ファイル末尾の「Custom Validation Attributes」に属性名の訳を追加しておきましょう。メッセージ内の「:attribute」の部分に用いられるようになります。

    'attributes' =>[
        'name'  => '名前',
        'email' => 'メールアドレス',
    ],

また、モデルやコントローラに依存して、そこでしか使用しないバリデーションなら、次のようにフォームリクエストで定義することも可能です。

しかし、この位置ではユニットテストが作りにくくなるので、次回で説明するようにカスタムバリデーションクラスを作成して、すべてのバリデーションを１つにまとめて管理するほうが良いように思います。

app/Http/Requests/MemberRequest.php

<?php

namespace App\Http\Requests;

use Validator;
use App\Http\Requests\Request;
use App\Member;

class MemberRequest extends Request
{
    public function authorize() {
        return true;
    }

    public function rules()
    {
        Validator::extend('kana', function($attribute, $value, $parameters, $validator) {
            // 半角空白、全角空白、全角記号、全角かなを許可
            return preg_match("/^[ぁ-んー 　！-＠［-｀｛-～]+$/u", $value);
        });

        $member = Member::find($this->member_id);

        switch($this->method())
        {
        case 'POST':
            return [
                'email' => 'required|email|unique:member,email',
                'password'  => 'required|min:6|max:20|confirmed',
                'name' => 'required',
                'kana'  => 'required|kana'
            ];

        case 'PUT':
        case 'PATCH':
            return [
                'email' => 'required|email|unique:member,email,'.$member->member_id.',member_id',
                'name' => 'required',
                'kana'  => 'required|kana'
            ];
        }
    }

    public function attributes()
    {
        return [
            'email'	=> 'メールアドレス',
            'password' => 'パスワード',
            'name' => '名前',
            'kana' => 'ふりがな'
        ];
    }

    public function messages()
    {
        return [
            'kana'	=> ':attribute は全角ひらがなで入力してください',
        ];
    }
}

ファイルのアップロード（２）画像ファイルだけをアップ

Sat, 02 Apr 2016 09:05:53 +0900

ファイルのアップロードと言っても、なんのフォーマットのファイルでもアップをしてよいというわけではありません。たいていは画像ファイルのアップロードになりますが、それでもGIFはアップしてもらいたくない、JPEGだけが欲しいとか。

そのときは、バリデーションを使用してアップしたファイルのMIMEの情報をもとにプログラムで制限します。

まず、jpegだけのファイルをOKとしましょう。

UserController

...
class UserController extends Controller
{
 ...
    public function postUpload(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'file' => 'required|max:10240|mimes:jpeg'
        ]);

        if ($validator->fails())
        {
            return back()->withInput()->withErrors($validator);
        }

        return redirect('user/upload');
    }
}

ここ、jpgでなくjpegであることに注意してください。ファイルの拡張子はたいてい、.jpgですが、ユーザーのマシンのOSが送信するMIMIEは、image/jpegです。

複数の画像フォーマットを許すなら、

UserController

...
class UserController extends Controller
{
 ...
    public function postUpload(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'file' => 'required|max:10240|mimes:jpeg,gif,png'
        ]);

        if ($validator->fails())
        {
            return back()->withInput()->withErrors($validator);
        }

        return redirect('user/upload');
    }
}

と指定します。

会員編集フォーム

Sat, 05 Mar 2016 07:36:54 +0900

ウェブのプログラミングでなんといっても難しいのはフォーム画面のプログラムです。テキスト入力、ドロップダウン、ファイルのアップロード機能、さらにjqueryやangularなどのフロントエンドのjavascriptも入れば、無限の可能性があります。

以前紹介したLaravelの付録の会員認証サンプルの会員登録画面は、php artisan make:authコマンドで自動作成されますが、ログイン後に会員がEメールアドレスや名前を編集する画面は作成されません。

今回はこの編集画面を作成してみます。

まず、新規のコントローラ作成します。

php artisan make:controller User/UserController

を実行して、それを以下のように編集し、

UserController.php

namespace App\Http\Controllers\User;

use Illuminate\Http\Request;

use App\Http\Requests;
use App\Http\Controllers\Controller;
use App\User;

use Auth;
use Validator;

class UserController extends Controller
{
    protected $user;

    public function __construct()
    {
        $this->middleware('auth:user'); // 認証

        $this->user = Auth::guard('user')->user();
    }

    public function getProfile()
    {
        return view('user/profile')->with(['user' => $this->user]);
    }

    public function postProfile(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'name'  => 'required|max:255',
            'email' => 'required|email|max:255|unique:users,email,'.$this->user->id
        ]);

　　　　//　エラーチェック
        if ($validator->fails())
        {
            return back()->withInput()->withErrors($validator);
        }

　　　　// データを更新
        $this->user->update([
            'name'  => $request->input('name'),
            'email' => $request->input('email')
        ]);

        return redirect('user/home');
    }
}

Validationでは、emailのチェックは、$this->user->idを除くusersのレコードを対象に他に同じEメールが使われていないかチェックします。

次に、以下のようなテンプレートを作成します。

profile.blade.php

@extends('user.layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-heading">Profile</div>
                <div class="panel-body">
                    <form class="form-horizontal" role="form" method="POST" action="{{ url('/user/profile') }}">
                        {!! csrf_field() !!}

                        <div class="form-group{{ $errors->has('name') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">名前</label>

                            <div class="col-md-6">
                                <input type="text" class="form-control" name="name" value="{{ old('name', $user->name) }}">

                                @if ($errors->has('name'))
                                    <span class="help-block">
                                        <strong>{{ $errors->first('name') }}</strong>
                                    </span>
                                @endif
                            </div>
                        </div>

                        <div class="form-group{{ $errors->has('email') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">Eメール</label>

                            <div class="col-md-6">
                                <input type="email" class="form-control" name="email" value="{{ old('email', $user->email) }}">

                                @if ($errors->has('email'))
                                    <span class="help-block">
                                        <strong>{{ $errors->first('email') }}</strong>
                                    </span>
                                @endif
                            </div>
                        </div>

                        <div class="form-group">
                            <div class="col-md-6 col-md-offset-4">
                                <button type="submit" class="btn btn-primary">
                                    保存
                                </button>
                            </div>
                        </div>
                    </form>
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

ここ、old()のLaravelの関数が使用されていますが、すでに存在する値を編集するので、デフォルトとしてDBからの値が入っていることに注意してください。

 <input type="text" class="form-control" name="name" value="{{ old('name', $user->name) }}">

コントローラでは、validationエラーが発生して、現在の画面に戻る必要があります。そのときは、withInput()がセッションに入力の値を保存して、back()で現在の画面にリダイレクトします。リダイレクト後には、old()は、デフォルトでなくセッションに保存された入力された値を表示します。

最後に、routes.phpを以下のように編集します。

routes.php

Route::group(['prefix' => 'user', 'middleware' => 'web'], function () {
...
    Route::get('profile', 'User\UserController@getProfile');
    Route::post('profile', 'User\UserController@postProfile');
});

以下のように、認証のミドルウェアをコントローラから移してもOKです。

routes.php

Route::group(['prefix' => 'user', 'middleware' => 'web'], function () {
...
   Route::group(['middleware' => 'auth:user' ], function () {
        Route::get('home', 'User\HomeController@index');
        Route::get('profile', 'User\UserController@getProfile');
        Route::post('profile', 'User\UserController@postProfile');
    });
});

重複回避－入力バリデーションで回避

Tue, 08 Sep 2015 09:41:02 +0900

GmailのEメールアドレス、Facebookのログイン、銀行の口座番号、などなど・・世の中どこに行っても必要なIDの情報。この情報に重複があったら困りますね。

このIDとなる情報を登録するプロセス、まずは入力バリデーション、次にDBでレコード作成時の重複DBエラーを利用しての２ステップで重複を回避します。

今回は、入力バリデーションを使って：

public function postSignup(Request $request)
{
  $rules = [
    'email'      => 'required|email|unique:member,email',
    'password'   => 'required|min:6|max:20|confirmed',
    'first_name' => 'required',
    'last_name'  => 'required'
  ];

  $messages = [
    'email.unique' => &quot;Eメールアドレスはすでに使用されています&quot;
  ];

  $this->validate($request, $rules, $messages);

  $member = Member::create($request->all());
}

重複をチェックしてくれるのは、unique:member,emailのルールです。「DBテーブル member の email には同じ情報があってはいけません」というルールです。

すでにDBに存在するEメールを入力したなら、DBに値を保存せずに、入力画面へ戻りエラー「Eメールアドレスはすでに使用されています」を表示してくれます。

それを行ってくれるのが次の1行：

$this->validate($request, $rules, $messages);

しかし、シンプルすぎて逆にわかりにくいかもしれません。そう思うなら、ララベルバージョン４のように、以下とも書くことできます。

$validator = Validator::make($request->all(), $rules, $messages)

if ($validator->fails())
{
  return back()->withErrors($validator)->$withInput();
}

さて、重複回避は、このチェックだけで十分でしょうか？

次回は、DBレベルでの重複回避の紹介をします。

バリデーション on ララジャパン

【Under the hood】エラーバッグの構造

$errorsの構造

$errors->first(...)の処理を追う

名前付きエラーバッグの場合

まとめ

名前付きエラーバッグによるエラー管理

煩雑になってしまう例

名前付きエラーバッグとは？

エラーバッグに名前をつける

名前付きエラーバッグからエラーを参照する

他の項目に依存する項目のバリデーション

入力例

exclude_if

nullable

匿名関数

チェックボックスの入力値 - mergeIfMissing()

配列値の入力のためのFormRequest（２）エラーを見やすく

複数行・複数項目の入力フォーム

エラーの出力を見やすくする

最後に

配列値の入力のためのFormRequest

配列値の入力フォーム

入力値の加工

「どちらかに入力してください」のバリデーション

入力フォームで@error

@if vs @error

配列の入力があるフォームで@error

FormRequestで入力値を補正（２）

FormRequestでルールを共有

ルールを共有する必要性

ルールの共有の仕方

FormRequestで入力値を補正

FormRequestを使う

FormRequestを使わないコントローラ

FormRequestを使用したら

編集のブレード

値がないときにバリデーションを実行するには

バリデーションルール、bail

コントローラー中でのルールの共有（3) データをDBに保存

コントローラー中でのルールの共有（２）sometimes

コントローラー中でのルールの共有

欲しいもの

１．コントローラー内でルールを指定したい

２．コントローラーのメソッド内でルールを指定したくない

解決方法 その１

欲しかった解決方法

カスタムルールオブジェクト

Laravel 5.6で追加されたバリデーション

バリデーションの実例：条件付きの必須

バリデーションの実例：更新

バリデーションの実例：項目の存在、項目の値の存在

バリデーションのあれこれ

リクエストのvalidate()メソッド

コントローラのValidatesRequestsトレイトのvalidate()メソッド

Validatorクラス

validator()ヘルパー

バリデーションの実例：DBの情報を引数とする条件

バリデーションの実例：他の項目の値を引数とする条件

バリデーションの実例：定数値を引数とする条件

バリデーションの実例：日付

バリデーションの実例：特殊データタイプ

バリデーションの実例：基本データタイプ

バリデーションの実例

実例の使い方

phpunitのデータプロバイダー

バリデーションの実例の連載開始

バリデーション (9) 配列のDistinctと暗黙の拡張

配列のDistinctバリデーション

空の入力に対するdistinct？

暗黙の拡張 implicitRules

バリデーション (8) 配列をバリデーションする

laravel 4 や 5.1 以前での配列バリデーション

バリデーション (7) エラーメッセージのリプレーサー

等号を含む日付の最大最小

メッセージへの引数の展開

カスタムプレースホルダー

バリデーション (6) 他の属性の値を参照

getValue()

min と max の拡張

解決方法　その１