どきゅん道の歩み方とlaravelと

どきゅん道を究めましょう。

laravel 青本のバリデーションとバリデーターのまとめ。実は4パターンが書かれていました

laravel の教科書と言ったら青本でしょう。

 


PHPフレームワーク Laravel入門 第2版

これなしではlaravelを使えない!!というほど重要なものなのだ。

 

しかしながら、実際この本は難易度は決して低くはない。

高い方だとは思う。いや、高いか?

 

今回は青本のバリデーション、バリデーターのことをもっと単純に書きたいと思う。

 

 

 

青本はバリデーター(バリデーション)が4つの方法で書かれている

1⃣バリデーションP120

命令文は validate

コントローラー内に書きこむ。全自動で入力エラーをチェックしてくれるが、自動すぎてエラー表示が煩雑すぎる。自分は使わない。

this -> validate

という引き出し方も初心者に優しくない。

 

2⃣バリデータ―P144(バリデーターを作成する)

命令文は validator

結局これでOK!上のバリデーションはいらないと思う。エラーも簡単に日本語にできる。コントローラーに記入する点はバリデーションと同じ。

ただ、青本の追記

use validator ;

は、laravel8 の場合、 

use Illuminate\support\Facades\varidator;

になるので注意。

 

3⃣バリデーションをリクエストから直でチェックする

p138(バリデーションをカスタマイズする、フォームリクエストについて)

命令文は  php artisan make:request リクエスト名

これはコントローラーを使わずに、フォームリクエストという仕組みを使ってバリデーションする方法。

リクエストを直接チェックした方がよくね?という目的で作られているけど、artisanで手数はかかるし、結局コントローラーにエラーメッセージを書くことになるし、結局2⃣のバリデーターでよい。

 

4⃣データーベース(モデル)でバリデーションをする

データーベースに行く前にバリデーションする形。

これが一番いいらしいけど、青本ではこれがあまり詳しく書かれていない!。実践の方でちょっと触れるだけなのでやり方がよくわからん。

 

 

この4つが青本のバリデーションの内容なのである。これが演繹的に書かれていて初見だと本当に意味が解らなかった。

しかしノートにまとめていく段階で「4つの方法がかかれているわけか」

と気づくことができる。

 

 

結論

青本の内容はまとまりがないところがあり、難解なところがあるのは否めない。

バリデーションの部分は4つの方法が書かれているということ、

そして使うのは2⃣のバリデーター(p144)だけでいいということ。

 

ということが解ってくる。

 

あと、P147のクエリー文字は全く使う意味が解らないので初心者は飛ばしていいと思う。

よって、青本で使えるバリデーターの話は

P144,P145、P146、

P148、P149、

だけでOKと言い切っていい!。

 

あとは無駄!飛ばしてOK!!!!

 

 

 

 

 

 

laravel 未定義の配列キー undefined array key って何?

んまー、このエラーはよーく出てくる。しかも調べてもあまりピンとくる解決法がない…

 

 このエラーは結局配列の中身が入ってないっていうことである。例えば

 

$配列    =   [ 'a', 'null ' , 'c',]

添え字キー       0     1       2

 

このような配列があるとする。

で、二番目(添え字キーでいうと1番目)を取ろうとすると

「そのキーでは中身ないですよ、設定されてないですよ、キー1=NULLですよ」

といってエラーになるわけである。

 

NULLならNULLで出せばいいじゃない、と思うが、駄目なのである。

 

自分もこのエラーには大概悩まされた。だってエラーの内容が表示されないんだもの。

ファサードだか何だかよくわからない部分しか表示しないから一体何のエラーだかわかりずらい事この上ない!!!。

 

 

しかし、この「未定義の配列キー」エラーは、ただの配列NULLエラーなのだ。

配列にしっかり値を入れようよっっっていうコンピューターのただただ優しい指摘なのである。

 

 

解決方法。ありますよ。自分がいくつか成功している解決方法をここに書こうと思う。

① @if分でNULLをはじくとエラーにならない。

② @foreach で as を完全無視。 $loop で繰り返してエラーを回避しやすくする。

③ 配列をしっかり入れるように見直しする

④ pluckをつかってレコードとキーを作り、キーから引き出す。

 

こんなところでしょうかね。簡単に説明しましょう

 

 

1⃣ @if分でNULLをはじくとエラーにならない

これは結構強力。

 

@if  (empty($配列[キー]))

値はありません

@else

値はあります

@endif

 

のように@ifでNULLをはじくとエラーは回避できる。しかしこれでもキー自体がなかったりするとエラーになることもある。

 

$配列 = [ a , b , c ,]

添え字     0   1   2

 

という配列なのに、キー3で値を取ろうとすることはできないので注意。

そんなキーはありませんよっていうエラーになる。

 

 

 

2⃣ @foreach で as を完全無視。 $loop で繰り返してエラーを回避しやすくする。

 

これはちょっと恥ずかしい方法なのですが、

@foreach  ($配列 as  name)

で、name を使いつつ他の配列を同時にループさせるときに、ループ数が合わなかったりすることがあるので、自分はas nameは使わないようにしてます。

 

まあ単なる素人発言です。しかし、このエラーがまあよく起こる。

 

@foreach  ($配列 as  name)

{{$配列[$loop -> index]}}

{{$配列2[$loop -> index]}}

{{$配列3[$loop -> index]}}

@endforeach

 

のように、自分は$loopを使ってループさせています。これだと配列のループ数が合わないことがない利点があります。エラーを減らす方法になるかと。

 

 

3⃣ 配列をしっかり入れるように見直しする

当たり前です。これが一番の解決策です。

未定義キーのエラーはただの配列ミスなので、しっかりデーターベースを調べて、NULL値とキーを把握しましょう。

 

とはいえこれがホントによく起こる。

例えばデーターベースのレコードを->deleteする命令をしたりすると、それに関連してた所が次の日にエラーになっていたりするのだ。

「昨日までは従順だったのに!!さてはコンピューターの反乱がついに起きたか!!」

ということはよーくあるのでDBの見直しをしよう。

 

 

 

4⃣ pluckをつかってレコードとキーを作り、キーから引き出す

 

これは1⃣のもう一つの解決法で、最初っからNULLを配列に入れないようにする方法である。

pluckで最初っから全てデーターベースの値をキー設定していまえばいいということになる。

 

->pluck('値’,'id')

という風にして、最初っから全データーベースの値とキーを作っておくのです。

すると、

$配列 = [ id1=>値1 ,  id2=> 値2  , id3=> 値3 ………]

このように、全値と全キーが出来上がります。

この方法ならNULLになる心配がない。

 

そしてidキーを使って@foreachすればいいだけなのであります。

 

@foreach ($配列 as name)

$配列[$idの配列[$loop->index]]

@endforeach

 

こんな感じ?

NULLの入った配列を最初っから作らない。pluckでデーターベース全部を配列にしてしまって、必要な値をキーで取り出す、という方法になる。

 

 

 

 

 

結論

未定義の配列エラーは最初はほんと意味が解りませんでした。だってエラー内容が全く表示されないのですから。

 

しかし、これは単なる配列NULLエラーだと気が付くと、結構解決はできる。

しかもemputyとpluckでほぼ解決できる。

 

後はタイプエラーだからしっかりミスを調べること!!!以上

 

 

laravel find と where と カラム と pluck が使えたり使えなかったりする理由

laravelを使っていて、

クエリビルダ―よりエロクアントが使いやすい

という記事を読み、自分もどうにか使い込んでいる。

 

しかし、思ったようにいかないことが多々ある、というか多すぎる!!

 

これはエロクアントのインスタンスが、

 

①モデルインスタンスなのか、

②コレクションなのか、

 

この違いによってメソッドまでも違う働きをしてしまうようなのだ。

今のところ、自分が試した結果、findとwhereでの違いを以下のように確認した。

 

 

1⃣findの場合

 

$モデルインスタンス = モデル::find(id);

 

findでID絞り込み検索した場合はモデルインスタンスとなって一塊のイメージでインスタンスする。

モデルを使ってカラムを引き出す場合、直接

$モデルインスタンス -> カラム;

で取り出せる。しかしモデルインスタンスをpluckした場合、こうはいかない。

$モデルインスタンス ->pluck('カラム’);

では指定したid以外の全てのカラムまで取ってしまうのだ。

 

結局IDで絞り込んだ意味がない!!。

 

 

 

2⃣whereの場合

 

$コレクション = モデル::where('カラム’、’検索文字’);

 

whereで絞り込み検索した場合はコレクションとなり、バラバラのイメージでインスタンスする。

そしてコレクションは直接カラムでは取り出せない。(と思う、違ったらごめん)

$コレクション -> カラム;  

駄目!この場合は何故かエラーになる(と思う、違ったらごめん)。

ずっと何でなん?取り出せるときと取り出せない時があるんだよと不思議に思っていた。コレクションでは直でカラムは取れないっぽいのだ

これはおそらくwhereは

「複数のレコードをとる」

という前提があるからなんだと思う。複数のレコードの中のどのカラム?という混乱がパソコンの中に渦巻くのであろう。

 

というわけで、where検索した場合は

「pluck」

でカラムを取り出さないといけないのだ。

$コレクション -> pluck('カラム’);

これだとwhereで選択したレコードの全カラムがコレクション配列として取り出せる。

 

(注)ただ、コレクション配列に大注意がある!!!

コレクション配列は、ほぼ配列のように扱えるが、

empty とか inArray

にかけようとするとエラーになったりする!!!!!。

この場合はちゃんと 

->all()  とか

->first() 

->get()

で「コレクション解除」しないといけない。このあたりもエロクアントの使いずらいところだ。

 

 

結論

 

find    直カラム〇  pluck△(全取り)

where  直カラム×   pluck〇

 

「ID検索はfindだ!」と決めつけてpluckでカラムを絞り込もうとすると、前途のように全カラムを取り出して結局IDで絞り込みした意味がなくなる。

というかIDはプライマリーキーだから一個しか検索しないので直接カラムで取ればいいってことなんだろうな。

 

しかし、pluckにはキーをつけることもできて便利。

どうしてもpluckを使いたいときはwhereでもID検索ができるのでそうしよう。

 

 

(余談)

しかし、データーベースの更新SAVEをするときはWHEREのID検索では出来なくて、ちゃんとFINDでID検索しないとSAVEできなかったりするのでほんとややこしい!!。

 

モデルインスタンスとコレクションの違いでできたりできなかったりすることがほんとに多々ありすぎるのだ!!。