【PHP】Laravel【フレームワーク】 Part.8
■ このスレッドは過去ログ倉庫に格納されています
バージョン指定して5.8をインストールしたら、
普通に/public/css/app.cssがあり、bootstrapのソースが書いてありました。
バージョン8にはないので、アップグレードの間に仕様が変わったということですね
>>205
8の本は4000円するので、さすがに何も知らない状態で買うのは辛いと思いまして >>204
assetじゃなくてpublic_path いやちがった
resourceの中にあるcssをコンパイルしてpublic_htmlの中に履けば使える
そこはドキュメントルートの外にあるファイルだから読み込めなくて当然
laravel mixで調べろ 時間の無駄になるし、とっとと8の本を買った方が言いよ 5でなんとかCRUDの基礎を学んだわ
あとはバリデーションとかテストをどうするかだが
そういうのは別の本で学ぶことにするよ >>211
正確悪ぅ！ これだからLaravelerはキモいんだよ！ Laravelで複合主キーを使う方法について教えてください
マイグレーションファイルで複合主キーのテーブルを作ることはできたのですが
モデルクラスのprimarykeysにどうやって複合主キーを指定すればいいのかがわからないです >>215
ループくんはいつになったら消えてくれますか？ 非公式のトレイトがどこかで紹介されていたけど
複合ユニークにして回避するほうが無難 blade書く時に、HTMLを直接書いてますか？
それともHTMLヘルパー的なものを使っていますか？ >>219
複合ユニークにしたほうが無難なんですねご回答いただきありがとうございます。 よく考えたらマイグレーションでは複合主キーサポートしているのにEloquentはサポートしていないっておかしいよな
なんでこんな中途半端な状態になっているんだろうか 郵便番号や駅データなどの大量レコードを用意したいとき、
マイグレーションでは無理ですよね？
SQLファイルからの一括インサートが無難な気がしてるのですが それが無難だと思いますよ
Laravelのマイグレーション自体に初期データ入れるとか機能ないし シーダーの話だと思うけど
基本は開発用として用意されてはいるから
本番のマスタなどの初期データはSQLかCSVなどのデータで投入するのが一般的ではあるかな
本番でシーダー使うと警告メッセージが出るから一発で動作はしないんだけどね >>224-225
シーダーの話です。
初期データはシーダーで用意するイメージが有りましたが、
SQLかCSVの方がいいんですね シーダーで大量のデータ入れるのって大変じゃない？
CSVか何かからシーダーファイル生成するツールとかあるの？（簡単に作れそうではあるが シーダーっても大した機能ないから、直接SQL叩くのとほぼ変わらんよ
本番環境で注意してくれるとか、そんなもんくらいじゃね？ ドキュメントではシーダーで出来るよって書いてあるけどね 別に本番でもシーダーで初期値設定することが悪い訳では無いとは思う
やるなら専用のクラスを作った方が良さそうだけどね Laravelのドキュメントにはシーダーは「テスト用」とはっきり書かれているが
本番で使ってはいけない理由も、使うべき理由も特にないように思う >>230
馬鹿発見
公式でもやめろって言われてるのにまだやってる馬鹿いるんだな シーダーはテストデータ詰めるときとかは色々使いようがあるが、
本番データ入れるのに使うメリットがほとんどないもん それな、使うべき理由がない
手間が減るわけでもないし >>232
でその理由は？
特に理由が無いのに何も考えずに辞めろってｗ
シーダーで登録して何か問題あるの？ｗ プログラム板にLaravel初心者のキチガイがいてたぶんこちらに来ると思うから相手よろしく どうせいつものアンチオートインクリメントおじさんだろ よくわからないんだけどシーダーで登録するとどういうデメリットがあるの？
公式ドキュメントもいまいちそこらへんが書いてないからどういう不都合があるのかを知りたい また前スレか前々スレの話題かよ。ループくん？
初期データをどのように投入するかは前回スレで話題になって数日後というタイミングで、Taylorが自分なりのやり方をTwitterで披露してたから、それを参考にしたらいいと思うぞ。 モデルのオブジェクトでAttribute と Original で値が違う場合がある？
しかもある1つのカラムのみAttributeが空文字になっているという謎の現象。 >>243
orginalはDBから取り出した直後の値。attributeは外部またはシステムによって書き換えられた値が入る。それだけの話だから謎でも何でもないと思うが。 なぁ、ファサードって、何なん？
静的アクセスしたいならstaticな実装すればいいだけやん？
なんでファサードなんか必要なん？
何のメリットがあるん？ 俺も気になってた
staticな実装で良くねって思ってる 単に簡潔に書けると言うくらいかと
そもそも、ファサードで最終的に呼ばれるメソッドはstaticじゃないけど テストする場合、テスト側からファサードに登録しているクラスをモッククラスに置き換えられるのは大きなメリットじゃね？
逆に言うとテストしないやつにとってファサードのメリットは、newしないでインスタンスのメソッドを利用できるから記述量がちょっと減ってラッキー！ぐらいの話かもしれない。
てか、比較するなら静的メソッドじゃなくてインスタンスメソッドだと思うんだが。単にコールするときのsyntaxが静的メソッドと同じってだけで静的メソッドとファサードを比較するのは乱暴かな。 >>249
別にその用途ならDIでやれるしなぁ
わざわざファサード使わなくても良くね？ >>250
依存が少ないならそれでも良いと思うぞ。コンストラクタインジェクションで長々とクラス列挙されたら嫌じゃん？ >>249
>テストする場合、テスト側からファサードに登録しているクラスをモッククラスに置き換えられるのは大きなメリットじゃね？
まぁ、その説明は確かに分らんでもないけど、そのくらいしか使いどころが無いのかい？ >>252
普段使いではそんぐらいでしょ。レアケースで良いなら、ファサードで呼び出してたサードパーティパッケージがイケてなくて、オーバーライドが必要な時に便利みたいな話はある(実際過去1度だけそういうケースがあった)。 Laravelはそろそろcreate-projectした段階でusersテーブルのマイグレーションやモデルが用意されているのを辞めてほしい そこまで用意して来るならジャンゴみたいに綺麗な管理画面作ったくれると良いんだが >>254
いらなきゃ消せばいいだけだし
普通はそのまま使うし認証部分は大きく変えたりしないし >>256
Novaがあるでしょ。まぁ有償だけども。 usersテーブルの認証機能を使わないなら何のためにLaravelを使うのか そこまで毛嫌いするもんでもない
使いたくなければ使わなければ良いだけ
Facade警察の人に感化されたの？ usersテーブル以外で認証させる方法を教えてください >>262
テストしない人間にとってはそうだろうね。どうせDIも似たような感覚でしょ？ >>264
laravelだとvendorフォルダのファイルを修正しないとできないから諦めろ え？それじゃ、usersテーブル以外は認証できないってこと？ >>267
だからvendorを修正すればできるって
日本語分からない？ >>267
vendorフォルダの下のファイルを編集すればusersテーブル以外でも認証することができる
ただしあまりお勧めはしないがな >>266-269
クソ雑魚ナメクジは人に教えるのやめてくれ。何がvendor配下だよ。そんなゴミみたいな方法を勧めるとかありえないぞ。 認証先のテーブルをusersから変えたい場合は、config/auth.phpのprovidersに認証に使いたいテーブル登録すれば良いだけ。 俺も>>271の認識だわ。>>268-269こいつ煽ってる割には知識が浅いな >>272
それな。日本語分からないの？て笑ってしまうわ。 >>271
config/auth.php直接編集はダメじゃないか？
config/auth_local.phpファイルを作ってそっちを編集したほうがいい 元あるファイルを修正するのではなくそれをオーバーライドした
XXX_local.phpを作るのはPHPのフレームワークでは常識のテクニックだろ・・・ >>277
煽るぐらい自信満々に回答したのに、バカにされたからって話を変な方に持ってくのはやめとけ。恥の上塗りだぞ。 サービスプロバイダでmergeConfigFromメソッドとか使ったことないんかね・・・
vendor内書き換えたいとか思わないくらい色々便利な機能あるのにもったいない Taylor Otwellはよく講演でvendor直下直接修正しているけどあれ何で何だろう
vendor直下なんて書き換えないというのがお約束というのはわかっているはずだが >>281
講演見たことないから正確にはわからんけど
俺の場合パッケージ開発の場合vendor以下を作業領域にするよ >>281
> あれ何で何だろう
Laravelが「変」だから、vendorを修正しないと対応出来ない。 >>285
自分の知識が浅いのをLaravelのせいにするなよwww どうしても触るにしてもcomposer.json使ってオーバーライドするくらいにした方がいい
直接触るのはさすがにない >>281
ざっと探したんだけどvendor修正してる動画ないなぁ
viewとか言語ファイルなんかをvendor:publishすると
resources/view/vendor/パッケージ名
以下に配置されるんだけど、それ修正してるとか？
きっと意味があってそうしてて普通に開発するよりもメリットがあるからそうしてるはずで
その恩恵を受けられないのは損だから動画とかあるならマジで教えてほしい
それで開発時間5%短縮できるならやらない理由ないし サービスプロバイダやクラスのオーバーライドを理解しているなら、日常的にvendor配下をいじる必要性なんてゼロだって分かりそうだけど。 >>289
そう、パッケージ開発以外でvendor以下を触るなんてありえないってのが俺の認識なんだけど
明らかに自分より能力の高い人物でlaravelの開発者がやってるなら
それなりの理由があってメリットがあるはずだから知りたいんだよね >>290
まぁ>>288の前半部の仮説が正しいのかなって思ってる。 確かにまじでvendorフォルダ直接修正しているね
しかも「composerのバージョン２を使っている方以外はマネしないでください」という意味不明な発言もしている
俺の認識だと別にcomposerのバージョンに関わらずvendorは修正しないのが原則だと思ったんだけど
composerのバージョン２だと何かメリットがあるのか？ 自分で作ったものなら意味も分かってる訳だし動作確認とかで修正するのもありなんじゃね？
ただ一般的にはいじらないだろうが >>295
何もそんな言い方しなくても・・・
公開されてる動画で確認したのかなと思ったのでそうであればURLが欲しいって意味だったんで
公開されてないデータであれば大丈夫です >>292
俺も294と同じくtaylorがvendorいじってるところを確認できる動画のurl知りたいわ。 url出せないなら、どのメディアやSNS見りゃ良いのか教えてくれると助かる。 >>298
別に俺は話の真偽を確かめたいから言ってるんじゃないのよ
Laravelをガチでやるって決めたから
知らない手法があるのが嫌なだけ、だからいつくらいの動画かだけでも教えて欲しい
「Taylor Otwellはよく講演でvendor直下直接修正している」って>>281で書かれてるから
v7以降の話だよね？
最後の手段は英検初段の実力をフルに使って本人に直接聞いてみるから
本当はlivewireのdiscordで怖い目にあったから英語で会話したくないけど >>301
草Taylorにdiscordでボコボコにされたのかよｗ 仕事でLaravel使ってる人って、公式サポート切れた後どうしてるの？ >>304
その分の費用請求するの？バージョンアップの間隔短いから納得しない気がするんだが ■ このスレッドは過去ログ倉庫に格納されています
