isDirty() vs wasChanged()
このブログの一番最初に書いた記事において、isDirty()に関して書きました。もう4年くらい前のことです。最近必要になって使用したところ、新たな発見がありました。
このブログの一番最初に書いた記事において、isDirty()に関して書きました。もう4年くらい前のことです。最近必要になって使用したところ、新たな発見がありました。
Laravelを最新のバージョンに更新するタイミングは難しい。しかし、5.7,5.8などのメージャーバージョンが更新された直後に更新するのは避けた方が良いです。なぜなら、新バージョン直後は必ずいくつか予想できない問題が出てきて、その修正がマイナーバージョンアップとして暫く続くからです。しかし、ある程度時間が経過して落ち着いたバージョンをインストールしても、やはり予想できない問題が出てきてます。
Laravel 5.7の更新を終えて、次は最新の5.8への更新です。こちらも私が経験したことをもとに、いくつかの重要な更新箇所をここで説明です。
Laravel5.7に更新したら、会員登録時にEメール確認リンクを送信する新機能が追加されました。設定は簡単です。
Laravelは一昨年あたりから細目に更新を出すようになりました。と言っても、年に2回ですが、Laravelで書いた大きなプログラムを管理する私としてはそれでも「きつい」。それで長期サポートの5.5にあぐらをかいているわけだが、しかし。
最近、統計のプログラムが必要になり、Rというプログラミング言語を習得することになりました。ウェブのアプリの開発では、php, javascript, htmlなどがメインなゆえに、それを外れたプログラミング言語を使用する機会は少なく、興味も手伝って取り組んでみました。
私のあるプロジェクトにおいて、Laravelからエクセルを生成するプログラムがあります。DBからの値を整形してエクセルに流し込み、生成されたエクセルをウェブからダウンロードできるプログラムです。記録として残すため、あるいはそれを他のプログラムにインポートするために、エクセルを生成する必要があるわけなのですが、ちょっとしたややこしい問題がありました。今回はその解決方法を共有です。
まだまだLaravelのバージョン5.5から進まない私ですが、5.6以降のバージョン(最新は5.8)を使い始めて、いいと思った改善です。
前回において、理想のバリデーションの関数、rules()を作成できたところで、今回は、そのバリデーションチェックを通過した入力データをDBに保存するところを見てみます。
前回で披露したコントローラー中でのルールの共有のメソッドrules()では、新規レコード作成と既存レコードの編集における入力項目の違いを、$actionの引数をswitchで分岐して対応しました。今回は、sometimesを使用してそれらの必要性をなくします。