A Week with Laravel 5: What’s New

A Week with Laravel 5: What’s New

   7 Comments   
http://bit.ly/1Fl5mbb

With a PHP project we have just started, we decided to begin development with the Laravel 5 framework – even before it’s been released. The framework is due to be released this month (Jan 2015) and instead of starting with Laravel 4 and attempting to migrate upwards, it seems natural to begin with the newest version even though it’s features might change slightly pre-release.

Being comfortable developing with both PHP and Laravel 4, some of the changes with version 5 seemed quite major. Here’s a list of changes which I’ve come across after working with Laravel 5 for just 1 week, my first week. This isn’t a changelog of each feature (here is a changelog), so there will be new bits missing and opinion will creep into a few statements.


Folder Structure

This has to be the first thing we talk about. As soon as you pull down Laravel 5 the new folder structure hits you square in the jaw. It took me a while to work out where everything went.

Initial thoughts:
  • I would have liked a Models folder as standard instead of leaving the in the app folder.
  • I couldn’t find the controllers folder.
  • Don’t initially understand the difference between providers and services.
  • Don’t undertand the difference between console and command.
Thoughts after a week:
  • I moved the models into a folder and namespaced them which kept me happy.
  • I actually really like controllers being under the http folder.
  • Really liked resources/assets being outside of public.

Requests

With Laravel 4, you have a form in your Blade template which will post data to your controller. Your controller then validates the data and acts accordingly. With Laravel 5 however, this process is slightly different. Your form will still post to a controller but the first parameter in the method is a Request class. This Request class validates your data, before it hits your controller – this means that your method in the controller does one thing, not two.

Initial thoughts:
  • How do I get it to return errors to the form? (fyi, it does it by default).
Thoughts after a week:
  • Excellent – clean controllers, super validation, robust code.

Namespacing

I would often employ namespacing on Laravel 4 anyway, so having this setup by default was a nice change. It means that your models, controllers and classes are all separated into different sections – so can have a class with the same name, if needs be. Once you’ve set up your app, you can run php artisan app:name MyAppName to setup your global namespace throughout.

Initial thoughts:
  • Yes! Excellent News
Thoughts after a week:
  • So many use statements at the top of your classes and long class statements in your views.
  • Why do I keep forgetting the backslash (\) from the start of the frameworks classes, e.g. \Auth::user().

Elixir/Gulp

Laravel 5 now comes with elixir, a task-runner for front-end development, by default. This will take any less/sass files you have in your resources folder and compile them into a single minified css file in the public folder. Front-end developers have been doing this for a while – what’s special is that it’s there be default.

Initial thoughts:
  • Another thing to learn – sigh (I usually use grunt).
  • What the heck’s Elixir?
Thoughts after a week:
  • Really easy to setup.
  • Couldn’t quite get it working right with my JavaScript and .scriptsIn().

Environment Variables

New install of Laravel, I went straight to the database config file. I’m used to this as lots of frameworks work in this way. Environment variables are quite a bit cleaner though – and safer as the .env file shouldn’t be commited to your repository.

Initial thoughts:
  • Very pleased there’s a .env.example file as standard.
Thoughts after a week:
  • Why don’t most frameworks work this way?

Less static methods

Laravel has always had a reputation for using lots of static methods and simple class names. For example Redirect::back() and View::make(). Now, the Laravel 5 way of doing these is to use the simple functions, redirect()->back() and view(''). I actually really like static methods, so I was a little disappointed, until I worked with what they’ve become – and I quite like these little functions.

Initial thoughts: Thoughts after a week:
  • They’re basically the same, I’m used to them now.
  • For some reason I think they look a little ameatur-ish without a class.

Artisan Serve

This is a controversial one… I was a user of the php artisan serve command. Developing on linux anyway, I found it a similar environment to using a vagrant box, with less precious resources being sucked away by having a virtual operating system running.

Edit 20th Jan ’14: Serve has been added back in.

Initial thoughts:
  • Do I really have to use vagrant now?
  • Like really?
Thoughts after a week:
  • No, I just started using php -S localhost:8000 -t public/ instead.

Have you used Laravel 5 yet? Let us know in the comments.

7 responses to “A Week with Laravel 5: What’s New

  1. I think by using lots of static methods, already become a characteristic for Laravel itself, looks more ‘pretty’ code. So I agree with you that with new way like ‘redirect()->back()‘ and ‘view()‘ they look a little ameatur-ish without a class.

    1. Ye, thanks for the comment Aldo. One good/bad thing about the function equivalents its that they’re not namespaced, so they actually cut out quite a bit of code — it just feels un-natural. I thought at the time, that the classes had been replaced by the functions but I think all the classes (Laravel 4 style) are still there and work fine, so it’s down to preference now.

  2. The static calls actually map to public functions or object instances under the hood, Taylor has also proven it to be unit test compliant so I don’t think it’s a problem, just facade on!!!!!

Leave a Reply

Your email address will not be published. Required fields are marked *