回答編集履歴
4
修正
answer
CHANGED
|
@@ -17,6 +17,6 @@
|
|
|
17
17
|
※ここはフレームワーク云々より発想の問題
|
|
18
18
|
|
|
19
19
|
もちろん「同じ処理を流す」からって同じ処理を別の場所に書くのは無駄。
|
|
20
|
-
「同じビューでエラーだけ追加」
|
|
20
|
+
「同じビューでエラーだけ追加」ということで処理を共通化させて内部で分岐したほうがいいですね。
|
|
21
21
|
|
|
22
22
|
ますます[前の質問](https://teratail.com/questions/199090)とわける必要がなくなってきているように思います。
|
3
修正
answer
CHANGED
|
@@ -14,4 +14,9 @@
|
|
|
14
14
|
画面表示ができているのならreserve_info自体にデータ取得のためのキーは揃えられるはずですし、
|
|
15
15
|
reserve_infoを表示するときと同じデータ取得処理を流せるはずです。
|
|
16
16
|
|
|
17
|
-
※ここはフレームワーク云々より発想の問題
|
|
17
|
+
※ここはフレームワーク云々より発想の問題
|
|
18
|
+
|
|
19
|
+
もちろん「同じ処理を流す」からって同じ処理を別の場所に書くのは無駄。
|
|
20
|
+
「同じビューでエラーだけ追加」なら分岐させて処理を共通化させたほうがいいですね。
|
|
21
|
+
|
|
22
|
+
ますます[前の質問](https://teratail.com/questions/199090)とわける必要がなくなってきているように思います。
|
2
修正
answer
CHANGED
|
@@ -6,4 +6,12 @@
|
|
|
6
6
|
|
|
7
7
|
もし「getもpostも発生しうる」仕様なのでしたらルーティングにpostしかないのがおかしいということになります。
|
|
8
8
|
そこは画面遷移の体系図をきちんと作って整理したほうが良いでしょうね。
|
|
9
|
-
特にフレームワーク利用の場合は、きちんと設計してから作っていかないと今みたいにぐちゃぐちゃなコードのまま問題切り分けがどんどん困難な状態になっていきます。
|
|
9
|
+
特にフレームワーク利用の場合は、きちんと設計してから作っていかないと今みたいにぐちゃぐちゃなコードのまま問題切り分けがどんどん困難な状態になっていきます。
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
> confirm_form_dataアクション内にて、以下のように、reserve_info.blade.phpにreturnした場合、html部分の<tr><th>希望日時</th><td>{{$reserved_date}}({{$reserved_dayOfWeek}}){{$reserved_time}}～</td></tr> こちらの$reserved_dateなどの変数の表示はどうすれば良いのかといった部分でつまずいてしまいました。
|
|
13
|
+
|
|
14
|
+
画面表示ができているのならreserve_info自体にデータ取得のためのキーは揃えられるはずですし、
|
|
15
|
+
reserve_infoを表示するときと同じデータ取得処理を流せるはずです。
|
|
16
|
+
|
|
17
|
+
※ここはフレームワーク云々より発想の問題
|
1
修正
answer
CHANGED
|
@@ -2,4 +2,8 @@
|
|
|
2
2
|
|
|
3
3
|
というか`$validator->fails()`の時点でwithErrors伴ってconfirmではなくreservation_infoにreturnすれば良いのでは？
|
|
4
4
|
|
|
5
|
-
[日本語訳マニュアルバリデーションの#バリデータの生成](https://readouble.com/laravel/5.8/ja/validation.html#manually-creating-validators)でもpost/createに戻しているので同じことかと思いますが。
|
|
5
|
+
[日本語訳マニュアルバリデーションの#バリデータの生成](https://readouble.com/laravel/5.8/ja/validation.html#manually-creating-validators)でもpost/createに戻しているので同じことかと思いますが。
|
|
6
|
+
|
|
7
|
+
もし「getもpostも発生しうる」仕様なのでしたらルーティングにpostしかないのがおかしいということになります。
|
|
8
|
+
そこは画面遷移の体系図をきちんと作って整理したほうが良いでしょうね。
|
|
9
|
+
特にフレームワーク利用の場合は、きちんと設計してから作っていかないと今みたいにぐちゃぐちゃなコードのまま問題切り分けがどんどん困難な状態になっていきます。
|