【PHP】Laravel【フレームワーク】 Part.8
■ このスレッドは過去ログ倉庫に格納されています
>>215
ループくんはいつになったら消えてくれますか? 非公式のトレイトがどこかで紹介されていたけど
複合ユニークにして回避するほうが無難 blade書く時に、HTMLを直接書いてますか?
それともHTMLヘルパー的なものを使っていますか? >>219
複合ユニークにしたほうが無難なんですねご回答いただきありがとうございます。 よく考えたらマイグレーションでは複合主キーサポートしているのにEloquentはサポートしていないっておかしいよな
なんでこんな中途半端な状態になっているんだろうか 郵便番号や駅データなどの大量レコードを用意したいとき、
マイグレーションでは無理ですよね?
SQLファイルからの一括インサートが無難な気がしてるのですが それが無難だと思いますよ
Laravelのマイグレーション自体に初期データ入れるとか機能ないし シーダーの話だと思うけど
基本は開発用として用意されてはいるから
本番のマスタなどの初期データはSQLかCSVなどのデータで投入するのが一般的ではあるかな
本番でシーダー使うと警告メッセージが出るから一発で動作はしないんだけどね >>224-225
シーダーの話です。
初期データはシーダーで用意するイメージが有りましたが、
SQLかCSVの方がいいんですね シーダーで大量のデータ入れるのって大変じゃない?
CSVか何かからシーダーファイル生成するツールとかあるの?(簡単に作れそうではあるが シーダーっても大した機能ないから、直接SQL叩くのとほぼ変わらんよ
本番環境で注意してくれるとか、そんなもんくらいじゃね? ドキュメントではシーダーで出来るよって書いてあるけどね 別に本番でもシーダーで初期値設定することが悪い訳では無いとは思う
やるなら専用のクラスを作った方が良さそうだけどね Laravelのドキュメントにはシーダーは「テスト用」とはっきり書かれているが
本番で使ってはいけない理由も、使うべき理由も特にないように思う >>230
馬鹿発見
公式でもやめろって言われてるのにまだやってる馬鹿いるんだな シーダーはテストデータ詰めるときとかは色々使いようがあるが、
本番データ入れるのに使うメリットがほとんどないもん それな、使うべき理由がない
手間が減るわけでもないし >>232
でその理由は?
特に理由が無いのに何も考えずに辞めろってw
シーダーで登録して何か問題あるの?w プログラム板に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のバージョン2を使っている方以外はマネしないでください」という意味不明な発言もしている
俺の認識だと別にcomposerのバージョンに関わらずvendorは修正しないのが原則だと思ったんだけど
composerのバージョン2だと何かメリットがあるのか? 自分で作ったものなら意味も分かってる訳だし動作確認とかで修正するのもありなんじゃね?
ただ一般的にはいじらないだろうが >>295
何もそんな言い方しなくても・・・
公開されてる動画で確認したのかなと思ったのでそうであればURLが欲しいって意味だったんで
公開されてないデータであれば大丈夫です >>292
俺も294と同じくtaylorがvendorいじってるところを確認できる動画のurl知りたいわ。 url出せないなら、どのメディアやSNS見りゃ良いのか教えてくれると助かる。 >>298
別に俺は話の真偽を確かめたいから言ってるんじゃないのよ
Laravelをガチでやるって決めたから
知らない手法があるのが嫌なだけ、だからいつくらいの動画かだけでも教えて欲しい
「Taylor Otwellはよく講演でvendor直下直接修正している」って>>281で書かれてるから
v7以降の話だよね?
最後の手段は英検初段の実力をフルに使って本人に直接聞いてみるから
本当はlivewireのdiscordで怖い目にあったから英語で会話したくないけど >>301
草Taylorにdiscordでボコボコにされたのかよw 仕事でLaravel使ってる人って、公式サポート切れた後どうしてるの? >>304
その分の費用請求するの?バージョンアップの間隔短いから納得しない気がするんだが いやうち自社サービスだから請求なんて概念無いけど
つかそんなの客との契約次第だろ
どんな契約してんだよ >>303
バージョンアップするだけ。内製だからな。外注の場合は金払ってバージョンアップするでしょ。他のFWはそうだったし。
あと、Laravelが殊更バージョンアップの周期短いのは事実だけど、サポート期間はそうではない。
LTSならバグフィックスは2年、セキュリティフィックスのサポート切れまで3年ある。これはPHPのサポート期間と同等。PHPは2年間のアクティブサポート、そこから1年間のセキュリティサポート。 バージョンアップって機能が追加される訳でもないから、費用かかるの嫌がるってのもわかる
フリーでやってた時本当に嫌だった 外注だと一度運用にのせたらFWバージョンアップなんて無理だわな
どうせそのうちリプレイスになるから放置ですよ FWに限らず、別の作り方するだけでリスクが高くなるからな
ポータルサイトなんかもずっと古い技術のサイト多いだろ FormRequestのattributesに
age => '年齢'みたいな感じでユーザにわかりやすい名称に変更可能だけど
多言語化するときってどうするんだ?age => __('age')みたいな感じにして
messages.phpでage => '年齢'って定義するのか? >>311
FormRequestはコントローラの関数の引数にいるんですよね?
public function store(HogeHogeRequest $request)みたいな感じで
だとしたら多分できないと思われます。
うろ覚えですがHogeHogeRequestの処理が行われる時点ではまだmessages.phpは読み込まれていないので
HogeHogeRequestのattributesで__('age')が'age'として解釈されてしまい
画面上にそのままageとして表示されると思われます >>311
エラーメッセージのカラム名翻訳の話だよね?
いくつかやり方あったはず、検証してないから間違ってたら申し訳ないけど
1. validation.phpに
'attributes' => [
'short_comment' => 'ひとこと'
],
って指定する方法
Custom Validation Attributesってコメントに書いてあるはず
2. resources/lang/{locale}.jsonに
"attributes":{
"translation":"多言語化"
}
って指定する方法 >>311
すでに回答している内容と被るけども、langディレクトリ直下にja.jsonてファイル作って、"hoge":"ほげ"とか定義しておくと、__('hoge')てなってる箇所が、ほげ で出力される。
ただしこの方法は、view上の出力を置き換える場合に使うものであって、vallidationメッセージの多言語化はlang/jaの下のphpファイルで達成するのが望ましい。
ちなみに、jetstreamはちょっとだめなとこがあって、後者だと一部のバリデーションメッセージが英語のままになってしまい、ja.jsonで変換かけてあげないとダメだったりする。 >>314
何でlang直下の多言語化ファイルがphpじゃなくてjsonなんだろうって謎が解けたわ
今日もまた一つ賢くなってしまったありがとう ■ このスレッドは過去ログ倉庫に格納されています