Modern PHP Development with Laravel

I have been using Laravel for a few years now, I moved onto it from Codeigniter and its now my framework of choice and something I use whenever I get the chance.

I have found laravel to be very different to anything I have used previously, it has introduced me to various coding practices and design patterns that are completely unfamiliar to me. Despite being new concepts I have embraced them but I don't think I have fully understood them.
I know that loose coupling, separation of concerns, dependency injection and testing are good things but I just don't really use them.

I had a bit of an epiphany recently while implementing a flash messages feature described in a Laracasts lession. This involved creating a new class for setting flash messages and passing notifications around.

This can be achieved very easily by default in Laravel, for example I am currently doing the following

App::error(function(BBExceptionsFormValidationException $exception)
    return Redirect::back()->withInput()->withErrors($exception->getErrors());

This catches a validation exception which contains the form errors and redirects the user back to the previous page along with them in a flash message. The key bit is ->withErrors(), this passes whatever you want as a flash message available in the session errors key.

So why would you want to change this?

Thats the real question that I struggled with, the alternative consisted of 3 classes; a facade, service provider and the class doing all the work. This method doesn't even improve the code above, infact it makes it more complicated.

App::error(function(BBExceptionsFormValidationException $exception)
    Notification::error("Something wasn't right", $exception->getErrors());
    return Redirect::back()->withInput();

The benefits come when you start to think about testing your code and more importantly improving and changing behaviour.


Testing the first version is not easy, if I wanted to confirm that an error message gets displayed if there is a problem you need to test the whole thing, a form submission, validation failure and then check that the error is displayed. If this test then stops working where do you start looking, the routing, controller, validation or rules, the request response or the html that rendered the error?

The second version is easy, you can look at various parts of the system and confirm exactly where things fail. You can test that the Notification::error() method correctly accepts and stores a message and that its available through what ever getters are used, you can even mock the session class which handles flash messages and confirm that they are set.
You can also test it as a whole, setting a message and then fetching a page to confirm the error is rendered, all without messing with form submissions and triggering validation errors.

Future proofing

This is the other benefit. What if I change the form to submit data via ajax; putting the errors into a flash message for the next page load is no good, I need them immediately. With the existing system I would need to modify the exception handler and the way the requests are returned but by abstracting things I could use something like pusher to return errors.
It also allows me to hook in other things, what if I wanted to pass all errors to a logging system to see what problems people had? With the old method I would need to modify the exception handler again and then perhaps the auth handler to catch those errors, it becomes very messy.

This has been a really fun piece of code to implement, when I set out to build this I did so because Jeffrey Way "said so" so it must be good(!) but during the process I really came to understand why its good.