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

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

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

    401 = :

    フレームワークと言ってもルーティング、コントローラー、データベース辺りの
    扱いが分かればそんなに大差は無い気がする

    402 = :

    フレームワークは言語問わずRails模範だとほぼ一緒。CodeIgniterはRailsの前だから違うのだろう

    403 = :

    >>401
    逆だよ
    MVCの概念を理解できた跡からが、各フレームワークの特徴が出てくる
    Laravelがフルスタックなんて言われるのも、phpで実装しにくいものをラップしてたりするからだし

    407 = :

    PHP原始人かな

    408 = :

    如何にLaravelの設計が良くできてるかって話ね

    409 = :

    >>406
    ゼロなのぉ!?

    411 = :

    >>409
    ゼロではねぇか、ゼロではねぇけど…

    412 = :

    単純にデプロイの作業が軽減される=利点にはならんか?
    よけいなパッケージ入れるのは、それだけリスクが高いわけだし

    413 = :

    >>411
    ゼロでなければそれがニッチな比較軸だろうと大きなメリットになりうるよ
    たとえば composer を利用できない環境だとかなり重要になる

    >>412
    それはメリットにならんかなぁ

    414 = :

    >>391ですが、これでいけました(Laravel 9)
    参考ページ(sof)://stackoverflow.com/questions/71923673/laravel-9-dynamic-email-configurations

    ほぼそのコピペですがこんな感じです(sendgrid)

    use Symfony\Component\Mailer\Mailer;
    use Symfony\Component\Mime\Email;
    use Symfony\Component\Mailer\Transport\Smtp\EsmtpTransport;
    ~~~
    $transport = (new EsmtpTransport('smtp.sendgrid.net', 465, 'ssl'))
    ->setUsername('user')
    ->setPassword('pass');

    $mailer = new Mailer($transport);
    $email = (new Email())
    ->from('hello@example.com')
    ->to(to@example.com')
    //->cc('cc@example.com')
    //->bcc('bcc@example.com')
    //->replyTo('rto@example.com')
    //->priority(Email::PRIORITY_HIGH)
    ->subject('Hello Subject/ 日本語テスト')
    // ->text('Sending emails is fun again!')
    ->html('<p>日本語テスト</p>');

    $mailer->send($email);
    ~~~
    sofのコピペだと動作しなくて、直接EsmtpTransport見たらいけそうで、いけちゃいました
    あと.crtファイルの参照がphp.iniに必要でした
    ありがとうございました

    415 = :

    LaravelでPDF作るのってみんな何つかってるの?
    html頑張って作ってdompdfしてるん?

    416 = :

    それが鉄板だと思う。情報も多いし。

    417 = :

    Laravel9で質問です

    あるModelからMySQLのdatetime型である、
    「created_at」「updated_at」、それと「issue_date」というカラムを含むデータを取得しました。

    しかし、それをcontrollerからreturnする前にjson_encodeなどで確認すると、
    前者2つは
    「"2022-05-30T06:57:27.000000Z"」
    後者は 
    「"2022-05-30 00:00:00"」
    と、型(フォーマット)が異なるような値になっていました。

    「created_at」「updated_at」の型(?)を変換しない方法はありますでしょうか。
    可能ならModel内で出来ればいいなと思っています。

    418 = :

    >>417
    http://mevius.5ch.net/test/read.cgi/tech/1624431485/63

    419 = :

    >>418
    マルチになってしまってたみたいなのであちらは取り下げました
    分かればお願いします

    421 = :

    必要ファイルを全部FTPでアップロードしても動くよ
    ただ更新する時にも全部コピーするのか?という話もあるし
    git pullするだけとかの方が運用はマシじゃね?

    422 = :

    >>421
    更新する時は更新したファイルだけアップロードすればいいだけじゃね?
    FTPソフトだとそういう設定できるだろ

    425 = :

    >>417
    前者はUTC

    427 = :

    >>422
    そいやそんな機能もあるか
    ここ10年ぐらいFTPクライアントとか殆ど使わなくなって忘れていたわ

    428 = :

    もはや非エンジニアが簡単に扱えるものではないのかもな
    ひと昔前は知識なくても掲示板のWebアプリとか設置したもんだが

    430 = :

    >>425-426、>>429
    ありがとうございます
    確認したら「created_at」と「updated_at」はデフォルトでCarbonを通してるみたいですね
    で、「issue_date」は通してないのでそのままと

    Modelで$datesに指定すれば、created_at等と同じようにCarbonを通すようになるみたいですね
    今回はそれと逆のことをしたいのですが、記載がなさそうです。(指定すればCarbon通さない的な)
    (PHPではないんですがフロントで"Y-m-d H:i:s"だとそのまま使用できるので・・・)

    431 = :

    >>430
    データとしてはオブジェクトで持っておいて、表示の際にフォーマットで整えるほうがきれいだと思うよ

    432 = :

    >>431
    ありがとうございます。
    Laravelとしてはそうすべきってことなんでしょうね。。

    一応ソースある程度見ると、Model.phpに
    const CREATED_AT = 'created_at';
    とありつらつら追うとイジれば変えられそうですが、影響が大きそうで止めることにしました。
    その代わり全ModelのDateカラムを$datesにつっこむ事になりそうです.。まだ設計イジれるので。。(つらひ

    お騒がせしました、ありがとうございました。

    433 = :

    え?$castsに指定してあげるかserializeDateに定義してあげるんじゃダメなの?
    http://readouble.com/laravel/9.x/ja/eloquent-mutators.html#date-casting

    434 = :

    >>433
    ありがとうございます
    あーあったんですね、、もう設計変えることになっちゃいました、そっちのほうがスジが良さそうなので
    今後の参考にします!ありがとうございました!

    435 = :

    暇だからLaravelのトレンド調べたら
    8>>6>>9>7
    って感じだった。6使ってる人多いんだね

    437 = :

    Laravel書いてると、なんかphp書いてる気がしないなぁ
    フレームワークってすごいな

    438 = :

    すごいんだけど、ファイル数多くなるのがどうしても気になるわ
    自分が把握していないファイルがあることに

    439 :

    >>438
    ある程度の規模のプロジェクトになると、自分の把握していないファイルは一定生まれるじゃん?それと同じことでは?
    必要があればリポジトリから調査も出来るわけだし、修正もできるので、本当にそれ問題なの?って疑問が湧くが

    440 = 439 :

    >>438
    ある程度の規模のプロジェクトになると、自分の把握していないファイルは一定生まれるじゃん?それと同じことでは?
    必要があればリポジトリから調査も出来るわけだし、修正もできるので、本当にそれ問題なの?って疑問が湧く

    441 = :

    フロントにもフレームワーク採用してLaravelに組み込んでるとかなりの数になるしなあ

    442 = :

    >>439
    使う・使わないを取捨選択できれば良いんだが、大抵は一式入れるからな
    だからcomposerした後は40MBぐらいになる
    調査するにも数が多すぎるだろ

    445 = :

    WordPressはもっと大きいけどな

    446 = 439 :

    >>442
    どんな調査する気だw
    調べたい箇所を追っかけるだけだと思ってたわ


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

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


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