【PHP】Laravel【フレームワーク】 Part.2
■ このスレッドは過去ログ倉庫に格納されています
>>225
自然と意識できるようになるまでまだ先は長いな…たぶん 標準搭載されてるServiceManagerはオーバーライドできるけど、それやるとapp.phpを入れ替えないといけんのよね。
オーバーライドすんなってことなのかな。
でもログ周りとか微妙なんだよね。 >>227
ServiceManagerってなんだっけ。ServiceProvider のこと？自分はガンガン置き換えてるよ。 >>228
ああ、申し訳ないProvider。
logとかevent周りとか、こいつら置き換えて使ってる？
container作られる時に、結構余計なことしてるのよね。。 >>229
defer付いてるやつは遅延ロードだから使わなきゃ動いてないよ。
logは標準の定義は残して使いつつ、logger.hoge の名前で別インスタンス追加して必要なときに取り出してる。
だいたいこれで事足りる。
標準のプロバイダを継承してカスタマイズしなきゃいけなかったのは認証とメールだけかな。 >>230
deferついてるならそれでいいんだけど、kernelの流れで読み込まれる連中でも、要件によってはそれなりにいらない事してるんだよね。認証周りは同じくカスタマイズしたけど結構めんどかった。
Facadeのメリット活かしつつ機能を取捨選択してると魔改造になっちゃうんだよなあ。 とても使いやすいし揃ってるframeworkだから、欲張ってしまうw
唯一eloquentだけはベンチとって愕然としたなー。あれは商用では使えないと思った。 >>232
ある程度の諦めは必要かもねー。自分で使わないからってFacade削除したら内部とか追加したライブラリで呼んでたとかあるから標準機能は触らないのが無難かもしれん。 >>234
そう。前者もあるけど特に後者が怖くて、標準の機能を削るって選択はなかなか出来ない。バージョンアップの時のオーバーヘッドがこれによって増大するから。ある前提で組まれてるものだから当然なんだろうけど。
削らないが無難。同意ですなあ ゴリゴリにチューニングするフレームワークではないので機能追加はしても削除はしない方針です。
パフォーマンスが必要になったら札束で殴るしかない。 >>233
そんな遅い？使いにくいのは否定しないけど速度は他と大差ない気がする。
というよりORMでそこまで遅くなる部分があるとは思えないんだよな。 >>237
ちょっと言葉足らずだった。パフォーマンスがシビアに要求されるシステムでは使えない、って感じ。もちろん速度とコーディングの利便性がある程度バーターになるのはわかるけど。
Doctrine単体とかとの比較なんで、同じレイヤーの他ORMとの比較ではないよ。
というのもLaravelでパフォーマンスチューニング、いくつかの案件でやったけどほぼほぼeloquentがボトルネックだった、ってとこからきてる Eloquentはマジックメソッドを多用したラッパーなんでオーバーヘッドはどうしても増える、PHP8のJITに期待
現状はcursor、バルクインサート、自作のバルクupsertなどで極力DBアクセス数を減らしとくしかない うーん、なんかイマイチ信じがたい話ではあるな。
マジックメソッドについてはクラスのメタデータキャッシュして2回目以降の呼び出しは速いはずだし。
例えばDoctrineはアノテーション使ってるし遅くなる要因はこっちの方が大きそう。
そもそもマッピングは枯れた技術ではあるので遅いなら他のフレームワーク参考にして同程度まで速度改善できるず。
フレームワーク全体で遅いなら理解できるけどORM単体でそんなに差がでるとは思えないな。クエリが遅いとかなら理解できるけど。 >>240
いや、queryが遅いとかではなく、リレーションシップをCollectionで表現したり（出来たり）するじゃない。そもそもそういう使い方をされる事による速度の劣化であって、同じ使い方をすればdoctrineとかでも同じ結果になってただろうとは思う。 お前達はなんでそんなフレームワークを使っているんだ？
修行でもしているのか？ Laravelのhelperかなりいいよね。関数単体もそうだしCollectionも良い。
PHPはどうしても配列プログラミングになっちゃうからCollectionを使い倒してほしい。 よく使うのはarray_get, pluck, tap, with,abort_if, throw_if, collectかな？
Collectionだとeach map first filter pluck。 >>245
現行モダンフロントのシステム作る上でFirebaseやAWS Lambdaやみたいなサーバレス以外では最後の砦感あるよね
ExpressみたいなNode系フレームワークは新規に手を出すには日本語情報少な過ぎるし(日本語情報は大規模修正入る前の旧版ばかり) mixってwebpackのラッパもしくは代替みたいなもん？ >>246
全然知らねぇんだけど、helperってもしかしてHTMLの自動生成機能の事？
アホか。要るか、そんなもん。 なんでLaravelのアホは、ガラパゴスジャパンじゃあるまいし、独自規格ばっかつかいまくるんだよ。 標準規格がゴミだから標準をラップした独自規格作るんでしょ。 >>254
おまえ、gulp様のどのへんがゴミなのか、Yeah! gulp使うんだったらwebpack使ったほうがまし おーおー、JavaScriptも満足に使えないバカどもが必死だな。
そんなんでどうやってフロントを作るつもりだ？ 未だにWindowsXPとかがあるところに収めてるシステムなので
JavaScriptは使ったことないな 俺の会社はapiサーバとしてLaravel使用してるけど
フロントは別会社が製作してるからJavaScriptは気にしたことないな map,tapは本当よく使うなあ。
Laravel使ってる現場だとたまにpredis見るけど、何故モジュールを使わないのーと思う。 結論：Laravelスレの作ったプログラムは１か月で産廃 メルカリでメルpay決済の祭り開催中！！
https://i.imgur.com/c5Rf0BQ.jpg
https://i.imgur.com/HgXj0Vc.jpg
※ポイントバックは翌日付与
更に初回会員限定で300pが貰えるキャンペーン実施中(iDで1p1円で利用可能、ポイントバックも対象)
【300pの入手方法】
・新規登録の最終ページでwelcome code
「BVUQWA」
を入力して300pゲット
・メルpay設定する
完了
うおおおお イキッテるやつほんと老害だなw
一緒に仕事したらトラブルメーカーだろうな お前らのレス見てるとお前らがいかに産廃プログラムを書いているかがわかる。
どうせ１か月ぐらいでお前らのソフトウェア産廃になってるんだろう？ LaravelはJSONを返すAPIに特化させて外観はフロントフレームワークで書いた方が絶対いい ワイはいまapp()->make()がマイブーム
うんコード化に拍車がかかる。 >>274
主にどの辺りで使ってる？Controllerなのがサービスクラス的なものなのか。 >>275
気が向いた場所。tinkerが一番多いけどモデルにもある。うんコードだから参考にはならないぞ >>275
requestを処理するのにそうゆうのもありなのか >>273
そういうデータ中心の用途だと、どうしてもPHPから離れたくなっちゃうんだよねｗ Node系のフレームワーク使えればそっちの方がいいのかも知れんけど
実用するには日本語情報が少ないんよね
サーバレスは無料で収まらない規模になったら従量課金鬼だし APIとして使うだけもLaravelが工数すくなくてすげー楽じゃね？
jsで使うのってexpressとかでしょ？ >>273
この用途だとしてもフロントでセッションとか使うならうわものはLaravelの方が楽じゃないかな Laravelの軽量版でAPI向けのやつって何だっけ？ APIだけだからとか気にせず
普通にlaravel使えばいい なあにLaravem MixとかあるしViewを使わないのなんて想定済みよ laravelがphpとjavascriptを
縦横無尽に使える両刃の剣と聞いたんだけど
web.appからアクションindexを呼び出して、
「$this->name=文字列」をいれたら
アクションwriteの$this->nameが別のモノに
なってるとか、オブジェクト指向としてオカしすぎる。
---MainController.php---
namespace 略
use Illuminate\Http\Request;
class MainController extends controller{
public function index(){
$this->name="TAROU";
/*処理A*/
}
}
class public write(){
$who=$this->name;
/*処理B*/
}
}
---wep.app---
Route::get('/test','MainController@index');
Route::post('/test','MainController@write'); $whoはいったい、なぜnullになるの？
そして、getとpostでそれぞれのアクションを呼び出した時に
どうやったら、同じインスタントを共有できるの
教えてエロい人。 ＞オブジェクト指向としてオカしすぎる。
自分スキルは自分が一番理解できてるはずなのに
こういう発言を平気で出来る精神が気にくわん！ とりあえずLaravelというかフレームワークの動作の紐解きからしようか
そういや最近はHowTo本ばっかで内部の仕組みまで解説した本ってC言語のコンパイル & リンクくらいだなあ
要望を文字通りに実現するならwebsocketサーバーなどで起動しっぱなしにしたところに
ルーティングが機能するように変態実装をしなきゃならんと思う >>293
根本的に書き方間違えてる
viewを返すにしろjsonを返すにしろちゃんとcontrollerにreturn掛け
その例じゃ何をreturnしてるか分からん てか状態を持ちたいなら
引数にRequest $request入れて
$request->session->put('name','tarou');
$request->session->get('name');
だろ
Requestがないってエラーで怒られたら
上のuse句に
use Illuminate¥Http¥Request;
って足せ >>293
当たり前じゃね？
カオスなのは自分の頭かと 呼び出してとか書いてるから
Route::get('/test','MainController@index');
でindex()が実行されてると思ってるんだろ Laravelを知らないというよりHTTPの状態管理とセッションの概念を知らなそう AWSで1時間半はまったわ
ENV反映されてないだけだった
artisanのキャッシュクリアコマンドで一瞬で解決したわ
キーないぞボケ！とかわかりやすいエラー帰ってこないのかよ そのミスとAWSは何の関係ないし
まあ、ありがちなミスではあるが >>303
あんな従量課金で請求が青天井なサービスよく使えるな >>293
＞class public write(){
これ何ぞ？ 我ながらすごい事に気づいたんだが。。
tinkerでapp()->make()すれば今書いてるクラスにエラーあるかちょびっとわかる xdebug()をtinkerで呼べば詳細なコールスタックも見れた これaxiosだけで完全遷移させようとすると
requestが正常応答のときは毎回$request->session()->get('_token')取ってきてaxiosのcsrfトークン更新しないといけないんだね
422エラー応答の時は要らないみたいだけど axiosって何。
なんかさぁ、なんでLaravelは中二こじらせたみたいに
機能の推測ができないわけのわからん名前をごろごろつけてんの？
エロなんとかとかパルメザンだかなんかとか。 tokenって取り方色々あるね
フォームに直接仕込む
metaに仕込んだのをJSで取る
cookieに仕込まれてるのをJSで取る
と最近知った
axios自体にrequest前に処理挟む機能とかあるし
そこでheaderにぶち込むとか プロジェクト全体としてフロント使わんならSymfonyでやった方がいいんじゃないか？とすら思う
プロジェクトとしては使ってるならコミュニケーションとってなさすぎ >>323
時代遅れなのは間違いない。それでもおれは使うけど。 ■ このスレッドは過去ログ倉庫に格納されています
