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

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

本家
https://laravel.com/

git
https://github.com/laravel

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

※前スレ
【PHP】Laravel【フレームワーク】 Part.9
https://medaka.5ch.net/test/read.cgi/php/1636499781/
【PHP】Laravel【フレームワーク】 Part.10
https://medaka.5ch.net/test/read.cgi/php/1647325775/
【PHP】Laravel【フレームワーク】 Part.11
https://medaka.5ch.net/test/read.cgi/php/1658553311/

>>31
お前はその連番すら作れないだろ

草

>>32
auto increment だから大丈夫です！（キリッ！）ｗ

14万おじは餓死したのか？ｗ

途切れない連番なんて先に採番した番号がコミットされるまで採番させなければいいだけじゃん

>>36

新たなバカベラー出現

>>36

これが、Laravelが無いと何も作れないバカベラーの知能程度なのです。

14万おじ生きていたのかｗ

途切れない連番の実現方法に時間費やしてるような無能だから薄給フリーランスなんだよ

>>40
F社とかなら普通にそんな事の為に時間と人員を費やしてそうだな

FってF通か？ｗ
NとかHとかも似たようなものだがｗ
NDATAも子会社や関連会社ばかりだし
大手でまともな所見たこと無いｗ

もうNはソフトウェア開発関連からは撤退したとか聞いた気がするからやってないんじゃないかと思うが

みなさんだと管理画面70ページぐらいは何人月くらいかかりますか？
テーブルの各カラムで検索とソートができる仕様で技術選定は自由だけど一括読み込みしてクライアント側で捌くのは無しです

>>42
日本の大手と言われるところは、基本、外注に仕事を振るだけなんでしょ？

>>44
「管理画面70ページ」とは？

>>46
AdminLTE等で作る一般的なCRUDのアプリで
リスト表示や入力含めてトータル70画面くらいの想定です

システム発注する側か受注する側か知らないけど今日日の流行りは自社内製で
自社内製で作る場合で要件固まって無いなら少しずつ作るやり方になって
少しずつ作るなら管理画面70ページは多い。
自社業務用のシステムは自社で作ったほうが自社向けの改修も対外向け受発注処理無くて済むから作りやすいよ

>>45
客に高い金を請求してよく分からん様なヤツでもなんでもかんでも増やしてとにかく大人数（派遣集め）にしたがるイメージだな

>>47
外注したら30人月くらいで出てくるんちゃうか

そんな情報だけでは見積もれんわなw

そんな情報で出せる程度の見積もりでええんや
そもそも引き合いでもないし

44です
みなさんレスありがとうございます
実は今入ってる現場の話でPGがあまりlaravelわかってない人で納品まで2ヶ月 待ってもらって3ヶ月くらいでなんとか！と言われてるんですよね
仕様書みてもまだ固まってないとこも多くer図もそれなりに複雑なので無理ですって言ってるんですが人材不足でこのままスタートしそうでして…
普段からやってる人ならこなせるのかと思って質問してみましたが無理なものは無理で出来る範囲でやってれば良さそうですね

>>53
PGじゃなくてPMでした

処理が簡単なのが沢山あるぐらいならそんなにかからないけど
画面仕様書作ってそれを承認して貰ってから作るとかメンドクサイプロセスがあると
２～３か月で作るとか無理じゃね？
過去に似たような仕事をほぼ一人で半月ぐらいでやってたけど、画面仕様書は発注元が作ってたわ

PMがLaravelをわかっている必要はないのと見積もりは画面数ではなく基本的には機能からだすものだ

>>42
この手の話Web系では無縁だと思ってたが
関わる事ってあるの？

Route::prefix('/{locale}')->group(function(){
Route::prefix('aaa')->group(function(){
Route::get('/', [App\Http\Controllers\AaaController::class, 'aaa']);
Route::get('a1', [App\Http\Controllers\A1Controller::class, 'a1']);
Route::get('a2', [App\Http\Controllers\A2Controller::class, 'a2']);
});
Route::prefix('bbb')->group(function(){
Route::get('/', [App\Http\Controllers\BbbController::class, 'bbb']);
Route::get('b1', [App\Http\Controllers\B1Controller::class, 'b1']);
Route::get('b2', [App\Http\Controllers\B2Controller::class, 'b2']);
});
Route::get('/', function () {
return view('index');
});
});

laravel9です。例えば上記みたいにprefixの中にprefix使ってて、「hoge.com/en/aaa」や「hoge.com/en/aaa/a1」が開いてるときに「aaa」が取得できる関数って用意されてますか？
->getPrefix()とか使うと「{locale}/aaa」が取れてしまいます。str_replaceとかは極力使いたくないです。詳しい方いましたらよろしくお願いします。

そもそもそんな書き方するより、例えばだけど
'en/{param1}/{param2}'
みたいな感じでコントローラの処理で$param1や$param2を見て分岐すりゃいいんじゃないの？
明確にURLが決まってるなら全てルーティングに書けば良いだけだし

最近サボってたけどなんとなくLaravelの仕組みを解ってきた、ちょっと興味わいてきたわ
久しぶりに触ってみようかな

相談です。
bladeテンプレートのview(子)がlayout（親）を継承して表示する状態になっています。

親子間で変数を共有する方法を探しています。
「親」で、複数の「子」で共通する変数を定義して使いまわしたい都合です。

子の変数を親が拾う処理は子：@section　親：@yield
でいけるのですが、その逆ができないか探しています。

ウェブの資料だとinclude()を使うとできるようなことを言っていますが、
親のyieldに子がsectionで入れる構造を変えたくないです。

この構造で親→子に変数を渡す方法があったら知りたいです。

>>61
設計変えた方がいい

概念的にはlayoutはトレイトであって親クラスじゃないからな

トレイトっていう考え方しっくりきやすいな
今度教えるとき使ってみよ

相変わらずLaravelはポンコツだな

Laravel勉強してるけど「これ覚える必要ある？」ってなってる。

ゴリゴリ自分で書いた方が楽では？

フレームワークって、同程度の品質で量産するためのものだからね
1,.2個ブログ作るだけならwordpressのほうが絶対に早いし楽

認証管理とかフロントフレームワークとか導入しやすいし
最近のComposer使わないとインストールするのがめちゃくちゃめんどくさいライブラリ入れる場合とかあるじゃん

>>66
そう思うなら使わなきゃいいだけ
自前で作ってセキュリティまで担保出来るとは思えんが・・・

ログイン周りはフレームワーク使わないと怖いな
いつ攻撃側がアップデートするか分からんし

ペライチのランペならメモ帳で十分だけどね

俺的にはReactがバックエンドにそのまま繋げれる環境が簡単に用意出来るのを知った時点で俺の中でのLaravelの優位性が一気に爆上げした

認証周りはFWに頼るべきだよなあ
自前とか今どきだと考えることおおすぎて

勉強の段階でもうLaravel不要とか言ってしまうのスゴいなよほど自分の書くソースコードに自信があるんだな

laravel勉強し、将来的に色々なwebサイトを作れるようになりたいのですが、何から勉強すると良いでしょうか
ブログを作ってみる、などでしょうか？

今はwordpress＋サクラエディタで、
開発環境もちゃんと整備しようかと思っています

ちょっと古いが何からやったらいいか分からんなら津耶乃本から始めるのがいいと思う

>>74
もう12年やってるからな。
今のところ被害ゼロだぜ。

ぼちぼちPhpExcelとか素のphpだと新しいバージョンのphpで使うの無理くね？

作るのは自分が好きなの何でも良いから
とにかく頭と手をどんどん動かせ

migration ファイルのフォーマットが変わっててビビった
変わったのは最近だと思うけど、コレなんで変わったの？

>>80
言うほど変わってるか？

何が変わったっけ？ってレベルで気づいてない

書き方のサポートは随分前に変更されてたらしい
変更前後はこんな感じ

https://qiita.com/ucan-lab/items/eb10ec577d8e08226b33

多分、最近テンプレートが新しいものに切り替わったんだと思う

return new class って書き方を見たことなかったんでそこでビビったｗ

ぜんぜん気づかなかったw

変更じゃなくて別の書き方も追加されたが正しいのでは？

正しくは以前別の書き方ができるようになった
で、最近それがデフォルトとして採用された
だと思う

まぁ、経緯はどうでもいいw

なんで新しい書き方になったのか知りたかったんだけど、それはQiita読んで完全に理解した
なんでこんな書き方ができるのかは全然分からん（完全理解ｉ以前の分からん）

無名クラスなんてPHPで出来る事をそもそも知らなかった件ｗ
https://www.php.net/manual/ja/language.oop5.anonymous.php

まぁ、普段使う事無いし、フレームワークとかの設計者ぐらいしか正直いらんのではと

無名関数はなんとなく分かるんだけど、いきなりreturnが意味不明だったのよ

まぁ、そのうちコード読んで見る

質問なんだけどデータベースのテーブルからWhereだけでレコードってとってこれるの？

Eloquentだと別にselect書かなくてもSQLで言うselect *にはなるよ
そういう意味じゃなくて？
例えば
Model::where('no','>',100)->get();
みたいな書き方は出来るよ

>>88
configs以下の設定ファイルもreturnで返してるから何となく分かるっしょ

無名クラスはinterfaceとabstractのテストする時
実体クラス作る必要なくなるから便利だった

>>90
get使わないで取れる？
table(’tablename’).Where('number', 100);
こんな感じで

データベースのマイグレーションが無名クラスの実装になってる

>>93
getかfirstまたはfindなどを使わないとそもそも取れないｗ
それらを最後に使う事で実際にSQLが実行されるからね
getなら複数（結果が０や１つでも配列となる）
firstならlimit 1と同じだから結果は単体（取れない場合はNULL)
findはwhere('id',xxx)->first()と同じようなもの

firstWhere

>>95
やっぱそいだよね、仕事先でGetしなくても取れるって話聞こえたから本当か？って思っちまったよ。

独自のメソッドを用意すれば出来なくはないけど、そこまでする必要が無いというか
明確にget() or first()にしておいた方が分かりやすいかと思う

新規作成で罠かかったわ、カレントディレクトリとかに罠にハマって時間を無駄にした

10はいつ出るの？最近Laravelの話題ないよね

>>100
ドキュメント読めないアラシがさんざん居着いたスレだから、ドキュメント読めば分かる内容に触れたくない
bot相手みたいな平行線はうんざりなのよ

>>101
わかる

正直新しいバージョンを待ってるって事が段々なくなってきている
セキュリティとかのパッチは必要だと思うけど、機能面は正直今で十分だしなぁ
どちらかと言うと高速化とかそっちを頑張って欲しい気がする

多対多で3つのテーブルをリレーションする構成を考えてるんだけど、Pivotを使うのが正攻法？

以下の記事でやりたいことは実現できそうなんだけど、中間テーブルの名称とかちょっと気持ち悪く感じてる
https://qiita.com/kkznch/items/72ff650737eff863e4d9

3つのテーブルは記事と同じく多対多対多の関係です
良い方法があれば教えて

それが正攻法なんでそれでやりましょう

やはりこれが正攻法なんですね
ありがとうございます

テーブル名だけ気持ち悪いんで3つ突っ込んで設計してみます

>>103はどのバージョンで開発してるの？
俺は7系が使える8で開発してるんだが

>>104

そんなめんどくさい事しなきゃならんLaravelって
マジ終わっとるな

>>107
今はまだ6使ってるわ
関わっているプロジェクトが長期化しているから
まだ次のプロジェクトでどうするかとかは考えてないけど
機能的には6で十分かなという感じ

laravel使ってみましたが、
ログイン画面とか一瞬で作れるんですね
sessionとかpassword_hashとか一生懸命勉強したのに、こんな簡単に作れるなんて・・・

そこから色々肉付けするのが大変なんだけどね

その勉強は無駄にはならんよ

認証はやっぱりSAMLとかのシングルサインオンですって！
SSO環境がないのならKeycloakをLDAP等に連携させるのはいかがです？
どのサービスでも同じ認証画面アクティブディレクトリのIDパスワード等で統一されれば、ユーザーも戸惑わないし、大量のIDパスワードに悩まずに済みますよ！
サービスを切り替える度々に認証入力する手間も省けて、ユーザーの満足度向上間違いなしです！
Laravel自体をSAMLのSPにするか、apache+mod_auth_mellonの組み合わせでシングルサインオンに対応できます
（認証回りを使い回して楽したい、パスワード管理ヤダ、パスワード忘れの問い合わせとか付き合ってられない）

LaravelのComposeとかのライブラリどう参照してるのとか仕組み知らないと混乱するな

>>109
確かに6で十分なんだよなぁ

Laravelに限らず、どのフレームワークもバージョンアップするたびに
仕様が変わりまくって機能がもりもりになるけど、
最小構成のものを出してくれればいいのにな
んで、追加したければモジュールやらプラグインで追加ができれば
自由度も上がるし、過去作ったものも保守しやすいのに

だったら自分で作れよw

より自由度を高める設計変更は、バージョンアップのたびに実施されてるよ
認証周りとかすげぇと思う

逆に、トレンド的に必須になった機能をフレームワークとして取り込んだりしてるから、そのバランス取りに加わりたければ、ディスカッションに参加するしか無いかなぁ

自由に出来すぎると迷うからなぁ
デフォルトで「これしかできない」にして、
後から追加できる方が便利だと思うんだよな
余計な機能がついてないぶん、リスクも減るだろうし

まあそれなんだよな
フレームワークには型に嵌めることも目的としてるとこがあるから

認証機能は後から追加するパターンなのにな

そもそも、オモチャみたいなWEBアプリしか作れないLaravelなんか、バージョンアップしても無駄。
ちゃんとした堅牢な業務システムを破綻なく作れるフレームワークが必要とされている。

ちゃんとしたのはRubyとかJavaに任せればいいだけじゃね？
Web自体がオモチャなんだし

Rubyじゃない、Pythonか
分野が違うんだし、比べる必要ないと思うけどね

>>121
具体的に堅牢性に問題がある箇所ってどこ？

フレームワークが破綻なく作れる所まで担保しないしｗ
そんなのは結局その利用者の作り方の問題だしなぁ

他を貶して自尊心を保つのは大体Rubyおじさんなんだよなぁ
ホント他と比べて勝ってると思わなきゃ自尊心保てないとか可哀想としか言いようがない

しかも自分ではろくにプログラムもかけないのに「Ruby命！」ｗ

あれはさすがにruby使いに同情する

我が道を行けばいいだけなのに何で他と比べたがるんだろう…？

ガイジだからさｗ

ちょっと事実をしたかされただけですぐに頭に血が上って発狂してしまうららべらーの皆さん相変わらずかわいいw