私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】Laravel【フレームワーク】 Part.6
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
前へ
>>250
多分日本語で書いてあっても読まないだろうな
多分日本語で書いてあっても読まないだろうな
だってAllowed memory size of 2097152 bytes exhaustedとか出るけど増やしても増やしても解決しないんだぜ
読んで対応したぐらいで解決してりゃ誰も苦労しないよ
読んで対応したぐらいで解決してりゃ誰も苦労しないよ
>>244
githubにアップされてるLaravelベストプラクティスを読めば良いぞ。
githubにアップされてるLaravelベストプラクティスを読めば良いぞ。
うちの場合はServer error: `GEThttp://cabinet.laravel.com/latest.zip` resulted in a `522 Origin Connection Time-out` response:
だったけど、ぐぐって出た対策じゃ解決しなかった。タイムアウトとか言われてもどうしたらいいんだよ。
だったけど、ぐぐって出た対策じゃ解決しなかった。タイムアウトとか言われてもどうしたらいいんだよ。
お前らのためにベストプラクティス貼ってやるよ
http://github.com/alexeymezenin/laravel-best-practices/blob/master/japanese.md
http://github.com/alexeymezenin/laravel-best-practices/blob/master/japanese.md
>>258
前もそれ書いてたよね。Laravelエアプかよ。
前もそれ書いてたよね。Laravelエアプかよ。
>>260
そりゃそうよ。まぁtailwindCSS使った方が楽なことが多いから。アホみたいにCSS設計とか命名規約とかに無駄な時間使うことも無くなるし。
そりゃそうよ。まぁtailwindCSS使った方が楽なことが多いから。アホみたいにCSS設計とか命名規約とかに無駄な時間使うことも無くなるし。
前に書いてたから何なんだ？
エアプって何？
言いたいことがあるなら普通に言えよ
エアプって何？
言いたいことがあるなら普通に言えよ
>>262
Laravelのフォームリクエストは、外部からの入力を検証するための機構だからモデルでやれって主張はアホすぎるってこと。MVCでは、入力値の検査はコントローラーの責務。
RailsとかがModelで検査してるのは、MVCよりActiveRecordのルールを優先した結果に過ぎない。
そもそも画面やAPIからの入力とバッチの入力のバリデーション仕様が同じになるケースなんてまず無いと思うんだけど？
誰にも相手にされなかった主張を、また繰り返すのはやめたほうが良いぞ。
Laravelのフォームリクエストは、外部からの入力を検証するための機構だからモデルでやれって主張はアホすぎるってこと。MVCでは、入力値の検査はコントローラーの責務。
RailsとかがModelで検査してるのは、MVCよりActiveRecordのルールを優先した結果に過ぎない。
そもそも画面やAPIからの入力とバッチの入力のバリデーション仕様が同じになるケースなんてまず無いと思うんだけど？
誰にも相手にされなかった主張を、また繰り返すのはやめたほうが良いぞ。
Cakeだとバリデーションはモデルに書いてたけど、Laravelではダメなん？
>そもそも画面やAPIからの入力とバッチの入力のバリデーション仕様が同じになるケースなんてまず無いと思うんだけど？
え、そんなことはなくない？
1つのテーブルにデータを追加するシンプルな要件だと、WebからフォームをPOSTしてもバッチで追加してもルールは一緒になるだろう
エラーメッセージの出し方とかは異なると思うけども、バリデーターをそれぞれ別に書いたりはしないと思う
え、そんなことはなくない？
1つのテーブルにデータを追加するシンプルな要件だと、WebからフォームをPOSTしてもバッチで追加してもルールは一緒になるだろう
エラーメッセージの出し方とかは異なると思うけども、バリデーターをそれぞれ別に書いたりはしないと思う
>>260
どのフレームワークを使うか選択できなかったっけ？
どのフレームワークを使うか選択できなかったっけ？
議論する際「どこでやるか」と「どこに書くか」を混同しないようにしないといかんな。
モデルに書いてもリクエストに書いても、流れ上は「コントローラーでやる」と言っても間違いではない。
モデルに書いてもリクエストに書いても、流れ上は「コントローラーでやる」と言っても間違いではない。
議論するなら、「俺はAに書いてる。なぜなら○○だからだ。Bに書くと○○で駄目だ」
って理由まで答えないと成立しないけどな
って理由まで答えないと成立しないけどな
>>269
268です。ありがとうございます。
ちなみにそれだと、
Aというルートではコントローラーにバリデーションを書き、
Bというルートではモデルにバリデーション書く、
というようにバラバラになってしまうんですが、気にしないほうが良いのでしょうか？
それとも一律コントローラーに書くほうが良いのでしょうか？
268です。ありがとうございます。
ちなみにそれだと、
Aというルートではコントローラーにバリデーションを書き、
Bというルートではモデルにバリデーション書く、
というようにバラバラになってしまうんですが、気にしないほうが良いのでしょうか？
それとも一律コントローラーに書くほうが良いのでしょうか？
>>270
それが許されるなら何でもありですがな
それが許されるなら何でもありですがな
バリデーションのルールをコントローラーに直書きするのがよくないと思う
使い回したりメンテしやすいよう別の場所に出して、コントローラーはそれを呼び出すだけにしたい
じゃあどこに書くか？となると多分モデルなんだが、LaravelのRequestに書く仕様はちょっとビックリした
一見理に適っていて便利でもあるけど、既出の通りコマンドから同じバリデーションを実行する場合は一工夫必要になる
使い回したりメンテしやすいよう別の場所に出して、コントローラーはそれを呼び出すだけにしたい
じゃあどこに書くか？となると多分モデルなんだが、LaravelのRequestに書く仕様はちょっとビックリした
一見理に適っていて便利でもあるけど、既出の通りコマンドから同じバリデーションを実行する場合は一工夫必要になる
>>275
コントローラーのメソッドから呼び出すのは良くて、コマンドのメソッドから呼び出すのが良くない理由もお願いします。
コントローラーのメソッドから呼び出すのは良くて、コマンドのメソッドから呼び出すのが良くない理由もお願いします。
リクエストのrules()メソッドにルールがまとまって、コントローラーとかにルールが散らばらなくてメンテしやすいと思うけどなあ
お前ら細けえな
好きなように書けよ
どうせ誰もメンテしなくなるんだし
バリデーションなんて動けばいい
好きなように書けよ
どうせ誰もメンテしなくなるんだし
バリデーションなんて動けばいい
>>276
コマンドからはFormRequestなんて使わないから
呼び出したくても呼び出せないぞ
とは言え、rulesはpublicだしどうしようもないわけではない
うまくやれば共通化もできるかもしれない
コマンドからはFormRequestなんて使わないから
呼び出したくても呼び出せないぞ
とは言え、rulesはpublicだしどうしようもないわけではない
うまくやれば共通化もできるかもしれない
>>272
そうだねそうなるよ
そうだねそうなるよ
コントローラにバリデーションルールダラダラ書いたコード納品されたら俺だったらキレるわ
メンテしない案件でも納品直前に「やっぱりパスワードの文字数○○文字以上に変えてくれ」なんて依頼よくあるからなあ
「空の時に表示が崩れる」という理由で本来必須じゃなかった項目をrequiredに変えたり
クライアントは馬鹿だから色々予期せぬ事が起こる
「空の時に表示が崩れる」という理由で本来必須じゃなかった項目をrequiredに変えたり
クライアントは馬鹿だから色々予期せぬ事が起こる
>>282
じゃあ今度からはモデルにルール書くね
じゃあ今度からはモデルにルール書くね
メンテ＝他人に見せることばかり考えてるやついるな
メンテは自分が見てわかりやすくするためのものでもあるだろ
好きなように書いてて、半年後に見ても思い出せるのかよ
メンテは自分が見てわかりやすくするためのものでもあるだろ
好きなように書いてて、半年後に見ても思い出せるのかよ
Laravelってバリデーションどこに書くかでも大論争になるんですね
Symfony選んどいてよかった
Symfony選んどいてよかった
Requestでバリデーションする方が分離されるから個人的には好きだけどね
モデルでやるとかは無いわｗ
モデルでやるとかは無いわｗ
間違ってたら考えを改めたいから言って欲しいんだけど
何でFormRequestがやってるバリデーションって入力された値が想定してる値かってバリデーションなので
その先にあるであろうテーブルとかを考慮しちゃいけないものだと思ってる
例えば同じテーブルに入力されるデータでも管理者権限と一般ユーザー権限でバリデーションルール変えたいってケースなんてザラだし
モデルに入力される値のバリデーションは持てるの担当範囲外でその担当は
おそらくバックエンドにあるデータベースが受け持ってて入力値が正しくない場合
Exceptionって形で戻してるって解釈してる
違うかな
何でFormRequestがやってるバリデーションって入力された値が想定してる値かってバリデーションなので
その先にあるであろうテーブルとかを考慮しちゃいけないものだと思ってる
例えば同じテーブルに入力されるデータでも管理者権限と一般ユーザー権限でバリデーションルール変えたいってケースなんてザラだし
モデルに入力される値のバリデーションは持てるの担当範囲外でその担当は
おそらくバックエンドにあるデータベースが受け持ってて入力値が正しくない場合
Exceptionって形で戻してるって解釈してる
違うかな
バッチ処理のことを考慮したらFormRequestクラス使うのはありえないんだけどね
ここはレベルが低いからそこまで理解できないらしい
ここはレベルが低いからそこまで理解できないらしい
今日もクソ暑い 毎年思うんだけどなんか１年のうちで暑くなる時期あるよな
バッチ処理なんてそもそも間違った入力を渡す事なんか無いやろｗ
頭悪すぎｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
頭悪すぎｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
>>297
こういうやつの為に、バッチにもバリデーションが必要なんだよな。
こういうやつの為に、バッチにもバリデーションが必要なんだよな。
>> 297
バッチ処理で間違った入力がされない保証が100%じゃない限り、本来ならバリデーションするべきとは思うけど面倒だからやらないで運用でカバーしてもらう事が多いのも事実
バッチ処理がBatchableジョブの事を言ってるのかartisanコマンドで任意に叩いた処理の事言ってるのかどちらを指してるかわからんけど
どっちにしろ動かす状況やら権限でバリデーションルールが変化するわけだから
機能(バッチ処理)ごとにそれぞれルールは必要じゃないの？
Batchableジョブでミドルウェアが使える様になってるのってリクエストの時と同じように
そこでバリデーションかけたり前処理できる様にしてあるって思ってたけど
バッチ処理で間違った入力がされない保証が100%じゃない限り、本来ならバリデーションするべきとは思うけど面倒だからやらないで運用でカバーしてもらう事が多いのも事実
バッチ処理がBatchableジョブの事を言ってるのかartisanコマンドで任意に叩いた処理の事言ってるのかどちらを指してるかわからんけど
どっちにしろ動かす状況やら権限でバリデーションルールが変化するわけだから
機能(バッチ処理)ごとにそれぞれルールは必要じゃないの？
Batchableジョブでミドルウェアが使える様になってるのってリクエストの時と同じように
そこでバリデーションかけたり前処理できる様にしてあるって思ってたけど
もうCloseされちゃったけど最近のissuesでもFormRequestsはバッチ処理に向いてないから廃止しようって話あったよね
やっぱりコミュニティでもモデルにルール書く人が大半らしい
やっぱりコミュニティでもモデルにルール書く人が大半らしい
php スレッド一覧へ類似してるかもしれないスレッド
- 【PHP】Laravel【フレームワーク】 Part.9 (884) - [98%] - 2022/3/13 12:00
- 【PHP】Laravel【フレームワーク】 Part.8 (148) - [98%] - 2021/8/8 21:30
- 【PHP】Laravel【フレームワーク】 Part.7 (779) - [98%] - 2021/7/9 16:18
- 【PHP】Laravel【フレームワーク】 Part.5 (568) - [98%] - 2021/5/1 22:00
- 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
- 【PHP】Laravel【フレームワーク】 Part.3 (983) - [96%] - 2021/2/12 4:00
- 【PHP】Laravel【フレームワーク】 Part.10 (446) - [96%] - 2022/6/6 19:30
- 【PHP】Laravel【フレームワーク】 Part.11 (870) - [96%] - 2022/8/28 15:45
- 【PHP】Laravel【フレームワーク】 Part.4 (460) - [96%] - 2021/4/4 4:00
- 【PHP】Laravel【フレームワーク】 Part.2 (917) - [96%] - 2019/9/10 9:15
- 【PHP】Laravel【フレームワーク】 (887) - [84%] - 2019/4/23 21:00
- 【PHP】フレームワーク Akelos (129) - [56%] - 2019/5/9 7:46
トップメニューへ / →のくす牧場書庫について