このブログを開始してから、もうすでに1年以上。RawのSQLを書いてコードに埋め込む日常から、Eloquentを使用したORMのコードへと日常へと移行しています。Eloquentに関しても、ブログを書き始めた頃からは理解が深まり、洗練されたLaravelのコードを書けるようになってきたこの頃です。 １年前に書いた「マスアサインメントで一括取り込み」のトピックで、EloquentのModelのクラスの属性fillableとguardedの話、1年の経験で学んだことを含めてここでもう一度説明します。
ユーザーがアクセスするURLを理解して、必要な関数にマップするのがroutes.phpの基本的な仕事です。 それらのURLには、以下のようにいろいろな形があります。
Laravelには最初から利用可能なバリデーションルールが多数存在していますが、そのいくつかは実用にならなかったり、自分好みに挙動を変えたりしたいこともあります。 CustomValidator クラスは標準 Validator を継承していますので、これらを置き換えて上書きすることが可能です。 vendor/laravel/framework/src/Illuminate/Validation/Validator.php
カスタムバリデーションのクラスを追加するには、サービスプロバイダーで次のようにクラスを登録します。 追加するクラスの名前や位置はどのようなものでもかまいせん。ここでは、ディレクトリパス app/Services に CustomVaidator.phpを作成し、AppServiceProvider に登録することにします。
Laravelでは、routeに名前を付けることができます。いったいそれがどうした？と思いますが、これができることで便利なことが増えます。 まず、routeの名前の付け方から、
開発しているプログラムの機能が増えてくると、必然的に定義するrouteの数が増えてきます。特に、マルチ認証ともなると、関わるプレイヤーの分だけで倍増する可能性があります。
resourceを使い始めて、まず思うのは、いつもいつも index, store, create, edit, update, destroyの一式が必要というわけではないことです。
はじめまして。ブログ主筆khino氏と同じプロジェクトで仕事をしてます。 彼とは別テーマを平行して掲載しますので、これまで順番に読み進めていた方にはちょっと読みにくくなるかもしれませんが、ご容赦ください。 私の最初のテーマはカスタムバリデーションルールです。 このシリーズでは、Validatorファサードの基本的な使い方から始めて、より複雑なルールの定義の仕方や、laravel 5.2で追加された配列定義のカスタムバリデーションまで紹介する予定です。
私が開発・管理しているプロジェクトのひとつは、もともとは過去に人気があったCodeIgniterで書かれたもの。過去２年の間に、それをLaravelのバージョン４で書き直し、さらに更新して現在はLaravelのバージョン5.2となっています。 それゆえに、最初のLaravelを使っての書き換えは、Laravelを勉強しながらの書き換えで、知らないことが多く、Route::controllerを多用していました。
Laravel以前は、ほぼコードにSQL文を埋め込んでいたので、Eloquentよりクエリビルダーの方が馴染みあります。特に複数のDBテーブルをjoinした検索などには。 しかし、各Modelにおいてリレーションを定義していると、それを使用しないのがもったいないように思えてきます。 クエリビルダーでできることをEloquentではどうやるのか、興味ありありになってきました。
