のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,896人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ【PHP】Laravel【フレームワーク】 Part.10

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    251 = :

    >>248
    本来であれば、そういう人にこそ刺さる資料なはずなんだけど。。。
    この資料は責務の配置方法のナレッジとそれをコード上で表す方法が記述されていているので、もう一度読み返してみてほしい

    最終ページを意識しながら読むと良いかも
    http://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022?slide=149

    252 = :

    FormRequestばりばりつかってまっす!
    Routemodelのほうはつかってないでっす!

    混在するとなんとなく混乱させやすそうなんやけど、実際どうなん?

    253 = :

    >>246
    しゅごい………

    254 = :

    >>252
    それらは性質上混在しない
    後者はコントローラー内で受け取った引数をもとにfindするケースにおいて
    引数でModelをbindすることにより、処理を書くことなく同じ結果を得られるというものだから

    255 = :

    >>254
    なるほど、実際にそうしてる人がいるならそうなんやろなあ
    例えばコントローラに
    edit (hogeRequest $hogereq, hoge $hogem )
    って書くのイメージしちゃうんやけど、もっとスマートになるん?

    256 = :

    >>255
    うーん、編集用フォームを表示するときは
    そもそもFormRequestでvalidationするケースが思いつかないなぁ
    ただupdate()の時は RouteModelBindingとForm Requestの混在がありえそうだよね
    その場合どうしてたか調べてみたんだけど、普通に気にせず混在させて実装してたわ
    Requestオブジェクトと Modelオブジェクトは別物って認識してるから混在することが無い

    257 = :

    >>256
    なるほど、実際同じものじゃないし、混在しても区別さえできてればいいってことね
    ただModelでも同じバリデーションしちゃってないかとかどこでするんやとかの、意思の統一は結局必要そうやね
    しちゃってもいいんだけど、気持ち的に
    とりあえずモヤモヤは消えたわ、さんくす!

    258 = :

    >>257
    laravelに限らず引数でいろんなオブジェクトをインジェクションするのはよくあるので、名前の付け方に気をつけてさえいれば混乱することもない気がする
    あとmodelのバリデーションは永続化する時のものだと明確にしておけば
    Requestのバリデーションと混同することはないと思うよ

    259 = :

    みんなLaravelで何作ってるの?CMS?

    260 = :

    未来を作ってるんだよ俺は

    261 = :

    わしはお金を作っている

    262 = :

    このように、Laravelerはバカだらけなのです。

    263 = :

    前にお問い合わせフォームぐらいでもLaravel使うって人いたような

    264 = :

    LaravelでBladeではなくSmartyを使用したいんですが何かそういうプラグインってありますか?
    Bladeが非常に使いにくいのでSmartyに変更したいんです

    265 = :

    あともう一つ質問があります。
    Laravelのマイグレーションで複合主キーのテーブルを作成し、そのテーブルに対応するモデルクラスも作成しましたが
    このモデルを使用して検索を行おうとするとエラーが出てしまいます。色々試したところクエリビルダでは検索が
    行えるのですがEloquentだとエラーになってしまうことがわかりました。
    おそらくEloquentを複合主キーを使用するモードに設定しないといけないと思うのですがどこを設定すればいいでしょうか。
    最初はEloquentのprimaryKeyを配列で['id1', 'id2']のように宣言すれば複合主キー検索可能になると思ったのですがそれも駄目なようです

    266 = :

    >>264
    自分が知る限りではプラグインはない

    >>265
    Laravelは複合主キーを扱えないので他のフレームワークを選定したほうがいいと思われる

    267 = :

    >>266
    定期的に現れるアンチオートインクリメントおじさんが上手い解決方法を提示してくれるであろうw

    268 = :

    Laravelでは複合プライマリは基本サポートされていないので
    どうしてもというなら複合ユニークにしてidをプライマリキーにする方がLaravelらしいかと
    (厳密にはLaravelがというよりはEloquentがと言った方が正解なのだろうけど)

    269 = :

    何度も何度もいい加減複合主キーの話飽きた
    http://laravel.com/docs/9.x/eloquent#composite-primary-keys

    どうしてもやりたいんなら
    ここにいくつか解決策書いてあるから自分で試したら良いと思う
    10年近く前の事だから動くかは知らねーけど
    http://github.com/laravel/framework/issues/5355

    270 = :

    よくわからんけどなんでEloquentって複合主キーサポートしてないんだ?
    複合主キーって割と一般的だからEloquentでもサポートするべきだと思うけど・・・

    271 = :

    >>270
    すべきと思うならならPRだしてマージされるの待ちゃいいじゃん
    いつまでもうざいやつだな

    272 :

    >>270
    OSS界隈では「ベキ論」でコアに余計な機能を追加してしまうと
    バージョンアップのたびに手間が増えて負債化するので慎重にならざるを得ない
    そもそも複合主キーなんてQueryBuilderで補完できるからEloquentで提供する必要性は薄いし
    複合主キー自体サロゲートキーで代替しても基本困らん代物だ
    加えて提供するなら最低限全てのreration関連のメソッドが修正対象になってしまう

    そういう点を考慮すると、リジェクトするのは合理的だと俺は思うよ

    273 = :

    Laravelでナチュラルキー派ってかなり少ないと思うのだがねぇ
    サロゲートキーで慣れるとナチュラルキーなんて無いわと思うし

    274 = :

    >>270
    開発者が却下したから

    275 = :

    複合プライマリキーすら実装できない間抜けLaravel開発者
    そこにぶら下がっている間抜けLaraveler

    276 = :

    >>263

    いや、お問い合わせフォームだけでもフレームワーク使うってのは良い事だよ?
    その後どんなふうにサイトが発展していくか分からないから。

    ただ、Laravelねぇ…。無理に未来に負債を残す必要はないんじゃない?

    277 = :

    >>275
    算数の授業中に「1たす1は田んぼの田だもん」って泣いてた子を思い出したw
    あの頃から、君、ずっと泣いてたんだなwww

    278 = :

    >>276
    なら何を使えば負債を残さないの?w
    まさかRailsとか言わないよね?w

    279 = :

    >>277
    体育のバレーボールの授業でずっと足だけ使ってたサッカー部員もいたわ
    いわく「ルール違反じゃないだろ」

    ポリシーの違う場が認識できないやつは一定数いるっぽい

    280 = :

    謎の世界を妄想して悦に入っているキチガイ >>277 >>279

    Laravelerって、こういうキチガイばっかなのぉぉぉx?

    281 = :

    もう、負債を残す事前提のキチガイ >>278

    マジ、Laravelerってこえぇぇぇぇwwww

    ガクブル

    283 = :

    >>280
    俺達からするとサロゲートキーを使う前提で設計されたEloquentに複合PK使いたいって謎世界なんだけど?

    284 = :

    嫌なら使うなだよな

    285 = :

    >>283
    謎の世界を妄想して悦に入っているアンチ君なんて構うなよw

    286 = :

    >>283
    寝言に返事をしてはいけない

    287 = :

    >>283
    それは間違い
    元々Eloquentは複合主キーを扱う目的で開発された
    ところが開発途中に複合主キー関連の処理で重大なバグが見つかり
    複合主キーのサポートをいったん中断してリリースされたんだよ

    288 = :

    >>287
    > 元々Eloquentは複合主キーを扱う目的で開発された
    そんな事実はないはずだけど?

    289 = :

    これ見ると設計として排除してるね
    http://github.com/laravel/framework/issues/5517

    これ以前の議論なのかな?

    291 = 272 :

    このスレ、たまにガセネタ流して悦に入ってるクズが書き込みするので
    いちいち反応しない方が良いぞ

    292 = 272 :

    >>278
    どんな言語、FWであっても負債は生まれるものだよね
    モノリスのほうが他のアーキテクチャよりも負債が増えやすいとか
    Laravelが提供しているファサードなどの便利機能が負債化しやすいみたいな議論は確かにある
    とは言えそんなのより開発を担うチームの技術力がどの水準かの方が
    よほど負債化要因としては大きい

    293 = :

    多分Laravelで挫折して逆恨みしてるんだよw
    そういう負の要因じゃなきゃここまで粘着しないだろwかわいそうにw

    294 = :

    ガイジは放置しようぜ
    仕事もした事が無いニートナマポだろうし相手にするだけ無駄

    295 = :

    Laraveler、悔しそうwww

    296 :

    アンチオートインクリメントおじさん
    宝くじのシステムの話で散々素人だとバカにされて
    まともに反論さえできずに消えて
    ほとぼりが冷めてからまた出てくるのすっげーダサいよね
    人間ここまで堕ちたくはないものだwww

    297 = :

    Laraveler、地団駄踏んで悔しかってる
    効いてる効いてるwww

    298 = :

    アンチくんは今日も謎の妄想してぐるぐるパンチ連発してんのかw
    ホンモノだな

    アラシ方がSNSでBAN食らうやつのやり方でレベル感がひでぇ
    ほかでやれ

    299 = :

    >>296
    まるで維新の政治家みたいなヤツだよなw

    300 = :

    ニートナマポな事を指摘されてファビョってる所が朝鮮人そのものなんだよなぁw


    ←前へ 1 2 3 4 5 6 7 8 9 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について