This is contributed post for Computer Weekly Open Source Insider written by Max Gilbert in his capacity as software developer at Preston UK based web design agency Blue Wren – a firm that builds bespoke and hybrid software applications to tackle operational inefficiency.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In this part #1 of two posts, Gilbert looks at Laravel, a free and open source PHP web framework.
As a Laravel-advocate, Gilbert has contributed this piece to examine the upcoming Laravel update, discussing some of the most notable upgrades and the practical application and implications of these advancements.
Gilbert writes as follows…
Firstly, let’s look at custom validation rule objects. These are custom objects that can be used in controller validation, instead of using the Validator::extend() style custom rules.
It’s different to a Closure in that it is tidier, it lives in a separate class and it gives us the ability to do a clean declaration of both the passes and message functions separately; something that can look squashed and harder to read in a Closure.
They are used in Controller validation, so every piece of data that is being added to a system passes through Controllers and are validated on the way in. They will also allow for better code separation and the re-use of validation objects.
By being in a separate object, the same controller could make use of it several times without bulking out the controller, or the same lines of code being repeated. Complex validation logic is separated out, making for thinner, cleaner controllers, whilst maintaining control over data validation, as well as any necessary complexity that the validation requires.
These are the new, simpler way to do conditional logic in templates. The new if-directives allow for arguments to be passed, which means checks can be even more dynamic than before; previously, you would be required to write more code inside your AppServiceProvider boot method.
They can be applied across the board, for things like hiding links from non-administrators to embedding HotJar tracking codes. They also mean that there is no need to write a directive for both the start and end anymore.
It offers the flexibility of being able to do easy if-else-ends for any number of custom if-checks and allows for convenient abstraction of what would normally be repetitive checks inside templates. This helps hugely with the code’s readability.
Die dump (DD) and dump for collections
DD and Dump are two of a Laravel Dev’s best friends.
They allow you to dump out the result and kill execution, often essential when debugging. An example of where this could be applied would be if you were mapping over an array of values, reducing them by 10%, before piping them into a reject filter.
The update means that you could dump them out to ensure that the original values are now 10% less than what they were before.
Until 5.5 it has often been tricky to work out the result of Collection after it has been through a few filters.
With 5.5, you will be able to dump or die dump the result, after it’s being through a filter, giving you immediate visibility of the result.
This means there will be more visibility of variables, when they have been through a filter, and presents a greater ease of debugging.
The return of Whoops
Whoops is a PHP error handler framework that came with earlier versions of Laravel (circa 4.2). It got removed around version 5, but the team at Laravel have announced that it will be making a return in 5.5.
This news is great for developers as Whoops is almost omnipotent.
No matter where you make your error, Whoops will catch it upon execution and serve a big, bold error to the screen. Whoops gives better, more verbose errors and even points you to the code that has caused it. It also has nice styling and is currently stand alone, so doesn’t require any other library to work.
Laravel ships with a range of pre-defined components – like headers, footers, buttons and tables – which are handy for dropping into email templates. In 5.4, emails can be sent with a default theme which can be overridden by generating your own theme and placing it in the correct folder path. Laravel 5.5, on the other hand, has made this much more flexible by allowing you to define a theme property on any mailable class, and the respective style sheet will be used for that email.
For example, if you wanted one set of branding for customers and another for emails that go to administrators, 5.5 would facilitate this. It gives greater flexibility on email styling, and allows you to have one theme for each mailable class, if you were that way inclined.
Laravel 5.5 also offers some huge advantages when it comes to testing email templates. Previously, this has been a bit of a headache and required the use of costly services, like Litmus, for testing how emails will render for different clients. In 5.5, you can now render email templates directly from a route, making debugging of email templates much quicker and easier than ever before.
Speed and ease of use seem central to Laravel 5.5’s features, but above is just half the story. We continue to delve into the imminent release in our follow up article (LINKED HERE), discussing each of the remaining and notable features, considering the advantages and their application.