Warning: This post is over a year old. I don't always update old posts with new information, so some of this information may be out of date.

Laravel 5.0

Laravel 5.0 is coming out in November, and there are a lot of features that have folks excited. The New Directory structure is, in my mind, a lot more in line with how most developers work; Flysystem integration will make working with files endlessly more flexible and powerful; Contracts is a great step towards making Laravel-friendly packages that aren’t Laravel-dependent; and Socialite looks about 100x easier than Opauth. Also, Method Injection opens up a lot of really exciting opportunities.

One of the most valuable aspects of Laravel for me is that it allows for rapid app development. Laravel, and other frameworks like it, automate out the repetitive work that you have to do on every project. And a lot of newer features have been focusing on this. Cashier, and now Socialite and Form Requests.

The headache of form validation

If you have ever tried to figure out the best practices for validation in Laravel, you’ll know that it’s a topic of much discussion and little agreement. Validate in the controller? In a service layer? In the model? In a custom validation wrapper? In Javascript (NO JUST KIDDING THAT’S NEVER OK)?

Laravel’s new Form Request feature provides both standardization (“best practice” ish) and also convenience (this is more powerful and convenient then all prior options) to the process of validating and authenticating in Laravel.

NOTE: In this post I'm using the new view() helper instead of View::make().

Form Requests to the rescue

Laravel 5.0 introduces Form Requests, which are a special type of class devoted to validating and authorizing form submissions. Each class contains at least a rules() method which returns an array of rules and an authorize() method which returns a boolean of whether or not the user is authorized to perform their request.

Laravel then automatically passes the user's input into the request before parse through the POST route, meaning our validation can now be moved entirely into FormRequest objects and out of our controllers and models.

Getting started: Spin up a Laravel 5.0 project

If you don't have one yet, create a 5.0 project using the following command:

Now, spin up a server with php artisan serve or your favorite method. Submit the form and you can see our validation rules working without adding a line of validation logic to our controllers.

Other use cases

What about if we have different rules based on add vs. edit? What if we have conditional authorization based on the input? Here are a few examples, although we haven't yet established "best practices" on all of these.

Separate form requests

There's nothing stopping you from having two (or more) separate form request classes for add and edit. You could create FriendFormRequest with all the rules, and then extend it to make addFriendFormRequest or editFriendFormRequest or whatever else, and each child class can modify the default behavior.

Conditional logic

The benefit of rules() being a function instead of just a property is that you can perform logic in rules().