A streamlined approach to Laravel validation

It has been while (almost two years) since I wrote an article here and I’ve decided to make my triumphant return with an article I never managed to get around to writing.

As the title may suggest, this article is about streamlining validation with Laravel. While the final aim is to explain and present you with a quick and simple abstracted validator that requires minimal code in the actual implementation stage, before we get there I will need to cover the usual methods of validation which are default validation, form request validation and model validation. So let’s start.

Default Validation

When I say default validation I’m referring to Laravels base validator with no packages or abstraction around it. If you’re unfamiliar with this or need a recap, check out the documentation here.

Lets take a look at the example used on the documentation.

As you can see this is relying on the usage of the ValidatesRequests trait which is used in the default Laravel controller, but what exactly does this method do? Let’s take a look.

There are some serious levels of abstraction here but let’s break this down into something you’d be more familiar with from previous versions of Laravel.

This approach is something that I have favoured since the days of Laravel 4.2. This approach actually covers the majority of the streamlining approach that I want to show you, simply by throwing an exception you’ve removed the need to manually check the status of the a validator every time you want to run one.

That being said, there are a couple of problems I have with this approach.

Firstly, while it’s nice to throw in an entire object representing the request and have the validator validate all input, it’s not something that you want to find yourself getting into the habit of. For a while now I’ve seen a lot of people using the $request->all() method when collecting user input, and while I’m aware that Laravel by default has some superb security and that a validator isn’t really doing anything that could be exploited by some malicious input, being lazy and just throwing handfuls of user input at parts of your application is a bad habit that you shouldn’t let yourself get into.

Secondly, this approach also requires that you define the rules for the validation in the controller, and while this isn’t really a security issue or a bad habit, you’ll find that later down the road when sifting through the controllers of a large application trying to find the definition of the validation rules you’ll wish that these were abstracted out.

In conclusion, Laravels default validation will suffice in a pinch, it’s good for getting started and rapid prototyping but it feels somewhat lazy and not very optimal, so lets move into the next one, form request validation.

Form Request Validation

Form request validation is a relatively new feature that was brought to us in Laravel 5.0, and while some of the underlying core code may have changed, the actual implementation and usage of this feature has remained somewhat static. If you’re unfamiliar with this approach or need a recap, check out the documentation here.

For a brief explanation of what exactly this is, let’s quote the documentation.

For more complex validation scenarios, you may wish to create a “form request”. Form requests are custom request classes that contain validation logic.

Essentially the idea behind this is that you have your own class that extends the Laravel  Request class, except this class is capable of defining rules so that it may be automatically validated.

While in theory this is a pretty cool approach, and while it does provide us with a level of abstraction so that we don’t have all of this validation code within our controllers, it does mean that we’re offloading the task of validating data to the HTTP layer, and don’t forget, that some of Laravels validation rules will actually communicate with the database, so now we have the HTTP layer communicating with the database before it even hits our controllers, which should realistically be the start of our logic. This is bad, bad bad bad!

By all means have a play with this feature, see what it’s like and get your own feel for it, but I highly recommend that you do not use this is an actual production application, clear definitions and responsibilities are important for maintaining your codebase and limiting the amount of work required to change and/or fix something in the future. If you have to use an out of the box solution, use Laravels default validation.

Now we go from the start of the lifecycle to near the end, while somehow still being as bad.

Model Validation

Model validation is something that’s not part of Laravels core, but instead something often provided by packages or implemented at a basic level by the developer working with the system.

The standard approach for model validation often has you create models that look like the following.

Nice and simple right? The rules are defined in your model and would be called automatically by events hooking into  Model::creating() or  Model::saving(). This approach doesn’t actually take into consideration one of Eloquents wonderful features, mutators. For example, when creating a  User model with Eloquent I will always create the following mutator.

If I were using this approach the validator would validate the hash of the password, rather than the actual password. The same goes for any other field that you may have a mutator for.

You may find yourself thinking

Hey, why can’t the validation on the model happen when a user calls fill()?

The answer is simple, because you shouldn’t be using the fill method, it’s lazy and when I see it used it’s either just having a whole mess of user input thrown into it (Usually from  $request->all()) or it’s through so many levels of abstraction that I genuinely have no idea what it is actually saving to the model.

Another thing to consider is that like the structure of your response, user input can quite often be totally different to how the data is stored. Maybe the user is submitting one form, but this data actually creates two maybe three models, that’s two or three separate instances of validation there, rather than the one that should be. If you believe there should be that many, remember that the validation of data (user input) has very little to do with the storage of the data. This actually brings us quite nicely to my final point about this approach.

YOUR PERSISTENCE LAYER SHOULD NOT BE RESPONSIBLE FOR VALIDATING DATA. Feel free to reread that a couple of times and let it settle in.

Got that? Well have another few more reads of it to make sure that we’re on the same page.

For those of you that are curious as to what a “persistence layer” is, the persistence layer is where data is persisted, typically this will be in a database but we’re in a place now where databases are not that only way to store data. This layer is sometimes called the “data layer”, “datastore layer” or “database layer”. The naming isn’t important, what is important is what it does.

This layers job is basically to take data and persist it, whether that means throwing it an API, into a database, datastore, whatever, that is its sole job, retrieving and saving data. Validating data is a logic step, and can be considered business and/or application logic (I’m not getting into the argument of definition) so it belongs somewhere else.

Just like the response layer or view layer has its own specific logic often referred to as “display logic” this layer has its own level of “data logic” which I think is a name that confuses a lot of people and leads to this. The logic that happens in this layer is specific to the storage of the data and/or the communication with the datastore. It doesn’t and shouldn’t care how valid or invalid the contents actually is.

Do not play with, use or contemplate this approach. While it sounds nice on paper, and it may “make your life easier” you’ll regret it in the long run, and you’ll find yourself getting into bad habits. I don’t know why I dislike this approach more than form requests, but I do.

FINALLY we’ve made it all the way through to the part you’ve all been waiting for, some of my wonderful code.

The streamlined approach

Now that we’ve covered Laravels default validation, form request validation and even the third party model validation let me show the fourth and final approach of the day. This approach combines the one good part of form requests with the streamline approach of default validation, but throws in some nice magic in a more optimal way that doesn’t involve encroaching into the territory of your other layers.

For our examples, lets create it for users. Now you’ve got your application setup, you have the following classes.

  • User (model/entity)
  • UserController
  • UserRepository

In the lifecycle of our example application here the data will go UserController -> UserRepository -> User. So where exactly do we perform the validation? Well, my approach sits in the UserController but realistically could even sit in the UserRepository if you so wish. It doesn’t add an extra step, but instead provides a fire and forget approach just like the default laravel validation.

For this approach, we’ll want to create ourselves a UserValidator.

As you can see, the implementation of this approach so far, is really simple. You extend a base class and just define your rules as you see fit. To actually use this class in your controller you would have a method like the following.

You may be able to figure out what’s going on here, but I’ll clarify for those of you that are still uncertain. Firstly I’m collecting the user input, and only the user input that I need before passing it along to a method within the validator, which will validate against matching rules and throw an exception if it fails. The final part of the validFor method corresponds directly to the defined list of rules within my validator.

Usually as a final step of the validation I like to add an automated response for a validation exception inside the render method of the Exceptions\Handler  class provided by Laravel.

I’m aware that the above error handler only works for non api/ajax calls but that’s not our concern right now. The idea behind it is that I don’t have to fanny around creating validation logic for every part of the application, I just simply define my rules and the small amount of work that I did on this at the start guarantees that my validation is as automated as can be with users being taken back to the form with the validation errors, allowing me to focus on the actual functionality.

That’s it for the implementation of the method, but now comes the fun bit, the creation of the BaseValidator  class.

To be honest with you, there’s not much I can explain about this that hasn’t already been or is covered by the docblocks.

It’s really quite simple, you have a class that represents the validation of an object/resource within your system, within there you define named rulesets such as create, update, login as well optionally creating messages for those rulesets following the Laravel validation message approach and keeping the structure the same as the defined rulesets. This then allows you to call a method with a validFor{ruleset}  structure and have the data validated and the user automatically returned if they messed it up.

It’s actually a really simple approach, it’s streamlined and relatively powerful, it combines the good points from the existing Laravel validation into a nice little approach that you can reuse as many times as you see fit.

I hope this helps some of you with your application development and hopefully my first article after almost two years break isn’t full of mistakes and unstructured ramblings (more so than normal).

Enabling Charitable Donations on Behalf of Open Source Projects

Now that I’ve managed to move away from working at home to working in a shared office space, I aim to separate and compartmentalise properly, allowing me to focus on some personal projects that I’ve managed to accumulate over the last few years.

As I mentioned in my previous article Office Space and Transitions, not only have I acquired the aforementioned office space, I’ve gone about setting up Ollie’s Lab as a way to slowly migrate towards an independent entity. One of the things I plan to do with this newly formed entity, is release applications and systems whether they’re open source, hosted or self hosted services. This article is about the first of these projects, a project which as of yet does not have a name (I find naming things to be a tricky task), but is a free service available to anyone, or at least will be soon.

Continue Reading…

My Laravel Toolkit

Image 2014-08-29 at 3.13.49 pm

So about a week or so ago I found myself started a few projects, some for clients and some personal. While I doing this I noticed that I was copying and pasting a lot of basic classes and configurations that I use in almost everyone of my projects, so I decided to create myself a toolkit to use with my projects. My choice was an annoying composer configuration connecting to private repositories, or just making it a public repository with a package on packagist, so naturally I went with the second option. You can find the package here, and the repository here.

As I stated above, the idea behind this was to provide myself with a simple toolkit for us in my projects, to save myself duplicating code and having the modify multiple files if I fix a bug or make improvements. That being said, it’s available for others to use should they wish for a basic toolkit, or would like a basis to build their own. With that in mind, I’ve decided to write this article with some further information regarding it.

Continue Reading…

Laravel Routes Like a Grown Up

routes

For those of you that frequent the Laravel irc channel on freenode, you may have been witness to a recurring conversation surrounding Laravel routing, namely, using http methods other than POST & GET, and the use of Route::controller() & Route::resource(). Well this article plans to cover those bases as well as some added fun regarding Laravel routes, that may help.

Continue Reading…

Minecraft Modding – Too Many God Damn Ores

tmgdo-thumbnail

This is just a quick post really about a small project I undertook a month or two ago.

The project was a very small utility minecraft mod. The idea stemmed from playing on a server with friends, I had started to notice that every time I went mining my inventory would be full of ores, which is pretty normal, but upon closer inspection I noticed that I had things like, 4 different kinds of copper and in some cases, 8 different kinds of tin. Now I know that some mods (Minefactory Reloaded I think?) have added in specific machines that facilitate the conversion of all these ores to one type, and the putting them through something like a macerator or pulveriser would convert them to the same thing (It wouldn’t, it’d convert them to the mods version, dependent on the machine), or you could just setup some ender bag + chest + automated system to convert them. The problem was, that once I got back to my home/base I had plenty of space for the ores, and they weren’t an issue, the annoying thing was having to frequently travel back because my inventory is full.

Continue Reading…

A Simplified Laravel ACL

User authentication is a huge part of web applications, with it being necessary in the majority of cases, on top of which, it’s usually the first part of any system that a developer will approach, or at least it should be. Laravel is a powerful, easy to use framework that provides you with the basic tools to create a simple ACL to suit your needs.

I am aware that there are many packages for Laravel that offer this functionality, but I find them often to be more complicated than necessary. In this article I will detail how to create a simple yet highly customisable ACL using the basic tools that Laravel ships with.

Continue Reading…

Viper – The open source backend for games

Recently I’ve been talking about a pet project of mine that came about at the end of 2013. That project is of course, Viper, an opensource API for game developers, built on top of Laravel.

Just a little pre-warning, at the bottom of this page is a link to a google form for feedback, I’d greatly appreciate it if you took a minute or two out of your day to fill it in, thanks in advance.

Continue Reading…

Choose a job you love, and you will never have to work a day in your life.

Many of you will have heard this quote before but for those who haven’t, it’s a quote from Confucius, a Chinese teacher, editor, politician, and philosopher of the Spring and Autumn period of Chinese history. That being said, the origin of this particular quote is not the topic of this post, but more the meaning and how I feel that more people could benefit from paying attention to this.

It’s quite likely that many of us in the tech industry already live by this whether or not it’s intentional or not. Like me, I imagine many of you do what you do because you enjoy it, I didn’t chose to be a PHP developer for monetary gain or anything other than the fact that I enjoy it, which means that there is a burning passion within me for what I do.

Continue Reading…

UK Based Freelancing, The Next Step.

For those of you that read my tweets and/or articles, you’ll be familiar with a recent post I wrote about the state of UK freelancing and how we don’t have a home on the web that we can call our own, a home that enables us to find projects and compete with other freelancers in a fair and unbiased way, other freelancers mind you, that are from the UK, so we’re not undercut by those who live in parts of the world where the price of living is lower, and in some cases, considerably lower. If you aren’t, you can read it here.

I’ve spoke to a fair few people about my idea, which includes a very brief Twitter conversation (about 4 tweets), with the UK country manager for Freelancer, who said the following:

Continue Reading…