【PHP】Laravel【フレームワーク】 Part.12
■ このスレッドは過去ログ倉庫に格納されています
>>100
ドキュメント読めないアラシがさんざん居着いたスレだから、ドキュメント読めば分かる内容に触れたくない
bot相手みたいな平行線はうんざりなのよ 正直新しいバージョンを待ってるって事が段々なくなってきている
セキュリティとかのパッチは必要だと思うけど、機能面は正直今で十分だしなぁ
どちらかと言うと高速化とかそっちを頑張って欲しい気がする 多対多で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に限らず、どのフレームワークもバージョンアップするたびに
仕様が変わりまくって機能がもりもりになるけど、
最小構成のものを出してくれればいいのにな
んで、追加したければモジュールやらプラグインで追加ができれば
自由度も上がるし、過去作ったものも保守しやすいのに より自由度を高める設計変更は、バージョンアップのたびに実施されてるよ
認証周りとかすげぇと思う
逆に、トレンド的に必須になった機能をフレームワークとして取り込んだりしてるから、そのバランス取りに加わりたければ、ディスカッションに参加するしか無いかなぁ 自由に出来すぎると迷うからなぁ
デフォルトで「これしかできない」にして、
後から追加できる方が便利だと思うんだよな
余計な機能がついてないぶん、リスクも減るだろうし まあそれなんだよな
フレームワークには型に嵌めることも目的としてるとこがあるから そもそも、オモチャみたいなWEBアプリしか作れないLaravelなんか、バージョンアップしても無駄。
ちゃんとした堅牢な業務システムを破綻なく作れるフレームワークが必要とされている。 ちゃんとしたのはRubyとかJavaに任せればいいだけじゃね？
Web自体がオモチャなんだし Rubyじゃない、Pythonか
分野が違うんだし、比べる必要ないと思うけどね >>121
具体的に堅牢性に問題がある箇所ってどこ？ フレームワークが破綻なく作れる所まで担保しないしｗ
そんなのは結局その利用者の作り方の問題だしなぁ 他を貶して自尊心を保つのは大体Rubyおじさんなんだよなぁ
ホント他と比べて勝ってると思わなきゃ自尊心保てないとか可哀想としか言いようがない しかも自分ではろくにプログラムもかけないのに「Ruby命！」ｗ 我が道を行けばいいだけなのに何で他と比べたがるんだろう…？ ちょっと事実をしたかされただけですぐに頭に血が上って発狂してしまうららべらーの皆さん相変わらずかわいいw ばかべらーさんは負けず嫌いなので直ぐに反応して分かりやすいです。 wordpressが大分使えるようになったので
laravel勉強し始めたけど、もしかして一人で作るフレームワークとしては、あまり向いてない？
分業体制には良いと思ったけど、
一人でやると
・MVCに分割
・それぞれで作業
という謎の工程になっているような気がします
それとも、これは私が未熟故の感覚で、一人で制作する際もMVCを念頭において設計した方が良いのでしょうか？
今作ってるサイトは、主にゲーム攻略系のサイトで、登録・会員制にしようと思っています >>134
Laravelに限らず、一人でやる場合もフレームワーク使ったほうが良いよ
理由は、過去に作った自分のソースを忘れるから。
フレームワークなら作り方に規則性があるから思い出せるけど、
そうじゃないものは思い出すのが大変になり、時間がかかる
保守に影響出るから、サイトやアプリの成長には繋がらない >>134
認証認可とセキュリティ周りの必要最小限をフレームワークが担ってくれるって点だけでも、一人制作において十分有用ですよ
また、MVCって概念は分業のための仕組みではなく、コードを整理するための仕組みです
結果として分業に寄与しますが、根本を間違うと理解が進みません
あと、学習初期に考えることでもないですが、MVCって概念だとコードが整理できない時期が来ます
クリーンアーキテクチャだなんだといった設計手法が耳に入ると思うので、壁を感じたらそちらを学習してみると良いです >>135-136
なるほど、得心致しました。ありがとうございました。
laravel、勉強します！
皆様に幸あれ CakePHPで散々「そうじゃない」と言われたのに馬鹿の一つ覚えでDBにアクセスする物をModelと称したり、TemplateをViewと称して表示方法に係るロジックをControllerに溢れさせたりする謎のヘンテコフレームワーク >>140
あなたの思う本当のフレームワークは？
叩かれるのが怖いから答えられないとは思うけどｗ 聞けば何でも恵んでもらえると思ってる乞食は
昔から貰いが少ない Laravel練習中です
複雑なページでは、ControllerからViewに投げるというのは理解できたのですが、
静的なページ（会社概要や、特定商取引法に関するページなど）も、必ずcontrollerを通した方が良いのでしょうか？ 必ずコントローラーを通す必要は無いよ
ルートの設定内でビューを返す事も出来る
ただ、全ルート処理を共通にする（同じように書く）なら
全てコントローラーでビューを返すというルールでも良いかも知れない >>148
ありがとうございます
この辺りは、製作者の好みという感じなんですね
とりあえず今はrouteからviewを返すのおアリにして、色々作ってみようと思います 最新バージョンで、良い勉強動画があれば教えてください
動画を色々見て、話し方などが聞きやすい動画を見て勉強していたのですが、
全然動かない、おかしいな、と思ってよく見たらバージョンが4の時代の動画でした
今までExcelのような下位互換があるものしか触ってこなかったので、気づきませんでした
webプログラムは、あまり下位互換が無いものなのでしょうか？ 下位互換を保つために、PHPの新機能が使えなくなったりしたら
本末転倒じゃん v7くらいをベースで勉強して差分を取り入れるのが一番効率的なんじゃないか？ あるよー
ドキュメント読んでみ
どんどん堅牢な書き方できるようになってるから 無理に新しい形で書けば良いというものでは無い感じ
switchはmatchにしてもなぁ・・・という感じがしなくもない 無理に使う必要はないけど、enumとmatchはずっと不便だったところだから実装されて以降頻繁に見かけるよ >>150
本気で覚えたいならちゃんと本を買って勉強しよう
動画で学ぶとかまず無理よ
Ver8に対応してるの買えば間違いない
勉強はコストがかかるもの >>161
言うても最新の本はマニアックだぞ
初心者向きとはとても思えない まあ、Laravel自体が素人向けじゃないしなぁ
少なくとも無料で公開されてる動画チマチマやるよりはいいかと >>162
横からすまん
なんてタイトルの本？
方向性が合う本なら読んでみたい なんだかんだで初めてやるなら津耶乃本がわりと無難ではあるけど古いんだよなあv6時代かぁ >>164
普通にAmazonで8と9の本探してみ？
電子書籍をのぞいて1冊ずつしか出てないから。
目次見れば素人向けじゃないの分かるよ 素人は本を欲しているけど本は玄人向け
しかし玄人は本なんて無くても調べたらどうにでもなるというｗ
本の必要性が・・・ 6の本はどれも割りと素人向けなんだけどな
なぜかそれ以上のバージョンから変わった
最新の9なんてTwitterと連携する方法説明してるしｗ >>169
あの頃が一番に入門書書いたら売れる時期とかそんなんだったんじゃない？ てか本当が4～5時代くらいが一番新規参入が多かったのが流行ってるらしいとそれに目を付けて執筆したところがそれくらいって感じ もうLaravelもphpも使われなくなってきてるからDjangoとかFastAPIにしといたほうがいいぞ
特に初心者は そもそもpythonなんかをweb系で使う事自体が間違っているのだがｗ PythonはAI・機械学習系だからな。用途が違う というか好かれてるPythonをWebフレームワークとして使いたいって思惑があったからDjangoは出来たんやろ
PHPはWebありき？の起源だった記憶
しらんけど、初心者はやりたいことを素直にできる言語をやればいいよ PythonはWebで使うには数値→文字列の変換とかが煩わし過ぎる テンプレートのyieldで教えてください
階層がこうなっています
https://i.imgur.com/t0rbVZ1.png
viewのshow
https://i.imgur.com/JBjNvJ7.png
headerのテンプレート
https://i.imgur.com/UYUTU8e.png
headerがyieldできないのですが、何が原因でしょうか？
show.blade.phpとheaderを同じ階層に置いた時はyieldが出来たので、
@yield('../layouts.header')のようにかくのかとも試してみたのですが、うまくいきませんでした あとただ読み込みたいってだけの場合は@includeってのが別にある >>180
なんと・・・
勉強し直してきます、ありがとうございます >>180のヤツ入れたら
resource/viewsに自動でファイル作られるからそれを参考にしてみ >>179-183こういう流れが本来のスレにあるべき姿だな
親切に答えた180に敬意を払う laravel勉強中なのですが・・・
git
docker（sail？）
nuxt.js
vue.js
typescript
vuetify
実務ではこれぐらい併用しているとお聞きしたのですが、
皆様普通にこれぐらい使っているのでしょうか
なんとなくですが、nueとnuxtがかなりとっつきにくい感じがしています。
laravelと同時に覚えたほうがいいでしょうか。それともlaravelを先に覚えたほうが良いでしょうか？
laravelの学習は楽しいです。 Laravel使ってるけどapiサーバとしてしか使ってないな >>185
並べてる技術は要素技術なので「普通にこれぐらい使っているか？」といわれれば普通に使ってますという回答になりますが、必須かと言われればプロジェクトごとに要不要が別れます。
Laravelはフルスタックフレームワークと言われるものなので、十分に使おうとすると幅広い範囲の技術知識が必要です。
同時におぼえるというよりは、各要素技術の体系的な知識を広く薄く身につけた上で、公式ドキュメントを参照しながら使用するツールだと思います。 >>185
必要ない。
それらを使った技術ブログをアップしている人の声が大きいだけで、
実際の現場でそこまで使うことはない。
gitは当然としても、Javascriptはどれ選ぶかぐらいじゃないか？
まだjQuery使っている人も3割はいるからな とりあえずLaravelで出来る事だけを先に覚えた方がいいだろうね
平行してVueとかやっても頭が良くないと厳しいのではないかと
フロントエンドも昔ながらのbladeで書く方法ぐらいはまず知っておいた方がいい気がする
そこでjavascriptも多少書けないとダメだしそれだけでも覚えることがかなりあるかと思う 別にjavascript的な処理が必要なければ書く必要ないけどな >>190
趣味なら無いだろうけど、仕事なら100%あるからjavascriptも次に覚える必要があるには変わりない 100%やろｗ
jsが全く無いサイトなんて仕事では無い 100%だね
ペライチのランディングページでも使うぞ ペライチなんてそれこそJavascriptで動かすサイトじゃん。
100％ってWordPressとか既存のテンプレ想定してるのか？
Laravelでイチから作る話じゃないのかよ migrateの部分を勉強しているのですが、
public function down()
の部分は自分で書かないとダメなんでしょうか？ 自動で書く方法はないのか？って話だろ
コマンド使うんだから、そう思っても仕方ない >>198
そうです
upに書いた後になにかすれば、逆のコードをdownに書いてくれるような機能があるのかと思いまして
完全手動っぽいですね 確かに推測して自動で・・・って思わなくもないけど
upも色んな書き方が出来るから（単なるPHPのプログラムだし)
今の時代にそれは望みすぎだなｗ
100年後にはAIで自動補完とか出来るようになってるかもｗ ■ このスレッドは過去ログ倉庫に格納されています
