【PHP】Laravel【フレームワーク】 Part.3

**nobodyさん** · 2019/11/20(水) 11:15:48.17

テンプレ追加修正お願いします

Laravel
ウェブ職人のためのPHPフレームワーク

本家
https://laravel.com/

git
https://github.com/laravel

動画チュートリアル(英語)
https://laracasts.com/

日本語
http://laravel.jp/

書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク

Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)

※前スレ
【PHP】Laravel【フレームワーク】
https://medaka.5ch.net/test/read.cgi/php/1503683914/
【PHP】Laravel【フレームワーク】 Part.2
https://medaka.5ch.net/test/read.cgi/php/1556417229/

amazonへのリンクが邪魔をしてスレッドを建てられなかったので外しました。

**nobodyさん** · 2020/05/01(金) 17:33:54.49

一番はモバイル対応だろ。
モバイルでもブラウザで済ませる方針なら従来型でもいいが。

**nobodyさん** · 2020/05/01(金) 17:42:24.28

Laravelはそもそも根っこの設計部分でフレームワークとして致命的におかしい
初心者が設計したと思われても仕方ない　最低だ
Laravelは根っこから設計に問題があるしおまけにFacadeに頼る逃げ癖もついている、Laravelの初期バーションがリリースされた頃から何も変わっていない
フレームワークのコンプレックスからかLaravelは他のフレームワークを敵と見てる
悪意があるわけでなくもう何も考えないで設計されているしその上他フレームワークでやっているような
当たり前の機能の実装を避けてきた、根本的にフレームワークとして致命的
Laravelは自分の価値観が絶対だと信じこんで一般的なフレームワークの基本設計からズレていることに気づけなかった

**nobodyさん** · 2020/05/01(金) 17:48:20.39

Laravelアンチ降臨

**nobodyさん** · 2020/05/01(金) 18:12:03.76

>>202
もっと具体的に
根っこの部分とは？

**nobodyさん** · 2020/05/01(金) 18:24:45.23

根っこも何も動作が重いに尽きる。

**nobodyさん** · 2020/05/01(金) 18:25:27.20

>>200
端的に言うと、MVCのVがすっきり分けられるってとこかな。

・htmlにphpを混ぜ込まなくて済む。（可読性、IDEの補完精度）
・htmlとphpのネストを別々にするというキモいことをしなくて済む。
・ビジネスロジックはAPIで、表示上のデータの整形は画面で、と分担がより明確化する。
・非同期処理でデータとってきた時の画面の更新はフロントフレームに任せるから楽。

>>201が言うようにネイティブアプリが必要になったときもそうしとけば楽だしな。

**nobodyさん** · 2020/05/01(金) 20:54:03.38

お前らってlaravel-mix使ってる？
それともvue createとかで別プロジェクト作成してる？

**nobodyさん** · 2020/05/01(金) 20:55:28.64

vue create使ってます

**nobodyさん** · 2020/05/01(金) 21:46:49.76

>>202
laravel云々を論じる以前に、伝達と表現技術を欠いて残念です。繰り返しが多い。抽象的かつ厳密さが無い。故に感覚的表現。ついでに根っこと言ったり、根本と言ったり概ね幼稚な表現。本当のところ理解出来てないんじゃないの？と想起させる。

私の主観はあなたの文章を以上のように感じてしまいました。アンチならアンチらしく理論武装して挑め。エラそうにかく言う私はlaravel使いこなせてません

**nobodyさん** · 2020/05/02(土) 02:53:21.55

VueよりもReactの方が絶対いいって！

**nobodyさん** · 2020/05/02(土) 07:04:08.36

React学んどけばモバイル開発も出来るんだぜ！
Vue Nativeも結局React Nativeにトランスパイルされるし

**nobodyさん** · 2020/05/02(土) 11:30:29.49

じゃVueでええやん、ってなる

**nobodyさん** · 2020/05/02(土) 14:33:06.67

react native 使ったことないけど実用性どうなの？
結局、 swift と kotolin のほうが良いやってならない？

**nobodyさん** · 2020/05/02(土) 14:35:20.91

あ、android と ios の互換性でって意味ね

**nobodyさん** · 2020/05/02(土) 14:35:32.86

Reactの方が細かいパーツの部品化がやりやすいから
使い込めば使い込むほど効率化できてくる

**nobodyさん** · 2020/05/02(土) 14:45:30.22

TypeScriptでやろうとするとReactがいいってなるな

**nobodyさん** · 2020/05/04(月) 04:27:06.16

過疎ってきたな
やっぱPhalconかー

**nobodyさん** · 2020/05/05(火) 00:44:44.03

lumen使いにくいな
やっぱlaravel使うわ

**nobodyさん** · 2020/05/05(火) 18:30:51.24

Laravelは今や世界最強のフレームワークだからな

**nobodyさん** · 2020/05/07(木) 15:58:46.45

５年後にLaravelを称賛するヤシが絶滅危惧種になってる
に１アベノマスク

**nobodyさん** · 2020/05/07(木) 16:09:38.70

やっぱりSymfonyがNo1になるのかな？

**nobodyさん** · 2020/05/07(木) 16:56:54.55

Wordpress/Drupalが新たな「フレームワーク」として残り続ける。
それ以外は他言語への流出が続く。

**nobodyさん** · 2020/05/07(木) 18:02:25.72

だからPhalconだって

**nobodyさん** · 2020/05/08(金) 04:23:27.43

お笑い芸人アンガールズのカッコいいほうは最近プログラミングの
勉強始めたらしくLaravelをやってるみたいだな

**nobodyさん** · 2020/05/08(金) 08:26:18.68

wordpressだけは絶対ないwあれはおもちゃでしょw

**nobodyさん** · 2020/05/09(土) 21:26:18.76

トイザらスにwordpressは売ってないと思うが

**nobodyさん** · 2020/05/10(日) 04:48:56.97

>>225
WordPressは、バージョンアップするたびに素人さん志向になっている。
ブロックエディターなんて必要なの？

**nobodyさん** · 2020/05/10(日) 19:45:22.28

Laravelって使ってみて思ったけどなんでUser.phpが直置きなの？
Modelsフォルダとか作ってそこに入れればいいと思うんだが
デフォルトでそうなっているのは何か理由があるんだろうか

**nobodyさん** · 2020/05/10(日) 20:16:08.02

>>228
俺も初めて触った時に同じことは思った。
「モデル」の定義は開発者によって様々、つまり曖昧な概念だから敢えてモデル用のディレクトリを作らなかったらしい。
だから開発者が自由な場所に配置できるようになってるし、「Models」というディレクトリを作ってそこに置いてもいいんだってさ。
俺はいつも「app/Models」もそうしてるよ。
てか公式見解は「Model」なんだけどね。

Where Is The Models Directory?

When getting started with Laravel, many developers are confused by the lack of a models directory. However, the lack of such a directory is intentional.
We find the word "models" ambiguous since it means many different things to many different people.
Some developers refer to an application's "model" as the totality of all of its business logic, while others refer to "models" as classes that interact with a relational database.

For this reason, we choose to place Eloquent models in the app directory by default, and allow the developer to place them somewhere else if they choose.

https://laravel.com/docs/7.x/structure

**nobodyさん** · 2020/05/10(日) 20:48:06.27

>>229
modelsの意味が曖昧だとしてもapp/modelsなら別に曖昧じゃないと思うけどね

**nobodyさん** · 2020/05/10(日) 21:36:58.77

LaravelはModelの意味は開発者によって様々といいながら、Laravel独自のModelという概念があるし、
その概念はDDDとかクリーンアーキテクチャでいうモデルと全く別物だからタチ悪い

**nobodyさん** · 2020/05/11(月) 03:30:41.49

>>231
DDDとか取り入れる時はEloquentsディレクトリ作ってそこにLaravelの所謂モデルを入れてる
DB取得にだけ使うから呼び方もモデルじゃなくてエロクウェントゥにしてる

**nobodyさん** · 2020/06/06(土) 15:44:19.74

うちの会社railsからlaravelに主力を変えた

**nobodyさん** · 2020/06/06(土) 16:17:02.30

symfonyしか知らんけどlaravelはhtmlのformどうやって作るんや
symfonyはformを作成する機能があってややこしいけど

**nobodyさん** · 2020/06/06(土) 17:16:44.62

>>234
symfonyもlaravelも普通のhtmlのようにform書けるぞ
わざわざFormBuilder的なの使わなくても良い

**nobodyさん** · 2020/06/06(土) 18:09:21.21

CakeにもあったけどFormBuilder的なの使ってる人居るんだな
生htmlかフロントフレームワークでいいじゃん
却って分かりにくいわ

**nobodyさん** · 2020/06/06(土) 18:39:16.18

>>232
lazyじゃなくなるな。APIなら大した問題ではないか？

**nobodyさん** · 2020/06/06(土) 23:24:04.95

>>235
えそうなの？うちの会社じゃformクラス作ってるが却って分かりにくい気しかしない

**nobodyさん** · 2020/06/07(日) 14:04:35.74

ぶっちゃけVueとかReactとかと組み合わせて使わないんなら別のフレームワーク使った方がいいんじゃない？
活発なバージョンアップでバンバン互換性が切れてるしLaravelだけの機能で全部賄ってたら古いバージョンにしがみつき続ける事になると思うんよね

**nobodyさん** · 2020/06/09(火) 22:47:20.51

>>237
ビジネスロジックにフレームワーク絡んでない方が楽できる場合もあるでしょ
まあケースバイケースってやつ

**nobodyさん** · 2020/06/20(土) 14:28:10.33

掌田津耶乃って人のlaravel入門ってどうですか？
評判いい？

**nobodyさん** · 2020/06/20(土) 15:55:51.63

評判いいよ

**nobodyさん** · 2020/06/20(土) 16:50:49.75

寧ろそれ以外の本はちょっと微妙だよね

**nobodyさん** · 2020/06/22(月) 14:39:20.20

>>241
やめておくのが吉
ご近所さんながら、玄関前に俺がかったのを置いといてあげるよ

**nobodyさん** · 2020/06/22(月) 22:22:45.90

できればなぜやめておいたほうがいいのかの理由も知りたいです

**nobodyさん** · 2020/06/23(火) 21:12:04.97

掌田津耶乃の本はプログラミング初心者向けでググれば誰かがウェブにおんなじようなこと書いてそうな内容
とりあえず公式ドキュメント（かその日本語訳）読んである程度分かりそうだったり
分からなくてもググって答え見つけ出して解決できる人なら買う必要はない

そもそもこういう入門書ってアプデの度に仕様変更で使い物にならなくなっていくからプログラミングのはじめの一歩ならいいけど基本は公式にあたる癖つけといたほうがいいと思うよ
当たり前だけどタダで読めて更新もされるんだし

**nobodyさん** · 2020/06/23(火) 21:27:07.08

でもLaravelの日本人コミッターに聞くと絶対
掌田津耶乃が上がるからそれなりに内容はよさそうな気がするが

**nobodyさん** · 2020/06/23(火) 23:08:51.29

掌田さんのlaravel本はわかりやすくてよかった
結局ほとんどググったけど、見返すとなるほどと理解が進む。
最初に何をすればさっぱりだった自分はまず掌田さんの本を見て
そかっからググって土日になんとかcrudたてることできました。
これでやっと組み込み基板の部品表管理と論理ソースのgheへのpush環境の
laravel実装が始められる…

**nobodyさん** · 2020/06/24(水) 05:13:47.76

>>246
はじめの一歩だから本でいいんだよ
いきなり公式ドキュメントを読ませようとするなどうせ挫折する
ググるのは基礎知識があってこそだ

**nobodyさん** · 2020/06/24(水) 08:11:34.48

>>249
だからはじめの一歩ならいいと書いてあるが？

**nobodyさん** · 2020/06/25(木) 23:17:10.98

ごめん書いてなかった

**nobodyさん** · 2020/06/27(土) 13:57:30.08

>>246
Laravel初心者っぽいし最初は本のほうがいいきがするけど

**nobodyさん** · 2020/06/28(日) 13:55:51.22

だからはじめの一歩ならいいと書いてあるが？

**nobodyさん** · 2020/06/28(日) 14:32:08.86

はじめの百歩くらいは本でいいだろ公式をあたれる能力が付くのはそれから

**nobodyさん** · 2020/06/28(日) 15:16:34.76

だからはじめの一歩ならいいと書いてあるが？

**nobodyさん** · 2020/06/28(日) 22:12:46.99

>>254
ゲーム好きってほどではなく軌跡のためだけにpspやvita,ps3,ps4を買う軌跡のヘビーユーザーとして意見さして頂きたい
あらかじめいうと、ルーファスが一番好きなプレイヤーの意見と考えてくれ。
Cはまずルーファスだと考えている。
身長がまず一つ、モーションで見ると、剣を抜くモーションが完全に閃の3,4のモーションそっくり。
そしてクロウに剣を突きつけるモーションは閃の軌跡2での正体を明かした後ヴィータに突きつけるモーションと同じ
またPVで撤収するときに実はユーシスが見切れている。これは正体が露見するのを防ぐためかと思う。アーツの紫の丸い玉は閃の軌跡3,4のSクラフトで最後紫になる。
PVのモノクロでロイド、リィン、ルーファス、まぁキーアもいるが、でてるのは3人の主人公の別の世界の存在である暗示。ノーマルリィンがでてくるから他の世界のルーファスがでてもおかしくはない。
前作で生きる意味を求めていたルーファス、偽物がゆえに本物になろうとオズボーンに認められようと足掻いていた。しでかしたと言われてめちゃ叩かれてるがひたすらもがいた不器用な男のファンなんだよ。
たぶんラピスも何かの紛い物、本物ではないが存在だが何かを救って救われるルーファスストーリーと期待してます。
仮にも鉄血の筆頭でレクターやクレアのように救われていないあいつは報われて欲しいと思ってるプレイヤーの妄想です。

**nobodyさん** · 2020/06/30(火) 16:56:22.98

>>253
>>255
効きすぎだろ

**nobodyさん** · 2020/07/01(水) 21:43:26.17

>>257
お前がな　どうした？顔真っ赤にして手が震えって手ているぞ

**nobodyさん** · 2020/07/02(木) 21:23:37.94

盛り上がってまいりました

**nobodyさん** · 2020/07/05(日) 22:49:30.26

信者がこれだけLaravelに夢中になるのだから
やはりおれのパンツにリソースをつぎ込めという指摘はきわめて的確なものであったといえよう
更なる増収増益のためにはパンツのステルス化及びカスタマイズモードの採用を提案したい

**nobodyさん** · 2020/07/06(月) 23:12:07.70

キチガイだらけ

**nobodyさん** · 2020/07/08(水) 21:13:14.65

Symfony蹴ってLaravel採用する理由は？

**nobodyさん** · 2020/07/08(水) 21:21:51.41

フロントエンドフレームワーク使うんならLaravelの方がいい

**nobodyさん** · 2020/07/13(月) 15:43:17.99

>>263
なんで？
JSON返すだけならフレームワークの相性なんて関係なくない？

**nobodyさん** · 2020/07/13(月) 21:18:55.24

>>264
まさかいまどきJSONでやり取りしてるの？

**nobodyさん** · 2020/07/13(月) 21:55:48.19

>>265
してるけど？

**nobodyさん** · 2020/07/13(月) 23:50:37.06

俺もJSONだわ

>>265
まさかXMLか？

**nobodyさん** · 2020/07/16(木) 18:55:44.28

おいおい、まさか…

**nobodyさん** · 2020/07/16(木) 22:51:15.76

天下のGoogle様の場合実はjsonではなくcsv形式でデータをやり取りしていることが多い

**nobodyさん** · 2020/07/16(木) 23:26:40.85

ここの連中JSONでやり取りしてるのかよｗ
セキュリティ大丈夫か？

**nobodyさん** · 2020/07/17(金) 08:18:44.28

JSONに親でも殺されたんだろうな

**nobodyさん** · 2020/07/17(金) 08:30:24.71

サーバー→クライアントがJSONなのであって逆方向の通信にJSON使ってるヤツなんて殆ど居ないだろうし
元々表示させる為のデータが何形式だったからと言ってセキュリティ的には関係ないだろ
クライアント→サーバーがどうかってのならまだしも

**nobodyさん** · 2020/07/18(土) 20:06:08.37

いやクライアント→サーバーがJSONでも一緒だろw
平文通信ならともかくw

**nobodyさん** · 2020/07/18(土) 20:19:33.20

>>273
素人にはわからないかもしれないが、サーバ側で不特定の相手からjson形式でデータを受けるときは、セキュリティ上考慮すべきことが増えるんだよ。

**nobodyさん** · 2020/07/18(土) 20:36:32.85

13日の金曜日には特に

**nobodyさん** · 2020/07/18(土) 20:43:24.50

お前らのアプリってパスワードも平文で保存してそう

**nobodyさん** · 2020/07/18(土) 21:17:13.50

Laravel使ってて標準のハッシュ使ってないヤツとかいるの？

**nobodyさん** · 2020/07/18(土) 21:26:58.50

>>274
それJSONに限った話じゃないと思うけど？
具体的な問題点と、JSONに代わるセキュアなフォーマットを教えてください。

**nobodyさん** · 2020/07/18(土) 21:45:36.91

JSONは悪意あるスクリプトを埋め込まれやすいってのは聞いたことあるな
JSONというよりはJSONのパース処理側に問題があるらしいが

**nobodyさん** · 2020/07/18(土) 22:20:59.76

認証使えばいいじゃん

**nobodyさん** · 2020/07/19(日) 03:13:51.03

認証とは？

**nobodyさん** · 2020/07/19(日) 04:40:16.89

>>274
それ、JSONP

**nobodyさん** · 2020/07/19(日) 07:12:07.65

掌田津耶乃のってアマゾンの評価悪すぎて

**nobodyさん** · 2020/07/19(日) 10:55:10.36

>>279
そうそう。json_decodeとかunserializedとかは、改ざんされた入力データで想定外の復元が行われる可能性があるから、信頼されたクライアントでない限りは使わないのが無難(使うなとは言わない)。

**nobodyさん** · 2020/07/19(日) 11:24:49.04

WordPressでは普通に使ってるけどね

**nobodyさん** · 2020/07/19(日) 14:32:07.57

>>284
パース時にアンセキュアな問題があるとして、それはどんなフォーマットでも言える。
それはjson固有の問題ではないし、csvだろうがxmlだろうがx-www-form-urlencodeだろうが、パースが甘ければインジェクション系の脆弱性は起こりえる。
逆に、「○○っていうフォーマットを使えばパースは安全」って言ってるならその認識を改めたほうが良い。

>>274 や >>279 「考慮すべきことが増える」とか「悪意あるスクリプトを埋め込まれやすい」って書かれてるけど、肝心の比較対象が書かれていない。

**nobodyさん** · 2020/07/19(日) 14:33:19.24

>>286
だから、使うなとは言わない

**nobodyさん** · 2020/07/19(日) 15:04:51.15

>>287
その前に君の「〇〇っていうフォーマットを使えばパースは安全」
という認識を改めたほうが良いよ

**nobodyさん** · 2020/07/19(日) 15:07:59.54

>>284
言い過ぎだろ。json仕様に脆弱性はないし（今のとこ）、json_decodeにも脆弱性は見つかってない。
その点でcsvだろうとxmlだろうと、x-www-form-urlencodedだって同じ。（は言い過ぎか）

**nobodyさん** · 2020/07/19(日) 15:09:04.04

>>288
こどおじには理解できないみたいだからそうせめてやるなよｗ

**nobodyさん** · 2020/07/19(日) 15:10:05.94

json_decode脆弱性見付かって何回かアップデートかかってるぞ

**nobodyさん** · 2020/07/19(日) 15:10:17.39

>>289
げ、まる被り（笑）まあ、あとは実装するやつの心がけ次第ということだ。

**nobodyさん** · 2020/07/19(日) 15:23:44.12

そうそう。リスク判定できない人はjsonでデータを受け取るなと。

**nobodyさん** · 2020/07/19(日) 15:34:47.57

>>291
2009年の脆弱性言われてもなあ。
>>291

**nobodyさん** · 2020/07/19(日) 15:59:01.63

json自体の脆弱性の話はしてないんだ。
使い方が悪ければ脆弱性につながりやすいというのを理解できないおこちゃまをどうしてやろうかという話なんだ。

**nobodyさん** · 2020/07/19(日) 16:15:55.69

>>295
いや思いっきりJSON固有の話してたのに、急に一般論にして話そらすのやめよう？
話の始まりは >>265 だからそれを見返してね。

「ユーザー入力をJSONでフォーマットするのは危ないですよ」
と
「どんなフォーマットを使ってもユーザー入力は気をつけましょう」
じゃ全然話が違うでしょ

**nobodyさん** · 2020/07/19(日) 16:31:04.14

>>296
どんなフォーマットだろうが不特定からの入力は、危険だからValidationは必須だよ。
特にjsonとかのデコードを前提とする入力は、さらに慎重なValidationを検討する必要があるよ。

という話をずっとしてるでしょ。

**nobodyさん** · 2020/07/19(日) 16:41:34.32

>>297
それなら早く具体的な問題点とJSONに代わるセキュアなフォーマットを挙げてみてよ。
以前のレスにもそう書かれてのになんで挙げないのかな？

**nobodyさん** · 2020/07/19(日) 16:41:57.45

顔真っ赤だな。
jsonはJavascriptとの親和性、csvはExcelとの親和性、XMLは構造の自己記述性とか、それぞれ特徴あって、好きなの選べはいいじゃん。
今回の話はJSONが良さそうに思えるけど、他の選択肢、どんなのあるん？

**nobodyさん** · 2020/07/19(日) 17:04:28.63

>>298
たとえばusersテーブルに住所・電話番号を更新させるAPIをつくるとして、

1.住所・電話番号をそれぞれ2つのパラメータとして入力させる場合
住所・電話番号のチェックを行い、それから保存。
2.住所・電話番号を連想配列に格納したものを、json_encodeしたもので入力させる場合（パラメータ1つの場合）
decodeして1と同様のチェックを行う。更に追加でdecode後に要素の過不足が無いかもチェック。それから保存。

という感じで明らかにチェックしなければならないことが増えてしまう。
そして万が一追加チェックを忘れてしまうと、実装によっては脆弱性になりかねない。