[過去ﾛｸﾞ] 【PHP】Laravel【フレームワーク】 Part.2 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
89(2): 61 2019/04/30(火)12:19 ID:??? AAS
>>71
まずオレの意見から言うとSymfonyは素晴らしい。けど理想を追い求めすぎて複雑。Laravelはバランスが良くて小規模アプリは最高。ただしEloquentはクソ。Doctrine持って来い。
Laravel触ってみるといいよ。勘違いしてる部分も多そうだし。
Actionの部分はService Containerを調べて。
Viewの話はロジックというのは業務ロジックのことで、例えばこの会員はAランクなので付与率5%、それ以外は1%というような話でこれはViewじゃなくてモデルに書きましょうということだ。表示のための分岐はいくらでも書いて問題ないよ。
最近のARはJOINしてもうまくマッピングしてくれるようになってる。各ORMがN+1問題をどう解決してるかコード読め。Doctrineはコードがきれいだぞ。
クエリビルダとエロは別々のものじゃなくてビルダの上位レイヤがエロだ。普通はエロだけでよい。withとlazy loadの仕組みである程度速度のコントロールはできる。
RoRとLaravelが似てるのは否定しない。Symfonyは別の問題を解決しようとしてるから用途が違う。果物ナイフとノコギリを比べるようなもんだ。
90(1): 2019/04/30(火)12:25 ID:??? AAS
>>71
「いまどきは取ってきたのをアプリ側で処理するのが流行りだ」
は確かGoogleが推奨しているコーディング方式だね。
GoogleのWEBサービスは全部このやり方で実装されている。
91(1): 2019/04/30(火)12:26 ID:??? AAS
>>73
Request生で使う奴はいないでしょ。
普通はフォームリクエスト使ってそっちで宣言する
92(1): 2019/04/30(火)12:28 ID:??? AAS
>>90
そりゃGoogleはGCP売りたいんだからそう言うだろ。RDBを使わないシステムをターゲットにしてるんだから。
RDB使ってそんなことしてたらクソプログラマ認定されるぞ。
ぐーぐるさまが言ってるからって盲目的になるのは感心しないな。
93: 2019/04/30(火)12:28 ID:??? AAS
アスペルガー特有の強い拘り
94(2): 2019/04/30(火)12:28 ID:??? AAS
JavaのSpringFrameworkのJPAや
PythonのDjango
Ruby on Rails
Laravel
Symfony
等々みんなActiveRecord方式採用しているってことは
それで十分システムを構築できているんでしょう。
95(1): 2019/04/30(火)12:29 ID:U8oZvJd3(25/43) AAS
>>89
>Viewの話はロジックというのは業務ロジックのことで、
>例えばこの会員はAランクなので付与率5%、
>それ以外は1%というような話で
>これはViewじゃなくてモデルに書きましょうということだ。
それをやめろって言ってんだ、ボケ。
なんで還元率適用後の値についてまでモデルが面倒見なきゃいけないんだ。
それはおまえ、社長が「よしこのお客さんには10%値引きしろ」って言ったら、
従業員が「社長、それはいくらになるんですか？」って言ってるようなもんだぞ。
馬鹿なのか？
96: 2019/04/30(火)12:30 ID:U8oZvJd3(26/43) AAS
>>91
おまえは何を言っているのだ？
97(1): 61 2019/04/30(火)12:31 ID:??? AAS
>>94
採用してないよ。JPAとSymfony/Doctrineは違う。もう一回調べて。
98(2): 2019/04/30(火)12:31 ID:??? AAS
>>92
大勢でアクセスされた際のJOIN高負荷問題がどのDBもまだ未解決だから
大規模だとJOIN使わない方式が推奨されてるってだけじゃないの？
PostgreSQLやMySQLやOracleとかでJOIN高負荷問題の対策チームが
個別に存在しているぐらいだし
99: 2019/04/30(火)12:32 ID:U8oZvJd3(27/43) AAS
>>94
つくるだけなら、な。
で、更改のたびにプログラマがヘドロのようになってるはずだ。
100: 2019/04/30(火)12:32 ID:??? AAS
MariaDBはわからんけど
101(1): 2019/04/30(火)12:34 ID:U8oZvJd3(28/43) AAS
>>89
>表示のための分岐はいくらでも書いて問題ないよ。
それもやめろっって何回言わせんだ。
デザイナが触れなくなるだろーが。
102(1): 61 2019/04/30(火)12:34 ID:??? AAS
>>95
ん？おまえは還元率の計算をViewでやってるの？
ECサイトでポイントを表示するケースって、カートとか確認画面とかメルマガでDM送るときにこの商品を買ったら50ポイントです！とかあるけど、全部のビューに書いてる？変更するときどうすんの。
103(1): 2019/04/30(火)12:35 ID:??? AAS
>>97
JPAはOracleのJava Dayイベントで
ActiveRecord方式ってOracleの中の人が言ってるぞ
104: 2019/04/30(火)12:35 ID:??? AAS
>>98
経験上大量レコードからJOINで大幅にレコード件数減らせるんなら減らした方が低負荷になるはずだけどなぁ
間違ってたらスマン
105(1): 2019/04/30(火)12:39 ID:??? AAS
>>101
いやデザイナーに実コード触らせるとかやめろよ。そんなやり方
デザイナーから上がってきたhtmlはコーダーが実環境にマージ・適用した方が全体でみて低リスクだし低コストになる
106(2): 2019/04/30(火)12:39 ID:??? AAS
>>98
なんで世の中JOINが遅いことになってるんだろうな。最近のARしか知らないプログラマはほんと軟弱だわ。
JOINが遅いのは設定と設計とクエリが悪いの。その対策チームはJOINを無くすために存在してるんじゃなくて、設計とクエリを見直してパラメータを調整して速いJOINにするために存在してるの。対策した後もJOINを使うの。
107(2): 2019/04/30(火)12:41 ID:U8oZvJd3(29/43) AAS
>>102
>87
>>85
>フォーマッタはあったら便利だろ。
>88
>先のことをさぁ、考えて、作るんだよ。
>>85くん。
加えて、Twigには、FilterとFunctionという便利なものもある。
おまえは、石器時代の人間か？
108(1): 2019/04/30(火)12:43 ID:U8oZvJd3(30/43) AAS
>>105
おまえのアプリは作ったら作ったまんまか？
おまえ、サーバ側の改修やってるときに、
デザイナが書いたHTMLやCSSの面倒見たいか？
物好きだなぁ…。
109(1): 2019/04/30(火)12:43 ID:??? AAS
>>103
JPA自体はエンティテイにデータアクセスの機能は持たせない。レコードと1対1の構造はARっぽいが同じではない。
拡張のActiveJPAとかいうのと混同してるのでは？
110(1): 2019/04/30(火)12:44 ID:??? AAS
>>106
いや違う。複数からアクセスされたときに単純なクエリにかかわらず
JOINが高負荷になってしまう問題が存在していて
それを解決するために各チームが存在している。
解決したソースコードを提供した人には賞金が授与されるけど
未だ誰もこれを解決できるソースを提供できた人はいない
111(1): 2019/04/30(火)12:44 ID:??? AAS
>>107
でも>>82読んだ限りだとARにフォーマッタ仕込みたいんだろ？
Twigはテンプレートエンジンの方じゃんなんでごっちゃになってるの？
112(1): 2019/04/30(火)12:45 ID:U8oZvJd3(31/43) AAS
>>106
それは、下手くそなバカがJOINするからだ。
アホが書いたくそぐっちゃぐちゃのSQLを1/3に減らしたら
実行速度が1/10になりましたとか、普通にあるだろ。
あいつらは実行計画の見方もしらない。
JOIN前にSELECTで絞りまくったほうが速いとすら思っている。
113(1): 2019/04/30(火)12:45 ID:??? AAS
>>108
変に分からんヤツに荒らされて狂うくらいなら自分でやった方がいいに決まってるだろ
114(1): 2019/04/30(火)12:45 ID:??? AAS
>>109
Oracleの中の人が言ってるんだから混同してないでしょ。
もしくは今後実装予定の機能をポロっと言ってしまった可能性もあるけど
115(1): 61 2019/04/30(火)12:46 ID:??? AAS
>>107
FiltetとFunctionはだいたいどのテンプレートエンジンにもあるが、あれはヘルパであってロジックの置き場じゃないぞ。
116: 2019/04/30(火)12:46 ID:U8oZvJd3(32/43) AAS
>>111
「たい」んじゃなくて、仕込「める」と言っているんだ。
OOPというのはそういうものだ。
117(1): 2019/04/30(火)12:47 ID:??? AAS
>>114
いいからググれ。JPAの仕様とActiveJPAの仕様を読んでこい。違いがわかるから。
118: 2019/04/30(火)12:48 ID:U8oZvJd3(33/43) AAS
>>115
寝ぼけ過ぎだ。
お前が言っていた
>表示のための分岐はいくらでも書いて問題ない
場所、
それが、その場所だ。いい加減に気づけ。
119: 2019/04/30(火)12:48 ID:??? AAS
>>110
うーん皆の話に齟齬があるみたいだからその複数アクセスの規模を明示して？
多分秒間10や20くらいじゃそうならないよね？
120(2): 2019/04/30(火)12:48 ID:??? AAS
>>112
それはJOINじゃなくてクエリの書き方の問題でしょ。
ここで言われてる複数アクセス時のJOIN高負荷は賞金がかけられてるやつだから
DB本体のコーディングの問題。
121: 2019/04/30(火)12:50 ID:U8oZvJd3(34/43) AAS
>>113
まったく、だからお前のやっている仕事はスケールしないんだよ。
連投禁止かかりはじめたから、しばらくポイント貯めるぞ。
122: 2019/04/30(火)12:50 ID:??? AAS
Java Dayに参加したことあるけど確かにOracleはJPAを
ActiveRecord方式と言ってたな。
123(1): 2019/04/30(火)12:53 ID:??? AAS
>>120
何言ってんのか意味不明。JOINのアルゴリズムはほぼ確立されていて、データ量が膨大であれインデックスがメモリに乗ってCPUに余裕があればどんなに大量のアクセスがあっても理論上は遅くならない。Btreeの仕組みとインデックスの用途、実行計画について調べてこい。
124: 2019/04/30(火)12:53 ID:??? AAS
>>117
Oracleが発言してるんだからそれOracleに言って来いよ。
どうせOracleがActiveRecordを勘違いしてるんでしょ。
125: 2019/04/30(火)12:55 ID:??? AAS
>>120
言いたいことは大体分かったけど
なんかソースみたいな記事持ってこないと噛み付いてる人は納得しないと思うよ
126: 2019/04/30(火)12:56 ID:??? AAS
>>123
遅くなる問題があるからわざわざ専門チームがいて
賞金もかけられれるんでしょ。
PostgreSQLやMySQLの開発チームの中に
JOIN問題を解決する対策チームがいるからそいつらに言って
間違い正して来いよ。
127: 2019/04/30(火)12:57 ID:??? AAS
ARの定義知ってんの？
1レコード1エンティテイ
エンティテイがDBアクセスを担う
この二つを満たしてるものがActiveRecordたぞ。JPAは当てはまらない。Oracleが言ったからって信じるなよ。
128: 2019/04/30(火)12:58 ID:??? AAS
JOINの高負荷問題で通常の開発者にはあまり関係ないはず。
あれはGoogleとかAmazonクラスのWEBサービスじゃないと
発生しないんじゃないっけ
129: 2019/04/30(火)13:00 ID:U8oZvJd3(35/43) AAS
おまえらは、LaravelのスレッドでなぜJOINの話題を始めるのだ。
バカなのか？
130(1): 2019/04/30(火)13:00 ID:??? AAS
同時アクセスでJOIN高負荷ってなんだよ…。JOIN 高負荷 賞金でググってもなんも出てこないぞ。
131: 2019/04/30(火)13:00 ID:??? AAS
DBのJOIN云々とか
ActiveRecordの定義云々とか他でやれ
ここはLaravelのスレだから
132(2): 2019/04/30(火)13:02 ID:??? AAS
>>130
よく知らんけど多分日本語じゃ無理だろうな
133: 2019/04/30(火)13:03 ID:??? AAS
それもそうだな。終わりにしよう。いいネタは出たな。
134: 2019/04/30(火)13:03 ID:U8oZvJd3(36/43) AAS
まったく、俺様のように、Laravelの欠点や、対抗馬となるべき未来のフレームワークについて語れ。
135(1): 2019/04/30(火)13:05 ID:??? AAS
話を戻すけど>>73については何がいいたいの？
136(1): 2019/04/30(火)13:05 ID:??? AAS
>>132
けっきょく知らねーのかよw
お前は日本語で誰も話題にしてないRDBのJOIN問題に辿り着いてここで披露してるわけか。すごいな。
137: 2019/04/30(火)13:07 ID:??? AAS
未来のフレームワークについては別スレのほうがいいのでは
138: 132 2019/04/30(火)13:08 ID:??? AAS
>>136
俺は120じゃないけど日本語での検索ワードじゃ無理だろうなって思ったから言っただけだよ
139(2): 2019/04/30(火)13:13 ID:U8oZvJd3(37/43) AAS
>>135
んとさ、例えば
<label for="Volume">数量</label>
<input type="text" id="Volume" name="volume">
というフィールドのバリデーションでさ、
max:255
って、ちゃんと動くのか？ って話。
140: 2019/04/30(火)13:20 ID:??? AAS
integer|max:100 なら数値だし
string|max:100 なら文字数だし
volume[] なら要素数でバリデーションだしファイルならサイズだよ。
141: 2019/04/30(火)13:26 ID:??? AAS
>>139
文字列、数値、配列、ファイルに対して255以下ってのが働くね
HTML側がinput type="file"になった場合は
255キロバイト以下という判定に代わる
142: 2019/04/30(火)13:40 ID:??? AAS
>>139
動くよ
もし数値であることも判定したいならinteger付けたりとかだね
143(2): 2019/04/30(火)13:41 ID:U8oZvJd3(38/43) AAS
なるほど。一応、型は意識していると。
では、Aの商品の時は最大50個までで、Bの商品の時は100個までだけど、
クーポンを使ったときにはBの商品は20個限定、
みたいな処理は、どこにどうやって書くの？
144: 2019/04/30(火)13:49 ID:??? AAS
AvailableQuantitySpecificationクラス作って isSatisfiedBy($cart)メソッドの中にそのロジック実装して
$validator->after()の中でバリデーション。
145: 2019/04/30(火)13:52 ID:??? AAS
>>143
それもバリデーションに書くね。その場合条件付きバリデーションって
方法になる
146: 2019/04/30(火)13:56 ID:??? AAS
色々かけるな。
afterの中でバリデーションしてもいいし
sometimes使用して条件付きバリデーション使用してもいいし
147: 2019/04/30(火)13:57 ID:??? AAS
それはバリデーションじゃなくて制約、仕様なんだからバリデーションに書くなよ。
単体でテストできるようにクラスでも関数でもいいから分離しとけ。
148: 2019/04/30(火)14:00 ID:??? AAS
まさか学校の課題をここで聞いているんじゃなかろうな
149(3): 2019/04/30(火)14:01 ID:U8oZvJd3(39/43) AAS
ほーら、なんかいろいろ言い出した。
つまり、作ってるやつで書き方違うって事だ。
150: 2019/04/30(火)14:04 ID:??? AAS
>>149
そりゃ違うでしょ。各会社でコーディング規約が違うんだから。
同じ会社なのに書き方違ったら馬鹿だけど
151: 2019/04/30(火)14:05 ID:??? AAS
>>149
誰が書いても同じになるようにしたいってこと？
なんかあんまり実務でチーム開発したことなさそう。どんなフレームワーク使っても同じになるよ。チームでルールを決めるんだ。
152: 2019/04/30(火)14:06 ID:??? AAS
逆にそんなキチキチのフレームワークとか嫌なんだがw
レールの上を走り続けたい人向けフレームワークでもつくればいいじゃん
153: 2019/04/30(火)14:08 ID:??? AAS
実際の開発だとコーディング規約が定まっていてそれ通りに書くから
少なくとも開発チーム内では同じ書き方になるぞ
154(1): 2019/04/30(火)14:11 ID:U8oZvJd3(40/43) AAS
バカどもめ。
見えるぞ。お前たちの作ったアプリが３年後に産廃の山になる未来が見える。
155(3): 2019/04/30(火)14:15 ID:U8oZvJd3(41/43) AAS
そうだ、思い出した。もう一個聞きたいことがある。
公開サイトと管理画面を作る時、このLaravelではどのようにプロジェクトを作るつもりなのだ？
156: 2019/04/30(火)14:15 ID:??? AAS
>>154
チーム開発したことある？過去に5人以上のチームで自分が満足したシステム作り上げたことある？
たぶんひとりで自分が満足するものしか作ったことないんじゃないかな。
157: 2019/04/30(火)14:16 ID:??? AAS
>>149
会社？個人？
個人なら好き勝手に書けるけど会社なら規約があるはずだから
会社が決めた制約で書くはずだが。
158(1): 2019/04/30(火)14:17 ID:??? AAS
>>155
自分でnamespace分けてサブドメインルーティングすればいいんじゃないかな。それかマイクロサービスにするか。ノリシックにしてもいいよ。
そんなのフレームワークに決め手もらうことじゃなくて開発規模、対象を見て考えるもんだよ。
159: 2019/04/30(火)14:19 ID:??? AAS
まぁ1人でやるような小〜中規模案件でも使い勝手はいいフレームワークだと思うけどね
160(1): 2019/04/30(火)14:22 ID:??? AAS
>>155
それはどういう管理画面なの。
納品先のユーザが使用する管理画面？
それともアプリ製作者が使用する管理画面？
161(1): 2019/04/30(火)14:22 ID:U8oZvJd3(42/43) AAS
>>158
何を言っているのかわからないんだが、
公開サイトのファイルも、管理画面のファイルも、
全部同じプロジェクトの中に入ると言っているのか？
162(1): 2019/04/30(火)14:23 ID:U8oZvJd3(43/43) AAS
>>160
例えば、ネットショップを作るとする。
公開画面でユーザが買い物をする。
管理画面で注文について管理する。
当然双方での料金の計算ロジックは同じではなければならないから、
モデルに相当するものは共有したい。
どうするつもりか教えてくれ。
163: 2019/04/30(火)14:27 ID:??? AAS
例が具体的過ぎて学校の宿題か
今度実装するアプリについてここで聞いているように思えるｗｗｗ
164: 2019/04/30(火)14:30 ID:??? AAS
namespace分けろよ
\App\Models 共通のモデル
\App\Frontend\Http\Controllers
\App\Admin\Http\Controllers
こんな感じで別々にするんだよ。
165(2): 2019/04/30(火)14:31 ID:??? AAS
間違っても App\Http\Controllers\Admin,Frontend にするなよ。
166: 2019/04/30(火)14:32 ID:??? AAS
従来の方法で良いんでは
AdminController作ってログインユーザーのroleがAdminのみ受け入れる
167(1): 2019/04/30(火)14:33 ID:??? AAS
>>161
Laravel使ってないから参考にならないだろうけど講演で聞いた限りでは
YahooとAmazonは、買い物画面と管理者画面は同じプロジェクト内で作っている
168: 2019/04/30(火)14:37 ID:??? AAS
固定観念の塊って感じw
169: 2019/04/30(火)14:40 ID:??? AAS
>>155
無理に擦り寄って来なくていいってば
170: 2019/04/30(火)14:42 ID:??? AAS
一般画面と管理画面でnamespace分けるでしょ
171(1): 2019/04/30(火)14:44 ID:AFYaLSZi(1/5) AAS
こーれはまた、チンパジーだらけだな。
お前らのプロジェクトが火を吹きまくる未来が良く見えるぞ。
172: 2019/04/30(火)14:47 ID:??? AAS
namespace分ける馬鹿ばっかりだなぁ
だからお前らのアプリは産廃になるんだよ
173(1): 2019/04/30(火)14:55 ID:AFYaLSZi(2/5) AAS
>>167
そいつらは自分のところのシステムであるから如何様にも出来ようが、
お前達のプロジェクトがお前たちのさじ加減でどうにかなると良いのう。
はーはっはっは。
174(1): 2019/04/30(火)15:01 ID:??? AAS
>>173
自分は>>162の場合どのように設計するつもりなの？
175: 2019/04/30(火)15:07 ID:??? AAS
>>171
Laravel誕生のころからずっと業務システムに使ってるけど
Laravel製のプロジェクトで今まで火を吹いたことないな。
別プロジェクトのDjangoとFuelPHPは吹きかけたけど
176(2): 2019/04/30(火)15:13 ID:AFYaLSZi(3/5) AAS
>>174
勿論、そのように設計するに決まっておろう。
同じプロジェクト内に作るが、
別のサイト単位で作るのじゃ。
馬鹿め。
Laravelとやらにそれができるのか？
お前にサンが救えるのか。
177(1): 2019/04/30(火)15:21 ID:??? AAS
>>176
そりゃ確かにLaravelはできないね。Symfony2の方がきれいに作れそう。
178(1): 2019/04/30(火)15:48 ID:??? AAS
>>176
その作り方はLaravelでは無理ですね。
そもそもそういうサイト設計するならLaravelは候補にすら上らん
179(1): 2019/04/30(火)15:54 ID:??? AAS
Laravelで作った決済系のサイトだとこいつが有名ですね
外部ﾘﾝｸ:github.com
180: 2019/04/30(火)15:57 ID:??? AAS
サイト単位はLaravelでもできるぞ
181(2): 2019/04/30(火)15:57 ID:AFYaLSZi(4/5) AAS
>>177-178
では、上の方でnamespaceなどとほざいていたチンパンジーどもはなんであったのだ？
182: 2019/04/30(火)16:02 ID:??? AAS
>>179
このショッピングサイトのソースだとnamespace方式でやってるな
183(1): 2019/04/30(火)16:09 ID:??? AAS
>>181
現状最高だと思えるフレームワークは何ですか？
184(1): 2019/04/30(火)16:11 ID:AFYaLSZi(5/5) AAS
>>183
お前はLaravelとやらを使っておれば良い。
185: 2019/04/30(火)16:14 ID:??? AAS
普通に複数サイトもやってるけど
パッケージに分けなよ
186: 2019/04/30(火)16:16 ID:??? AAS
>>184
お前が未来のフレームワークについて語ろうって自分から
言ってきたんだろうが
187: 2019/04/30(火)16:18 ID:??? AAS
幼稚な嵐にかまうなよ……うれションして喜んでるだろうが
188: 2019/04/30(火)16:20 ID:??? AAS
Laravelスレってみんな技術力低すぎないか？
AFYaLSZi様の言っていることはもっともだと思うんだが
189: 2019/04/30(火)16:21 ID:??? AAS
様付けとかｗｗｗ
ID消して自演かよｗｗ
190: 2019/04/30(火)16:26 ID:??? AAS
様とかこいつ頭大丈夫か？
AFYaLSZiが一番技術力低いんだが
191(1): 2019/04/30(火)16:32 ID:??? AAS
>>181
Laravelはマルチプロジェクトの概念がないからnamespace で分けるんだよ。
パッケージの使い方としては正しい。ただ設定値はフロントと管理で共通だからな。まぁ普通はサブドメインを分けて、ルーティングも分ければマルチプロジェクトになるのでそれで十分だろ。
192: 2019/04/30(火)16:34 ID:??? AAS
このスレでまともなの俺とAFYaLSZiも含めて3〜4人ぐらいだな。
フレームワークに使われて自分の頭で考えるの放棄してるやつばっか。
193: 2019/04/30(火)16:53 ID:??? AAS
お前ら平成最後の日に何やってんだよ
日本人なら日本人らしくアニメ見るとか漫画読むとかゲームするとかしろよ
194: 2019/04/30(火)17:00 ID:??? AAS
俺、仕事しながら令和迎えるんだ
日本人は24時間365日仕事し続ける生き物だからね
日本人ぽいでしょ
あはははは
195: 2019/04/30(火)17:16 ID:??? AAS
頭いい人はららベルより素晴らしいオレオレフレームワーク開発してよぉw
196(1): 2019/04/30(火)17:39 ID:??? AAS
LaravelでDoctrine使ってる人いる？一度プロジェクト見た気がするんだか見つからない。
ActiveRecordよりEntityManagerのほうが集約コントロールしやすいので好きなんだが。
197: 2019/04/30(火)17:45 ID:??? AAS
Laravel+Reactはいいぞ
198: 2019/04/30(火)17:57 ID:??? AAS
このスレでまともなの俺とAFYaLSZiも含めて3〜4人ぐらいだな。
フレームワークに使われて自分の頭で考えるの放棄してるやつばっか。
199: 2019/04/30(火)18:05 ID:??? AAS
>>196
これのこと？
外部ﾘﾝｸ:www.laraveldoctrine.org
200: 2019/04/30(火)18:19 ID:??? AAS
露骨な自作自演始まったなw
201(1): 2019/04/30(火)20:07 ID:??? AAS
Laravelが他のフレームワークと比べて
勝っているところと負けているところは何？
202: 2019/04/30(火)20:41 ID:??? AAS
>>201
771 nobodyさん sage 2019/04/17(水) 08:51:04.13 ID:???
フルスタックなところかな。キャッシュ、シュケジューラ、ジョブ、ミドルウェア、認識、なんでも設定すればすぐ動く。英語で out-of-the-box って言うんだっけ？箱から出してすぐ使えるってやつ。
203: 2019/04/30(火)21:28 ID:??? AAS
誰も一般画面と管理画面の実装方法答えられないのかよ。
204: 2019/04/30(火)21:31 ID:??? AAS
そんな質問あったか？
205: 2019/04/30(火)21:35 ID:??? AAS
別人だが俺も>>191みたいにサブドメイン切って置いてるな
DB共通にしつつユーザー認証用のテーブルだけ別のものに差し替えて認証するようにしてる
206: 2019/04/30(火)21:36 ID:??? AAS
普通サブドメインだよな
207(1): 2019/04/30(火)21:43 ID:??? AAS
基本的にデバッグ時は8000番でやってるからルート以外に置くの面倒なんよね
管理者用の認証テーブル使いたい場合はテーブル作って管理画面用プロジェクトのapp/User.phpに
protected $table = 'administrators';
とか足しとけばそっちのテーブル見に行くようになるし
208: 2019/04/30(火)22:08 ID:??? AAS
>>207
auth.php に定義追加すれば Administratorモデルで認証できるよ。
マルチユーザで使えるように設計されてる。
209: 2019/04/30(火)23:56 ID:hZKQ99fS(1) AAS
>>143
SyouhinモデルにmaxKosuuを作ってええとカスタマーと1x複数になるのか？
商品を受け取ってバリデーションに渡すと
210: 2019/04/30(火)23:59 ID:??? AAS
お前らはLaravelで和暦対応どうした？
211: 2019/05/01(水)00:17 ID:??? AAS
和暦使うような糞なシステムはないよ
和暦は役所書類のみ、それ以外は西暦でってのはビジネスの常識
昔はごくごくたまに会員情報の生年月日で使うことがあったが今は個人情報をできるだけ入れない作りが主流
212: 2019/05/01(水)00:19 ID:??? AAS
大学関係の契約書だと和暦が多いね
213(1): 2019/05/01(水)00:40 ID:??? AAS
この前「最近点画にハマってる」って言ったら変な顔された
214: 2019/05/01(水)00:42 ID:FhfsDH51(1) AAS
TENGAにハマったまま平成が終わったのか
215: 2019/05/01(水)00:46 ID:??? AAS
「てんかく」な
上下前次1-新書関写板覧索設栞歴
あと 787 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s