laravelは自由度の高いフレームワークなので、構造上は基本的にどこでバリデーションを行ってもよいとのことです。
WebやQiita上では、ControllerやカスタムRequestでバリデーションを行なっているのを多くみかけるのですが、今回カスタムrequestクラスで行ったところコントローラーが呼べなくなってしまったのでまとめます。
よくよく考えたら仕様をよくわかってなかっただけなのですが‥
起こったこと
前の記事にあるような
①bladeファイルへテキスト入力するタイプの検索フォームを作成
②form actionでフォームに入力した内容をコントローラーへ送信する
③フォームに入力した内容をコントローラーで受け取り、検索ロジック（モデル）へ渡す
ような機能を作成した際に、コントローラーが走らず検索フォームがまた表示されてしまう
そもそもRequestとは
特徴
・バリデーション専用のファイルを作り処理をさせます。
・Validatorを用意しなくて良いので各処理をシンプルに記述することが可能
・HTTPメソッド（GET、POST）を区別せずリクエストデータを操作可能
・バリデーションが通った時だけコントローラー内の処理が走る
使用方法
・requestクラスをコントローラーメソッドにDIする
→ DIとは...（Dependency Injection）
ゆるく簡単にまとめるとクラスの内部でnewするのではなく、外部で用意し使用することができるようにする。
下記のようにコントローラーの引数に入れることで、オブジェクトとして使用できるようになる
public function search(SearchRequest $request, NameGetInterface $interactor)
{
$name = $request->query('name');
if (!empty($name))
{
$result = $interactor->searchName($name);
return view('/search_result', compact('result'));
}
}
詳しくは下記記事がわかりやすいかと
やはりあなた方のDependency Injectionはまちがっている。
DI・DIコンテナ、ちゃんと理解出来てる・・？
なぜコントローラーが呼べなくなったのか
今回は上記コードのように、requestクラスでバリデーションを実装していたのですが
バリデーションチェックの結果、ルール違反があった場合は自動的に以前のページヘリダイレクトするLaravelの機能によりコントローラーが呼ばれず、検索フォームをループしているようでした。公式に書いてあった
今回はbladeファイルに $errorsでエラーを表示する仕様にしていなかったことも検索フォームをループしているようにみえた要因でした。
学んだこと
①Laravelの仕様でルール違反があった場合は自動的に以前のページヘリダイレクトする
- ひとつひとつのページごとにエラーがないか確認する
- 真っ白なページが表示されているときはbladeファイルのrouteがあっているか確認する、エラーの番号も確認する
- bladeファイルからcontrollerをよびだせている場合、dd();のデバッグコマンドでどこのメソッドまで動いているのかを確認する
- bladeファイルからcontroller、controllerからbladeファイルをやりとりする際はbladeファイルで使う変数をcompact関数でcontrollerから送っているか確認する
②ここはあっているという概念をすてる
まとめ
冷静に考えたらこういうミスする人いなさそうだけど、バリデーションについて前よりちょっぴり詳しくなったような気がするからよいと思うことにしました