【PHP】Laravel【フレームワーク】 Part.8
■ このスレッドは過去ログ倉庫に格納されています
いやうち自社サービスだから請求なんて概念無いけど
つかそんなの客との契約次第だろ
どんな契約してんだよ >>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なんだろうって謎が解けたわ
今日もまた一つ賢くなってしまったありがとう いまいち本番環境へのデプロイがイメージわかないんだけど
node_modulesやvendorフォルダってそのまま本番環境にコピーしていいの？
それとも本番環境でnpmやcomposer等のinstallコマンドを実行しないとだめなの？ >>313
1のやり方だと多言語化できなくない？
それだと日本語オンリーになる >>317
どうしてそう思ったんだろう
resources/lang/en/validation.php
を変更してるって事なのかな
だとしたらenってディレクトリ名のenってどういう意味か考えたらすぐわかると思う
resources/lang/{locale}/validation.php
こう考えたら日本語オンリーにはならないよね >>316
環境によるから何とも言えないけど
基本的にvendorとかnode_module辺りはコピーしないでやってる 今までlaravelできますって言われてちゃんと使えてる人にあった事ないんだけど
みんな自己評価高すぎじゃない？ >>316
どういうデプロイの仕組みを使うにせよ、composer installやnpm run productionを実行してから本番と同期とるような処理を書いてる。 >>320
俺もその認識。たぶんconfig/app.phpのローカライズ用の設定変更などせずに開発してるんじゃね？ 別にvendorファイルをコピーしても害はない気がする vendor以下をコピーして受けられるメリットがあんまりないのよね
環境がWindowsかMacかLinuxで少しだけbinに入るファイルが違ってくるし 自分が居なくなっても別の人に保守してもらうことを考えたらWindowsは選択肢として有り composerやnpmは環境次第で高確率でトラブるから使わないようにしてる
レン鯖だとそもそも使えないしな WindowsとMac使わないって開発環境もLinuxって事なの？
そうでないならどこのvendorをコピーする想定なんだろうか 開発環境はWindows上のLinuxだろDockerか何かの
Windows用のVendorが必要になることなんてないが composerやnpm使ってデメリットになることはほとんどないな 【悲報】Laravel9でまたModelsディレクトリが消失してしまう モデルの置き場を強制されることを嫌う奴が開発陣にいるの？
決まっている方が使いやすいと思うし従来のでも結局Models作って
そこに置くからどっちでもいいんだけどｗ リポジトリには来てないけどな。情報源はどこだろう？公式のdiscordでもなさそうだし。 皆さんはlaravelを使っていると思いますが
この機能が欲しいとかここ直してほしいとかそういう要望って何かありますか？ Eloquentの100ループ問題を早く修正してほしい Eloquentって使ったことないなそういえば いつもクエリビルダ使ってるけど
Eloquentって何かメリットあるのかな >>336
bladeをWordPressみたいにWeb上で更新できるようにしたい
ローカルでいちいちエディタ使わないといけないのが面倒だ laravelはsymfonyと比べると使いづらい >>340
自分もあったら良いなと思ってたんですよね
自作するとしてエディタは何がいいと思いますか？ それならFTPなどの同期でも利用すればローカルのbladeファイルを保存したらアップロードされたりするしそれで良さそうな
まぁ本来ならgitで管理して最低でもサーバーでgit pullするとかだろうけど 使う場面が想定できんな
だったらWordPressでええやん、ってなる
bladeの処理をエディタの部分だけ切り離すのも大変そうだし
作るにしてもちょっと割に合わない 詳細な要件は不明だけど、今どきはgithubリポジトリでピリオド打鍵したらすぐwebエディタ起動するじゃん？それでbladeファイル編集して、保存時にgithubアクションでデプロイする仕組みにしとけば、希望は叶うんじゃないの？プレビューしたいとかなら、話は変わってくるかもだが。 >>345-347
やりたい事はかなりシンプルで
デザイナー？HTMLコーダー？の人から上がってきた
HTMLをbladeファイルにする作業から逃げたいってだけなんだよね
結構github何それ？って人とかいてそういう人にどうやって直接触ってもらおうか悩んでるのよね
ヘッドレスCMSとかも考えたんだけど不評でさ デザイナレベルならGitHubたたき込んだ方が早い
メインブランチには触らせないようにしとけばいいし
てか、Larabelで更新させたらbladeの履歴管理はどうなるん？ >>348
そういう奴はjigsaw使え。それ使って作らせたらbladeファイルで納品させられるぞ。
https://jigsaw.tighten.co >>349
直接触れるんだから更新履歴とか知った事か
そっちで管理してねって感じ
それが嫌ならgit覚えて下さいかな file_get_contentsでbladeの中身を取得して、それを書き換えるってことはできないの？ まあ、どうにせよ需要がニッチで開発する人はいなさそうだ WordPressに実装されてるって、素人にも編集させるためだろ？
なのにニッチ（需要が少ない）と決めつけて良いのか？ WordPressでできないからLaravelで一から作ろうとしてるんだろ そろそろLaravel始めてみようと思うんだがそれぞれ一言ずつください そんなに需要があると思ってるなら自分で作って公開すれば良いと思いますわ
みんな喜んで使ってくれたら嬉しいでしょ >>359
複合主キーはLaravel(Eloquent)では扱えない >>363
それならLaravelも十分使えると思うよ
昔は日本だとCakeばかりだったけど最近はLaravelばかりという気がするし PHPのできないHTMLコーダーにビュー作らせるためにbladeとかtwigみたいなテンプレートエンジンがあるんだろ？
それもできないからCMS作るって斬新だな 普通はwebデザイナーにHTMLを作って貰ってそれをプログラマが
bladeにするみたいな感じが普通じゃね？
そりゃデザイナがbladeまで作れたら楽だけどそんなところ少ないんじゃね デザイナーはモック作ってお前らがphpでマークアップするんだろ
何で他人にやらせてるんだよ
どうせ、cssをまともに作れなくてデザイナーが指定したとおりに作れないんだろうが 別会社が作ったHTMLを組み込む場合は自分でbladeにするけど、社内で全部作る場合はデザイナーがblade書くよ
ただし@なんちゃらの部分はこっちで付け加える、修正時はそこをいじらないようにしてもらう たとえばデザイナーに修正させるときはどうするんだよ？
いちいちプログラマがマークアップしなおすか？ いじるなって言ってもミスは防げないだろって意図か？
うちはコーダーにもGit使わせてるからバグってたらマージさせないだけだぞ プログラマーが作るhtmlとcssはマジでゴミクソだからな
生まれつき目ん玉腐ってるからデザインを再現できない
崩れるしバラバラ
色や線すら理解できない
普段どんな世界見てるんだろなこいつら 俺が書くHTMLのソースはきれいだと、よくデザイナーに褒められるぞ。
丁寧に書くよう心がければ、結果に現れるということ。 俺の周りはデザイナー作のマークアップのほうがひどいわ。セマンティック何それ？コンテンツモデル何それ？autoprefixer何それ？みたいなの多い。
おまけにタイトルや見出しにカーニングも入れないバーティカルリズムも考慮してくれない。illustratorやphotoshop使える=デザイナて感じだから、マークアップやらせるのがそもそも無理があるんやろなぁ。 Reactをいじっているところだけど、
こうなるともはや、デザイナのHTML,CSSをBladeにするのは誰か？みたいな話は論外になって
全部フロントエンジニアの仕事になるるるな。
デザイナにコンポーネントとか理解できるわけなくなくない？ >>381
自称フロントエンジニアはただのプロップスマン
デザイナーにステート管理とstyleComponentとjsxを任せるしかない >>382
理想はそうしたいけどそうなると今までのデザイナーの担当範囲を相当超えちゃうでしょ
もはやデザインができるプログラマーみたいにならない？ そもそもデザイナーがコーディングなんて担当しないだろ
デザイナーとフロントエンドエンジニアとバックエンドエンジニアはそれぞれ存在する Laravel6でAppServiceProviderのboot()に↓を記述してDBアクセスしてもログが出力されないんだけど原因思い当たるエスパーいますか。
\DB::listen(function ($query) {
\Log::debug('====================');
}); >>386
ちなみに何がログ出力されない原因だったんですか？ >>383
プログラマーができないんだから仕方ないじゃん
今まででまともにできるプログラマーを見たことがない
>>384
デザイナーはhtmlとcssができてプログラマーはできないからやらせるしかないよな
モックからマークアップに起こせるプログラマーもいないし >>387
クエリログを出力していない別のログファイルを見てました、、、 Laravelerって簡単なWEBページ作成すらできないのかよ・・・・ LaravelってCakePHPでいうテーマ機能って無いんだな ページ作成できるできないで言ったらできるぞ
作ったものが何故か不評なだけ、俺には見やすくて使いやすいんだけど Laravelの認証ってLaravelだけで完結してるの？
Firebaseとか使う必要ないのですか？ Firebase使わんとならんとかなら使いようがないだろうねw そもそもなんだけど、auth0とかFirebaseとかなんで外部の認証サービス使うんですか？
Laravelとかのフレームワーク＋DBで完結できないんですかね？ 釣りでしょどうせ。初学者がLaravelセットアップして最初にやることが認証パッゲージの導入でしょうに。 完結できるならそれでいいんですが、なぜLaravelでFirebaseなどの有料認証サービスを使う開発があるんですか？
外部の認証サービスを使うメリットってどんなものがありますか？ 簡単な話だよ。外部の認証サービス使えば、内部に認証情報を保存しないから、セキュリティ面での不安が少なくなる >>400
うーん、だけどFirebaseでIDトークンって厳密には漏洩リスクがあるから最大1時間で可能なら要件によってもっと短く設定しますよね
どっちもリスクあるから好きなように使えってこと？ 作り方次第では？
漏洩のリスクって何を想定してるのかによるが 認証って、どのレベルまでのを想定してはなしてんのよ？ Laravel用のSmartyってあるんだな。しかも8にも対応してる わざわざsmarty使う必要は無さそうだけどcakeからの移行なら使いやすいのかな？
変えるならtwigの方が好みだな ■ このスレッドは過去ログ倉庫に格納されています
