Software-update: Laravel 5.4

Laravel is een opensource PHP-framework waarmee webapplicaties volgens het model-view-controller-ontwerppatroon kunnen worden ontwikkeld. Achter Laravel staat een uitgebreide community en er is uitgebreide documentatie. Niet voor niets is het naast Symfony en Yii een van de meest populaire PHP-frameworks van dit moment. Eerder deze week is versie 5.4 van Laravel uitgekomen en de release notes daarvan zien er als volgt uit:

Laravel Dusk

Laravel Dusk is an end-to-end browser testing tool for JavaScript enabled applications. It aims to provide the right way to do page interaction tests, so you can use Dusk for things like click buttons/links, forms, as well as drag and drop!

Dusk utilizes the ChromeDriver and the Facebook Php-webdriver for tests. It can work with any Selenium browser, but comes with ChromeDriver by default which will save you from installing a JDK or Selenium.

Dusk is very easy to use without setting up Selenium and starting the server every time.

Laravel Mix

Laravel Mix is the next generation of Elixir. It is built with webpack, instead of Gulp. It was renamed because of the significant changes.

Unless you customized your Elixir setup, moving to Mix shouldn’t be a problem and Laracasts has a video covering this updated tool.

Blade Components and Slots

Components and Slots are designed to give you even more flexibility in your Blade templates. As an example, imagine you have an include template that is used for showing an alert:

// alert.blade.php
<div class="alert">
    {{ $slot }}
</div>

Then, in your template file you can include it like this:

@component('inc.alert')
    This is the alert message here.
@endcomponent

Markdown Emails

Laravel 5.3 introduced two new features around email, Mailables and Notifications which allow you to send the same message through email, SMS, and other channels.

Building on top of these improvements, Laravel 5.4 includes a brand new Markdown system for creating email templates.

Under the hood, this feature implements the Parsedown parser with its companion, Markdown Extra so you can use tables.

@component('mail:message')
# Thank You
Thank you for purchasing from our store. 
@component('mail::button', ['url' => $actionUrl, 'color' => $color])
{{ $actionText }}
@endcomponent
@endcomponent

Automatic Facades

You can now use any class as a Facade on the fly. Here is an example:

namespace App;
class Zonda 
{
    public function zurf()
    {
        return ‘Zurfing’;
    }
}

Then, in your routes or controller:

use Facades\ {
    App\Zonda
};

Route::get('/', function () {
    return Zonda::zurf();
});

Route Improvements

Another new feature is the ability to use fluent syntax to define a named route or a middleware:

Route::name('profile')->get('user/{id}/profile', function ($id) {
    // some closure action...
});
Route::name('users.index')->middleware('auth')->get('users', function () {
    // some closure action...
});
Route::middleware('auth')->prefix('api')->group(function () {
    // register some routes...
});
Route::middleware('auth')->resource('photo', 'PhotoController');

The route caching layer also received improvements which will allow route matching on very large applications to see a significant enhancement.

Higher Order Messaging for Collections

The best way of showcasing this new feature is through code samples. Pretend you have a collection, and you want to perform an operation on each of the items:

$invoices->each(function($invoice) {
    $invoice->pay();
});

Can now become:

$invoices->each->pay();

More New Features

Some other changes and improvements include the following:

• New retry helper
• New array_wrap helper
• Added a default 503 error page
• Switched to the ::class notation through the core.
• Added names to password reset routes
• Support for PhpRedis
• Added IPv4 and IPv6 validators
• date_format validation is now more precise

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Versienummer	5.4
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Laravel
Download	https://laravel.com/docs/5.4/installation
Licentietype	GPL

Reacties (24)

Uch, die routes vind ik zo'n omslachtige oplossing. Ik gebruik een bestandssysteemgebaseerde manier om de controllers aan te roepen in combinatie met overlays van extra modules / plugins. Hoef je maar op één plek code aan te passen om nieuwe routes toe te voegen of te wijzigen in plaats van op twee plekken.

En bij:

$invoices->each(function($invoice) {
$invoice->pay();
});

vraag ik me af waarom je niet gewoon

foreach ($invoice as $inv)
$inv->pay();

zou doen. Waar is die extra functie-aanroep dan weer voor nodig? Dat $invoices->each->pay() lijkt in ieder geval wel alsof ze heel hard proberen een functionele taal van een OOP / imperatieve taal te maken. Not my cup of tea.

Elke keer als ik dit voor bij zie komen denk ik bij me zelf ik moet dit echt eens gaan leren.
Alleen voor iemand die zijn coding skills van CodeCademy heeft is dat best een drempel.

Als je Laravel wil leren raad ik je aan om te beginnen met de fundamentals serie op Laracasts: https://laracasts.com/series/laravel-5-fundamentals Alles wordt duidelijk uitgelegd door middel van goede voorbeelden.

Hiermee ben ik ook begonnen en ik gebruik tegenwoordig Laravel voor vrijwel alle PHP projecten.

Sowieso is de laracasts website aan te raden. Staan erg informatieve tutorials op, niet alleen voor Laravel, maar bijv. ook voor Vue2 en ES6.

Bedankt voor de tip ik wist nog niet van het bestaan van deze website. Echter zal ik eerst OOP moeten leren voordat ik met Laravel kan werken.

Ik denk dat je tegenwoordig beter deze kunt bekijken: https://laracasts.com/series/laravel-5-from-scratch. Die gaat over Laravel 5.2, jou link is nog de 2015 editie over Laravel 5.0.

Vooral zelf uitproberen, daar leer je het meeste mee.

Heb je al enig ervaring met OOP (in PHP)? Zo niet dan is het slim om dat eerst te doen. Ook is het slim om een beetje bekend te worden met het MVC patroon, dit wordt namelijk veel gebruikt!

Nee bijde nog niet weet wat het inhoud en wat het is maar kan het niet. Dat is ook de grootste drempel.

Ik ben uiteindelijk na jaren pure php ingestapt bij Laravel 5.x en ik kan je vertellen dat ik er geen spijt van heb gekregen. Vroeger maakte ik bij elke opdracht mijn componenten toch weer ietsje beter waardoor versie beheer een drama werd. Dingen aanpassen in een oudere Website kwam uiteindelijk neer op opnieuw bouwen van hele componenten.

Nu in Laravel is het allemaal een stuk makkelijk geworden. Composer, Gulp en Bower horen er gewoon bij en hebben mijn leven als programmeur een stuk makkelijker gemaakt. Laravel zelf upgraden is een eitje met de aanwezige documentatie en als de stap te groot wordt dan is een nieuwe Laravel installatie in een paar uur weer voorzien van de oudere bestaande en aangepaste custom componenten waardoor de Website weer in de laatste versie van Laravel werkt.

Voor mij was het gewoon beginnen met een eerste opdracht en leren terwijl je bouwt. Natuurlijk doe je de tweede en derde opdracht weer net iets anders omdat je steeds meer gebruik maakt van de beschikbare functies binnen Laravel. Als je werkt zoals ik dan pas je de oudere websites direct weer aan aan je nieuwe 'standaard'. Kost in het begin even tijd maar gaandeweg zul je merken dat je steeds netter werkt en het uiteindelijker een stuk minder tijd kost om een Website te bouwen.

Gewoon beginnen dus!

Wat mij altijd dubbele gevoelens geeft bij dergelijke frameworks is het feit dat ze na verloop van tijd allemaal op hetzelfde punt uitkomen; extreem generieke toepassing. Dus in plaats van specialisatie groeit de core steeds verder uit met zeer brede additionele functionaliteit.

Waar is de tijd gebleven waarin programmeurs 64kb systeemgeheugen hadden en daarom creatief leerde nadenken om resultaat te boeken? Het is fantastisch dat computerkracht blijft groeien, maar dit soort frameworks zijn niet bepaald zuinig in hun omgang hiermee. Neem bijvoorbeeld het IO verkwisten met grote boomstructuren van includes. De vaak ontbrekende cachelagen om dit te verzachten, en het gebrek aan werkelijk modulaire blokken welke naar keus inbegrepen of weggelaten kunnen worden om het uiteindelijke doel zo efficiënt mogelijk te behalen.

Ik begrijp security, performance en gebruikersgemak.. maar developersgemak? Tot op zekere hoogte. IT is vakmanschap. Een goed eindproduct is belangrijker. Developersgemak gaat hier altijd ten kosten van.

Grappig, ik hoor dit argument ook regelmatig. Maar dan van mensen die qua coding nog in 1999 leven. Ze zien een framework dan als een bedreiging van hun 'specialisme', terwijl een framework juist de basis kan leggen voor betere en complexere projecten.

Ik zou er eerlijk gezegd niet aan moeten denken om een project van iemand over te nemen die op elke byte bezuinigd heeft . We leven in een tijd dat het een minder groot issue is, dus laten we ons dan vooral richten op een betere gebruikerservaring dan om te bezuinigen op zoveel mogelijk CPU cycles.

Het moet in balans zijn. Niet volledig de ene kant op, koste wat kost elke byte besparen, maar ook niet de andere kant op: och CPU cycles/RAM/opslagruimte genoeg, dus doe maar lekker inefficiënt.

Wat ik veel bij frameworks zie is dat ze eenvoudige stukjes native code gaan herimplementeren op een net andere manier. Zoals in dit voorbeeld de each-loop. Daar hebben we native foreach al voor. Maar nu wordt er een "magic method" __get aan toegevoegd van een proxy-object om willekeurige functies op elementen in collecties aan te roepen. Netto besparing, een paar karakters misschien. Wel veel CPU cycles verspild. Leesbaarder? Nah. Hoogstens functioneler, maar als je functioneel wilt programmeren kun je beter naar Ruby, Haskell of Lisp gaan.

Wat wél een grote meerwaarde is van softwarebibliotheken is als ze protocollen (communicatie, encryptie, bestandsformaten) implementeren. Daar komen vaak complexe specificaties aan te pas en dan is het fijn als je dat achterwege kunt laten en pre-made libraries kunt gebruiken. Vermijdt je ook gelijk alle bugs en bijbehorende veiligheidsrisico's.

Jouw reactie had ik inderdaad verwacht. Ik begrijp je punt. Toch is mijn bedoeling niet om specialisme te beschermen, maar juist specialisme te stimuleren. Naarmate IT in onze samenleving exponentieel blijft groeien is het meer dan ooit tevoren belangrijk dat men er bewust mee omgaat. Het dalende expertise niveau kan grote gevolgen hebben voor alle eindgebruikers.

Ik ben misschien een programmeur van de vorige eeuw, maar ik vind dat iedere programmeur in staat moet zijn om zo efficiënt mogelijke code te schrijven, zonder enig framework. Zeker als je voor relatief simpele hardware moet schrijven kan je heel wat snelheid winnen.
Klakkeloos gelijk een framework pakken voor om het even wel project is geen goede zaak, maar gebeurt wel vaak. Per project zou je je af moeten vragen of je wel een framework nodig hebt.
Ik ben nu ook met laravel begonnen voor wat ingewikkelder werk. Het heeft zeker voordelen, maar het framework is zo groot dat je niet eens 10% van het geheel gebruikt. Dat het zo uitgebreid is heeft natuurlijk ook voordelen. Andere frameworks zijn lang niet zo compleet en als je dan net functies nodig hebt die er niet in zitten, geeft het wel veel extra werk.

Je kunt in je config file vrij eenvoudig service providers uitschakelen waardoor je een groot deel van die 90% helemaal niet meer als balast meeneemt. Je zou zelfs al die code kunnen verwijderen.

Klopt, maar in de praktijk wordt dat niet veel gedaan. Overbodige code verwijderen is riskant. Wie weet heb je die later toch nodig.

Mee eens! Uiteindelijk zijn de framework de tools om eenheid binnen een organisatie te creëren. Maar ik weet als geen ander dat een framework goed gebruiken veel meer ervaring kost dan enkel een manual of tutorial doorlezen.

Ik zou er echt niet aan moeten denken om van al mijn collega's hun zelf bedachte en meestal slecht gedocumenteerde componenten te moeten onderhouden. Het framework is dan noodzakelijk om eenheid in het geheel te kunnen krijgen. Helemaal in een tijd waarbij elk uurtje toch ook geld voor de klant betekend.

developersgemak = snelheid = geld. En dat is bij 90% van de klanten belangrijker dan een 'goed' eindproduct (ja het moet goed zijn, natuurlijk... maar mag max xx kosten, is de meest gehoorde insteek van random klant..)

Klopt. Toch is het een beroep waarbij veel voor de eindgebruiker 'verborgen' blijft en er bij de eindgebruiker soms simpelweg geen kennis is. Het is aan de leverancier om te informeren en adviseren. Soms slaat het balans te ver door naar de klant denk ik. Dit kan heel nadelig zijn.

Ik snap het gebruik van een template engine in een PHP-framework nooit zo goed. PHP IS een template engine. Dus om een template engine in een template engine te bouwen, vind ik nogal vreemd en nadelig voor de performance. Het enige voordeel wat ik zie is dat je jezelf forceert om geen businesslogica in templates toe te passen, maar dat is een kwestie van het jezelf gewoon goed aanleren.

Het gaat vooral om de leesbaarheid in de template files. Blade is een stuk leesbaarder dan direct PHP in een bestand te plaatsen.

In templates moet je code simpel zijn, anders doe je teveel in het template wat feitelijk elders zou moeten gebeuren. Conditionals en loops zijn in PHP een piece of cake. Combineer dat met wat eenvoudige formatting functies en includes van deel-templates en je bent voorzien. Wat ik in de voorbeelden zie is vooral een andere manier van hetzelfde opschrijven, waarmee je dus extra syntax moet leren. PHP voldoet prima als template engine, dat ben ik volledig met Bas_f eens!

Exact. Ik ben daarom zelf erg gecharmeerd van Yii2. Standaard geen eigen template taal, gewoon PHP. En inderdaad, als je wilt kun je daar een hele site in bouwen. Maar dat is een kwestie van discipline.

Blade is misschien niet een goed voorbeeld omdat de Syntax wat eigenaardig, ik heb van verschillende Laravel gebruikers gehoord dat ze er ook niet altijd even positief over zijn, en liever met Twig werken (kan overigens wel).

Een groot voordeel van Twig is auto-escaping zodat je niet voor elke "echo" een filter moet gebruiken om XSS te voorkomen. Daarnaast is de Syntax veel korter en gebruikersvriendelijker dan PHP voor templates. Mede omdat Twig op jinja (Python) gebaseerd is.

En het snelheidsverschil ten opzichte van PHP is echt minimaal, Twig compileert de template naar PHP, en sinds versie v1.30 word zoveel mogelijk aan lazy-loading gedaan waardoor de snelheid nu nog beter is.

Kijk http://twig.sensiolabs.org/, en probeer https://twigfiddle.com/ zelf.

Een goede template taal voelt natuurlijk, is consistent en kan binnen enkele minuten worden geleerd.
Vooral als je met designers werkt, als ze PHP moeten leren zonder daarbij de echte kennis van PHP te beheren, dan heb je binnen no time een onleesbare brij.

PHP IS een template engine.

PHP was van oorsprong een template taal maar inmiddels zijn we veel verder, JavaScript was bedoeld voor browsers en nu kan je een complete stack ermee draaien.

Ps. Twig ondersteund ook een sandbox modus erg handig voor custom themes zonder risico op veiligheidsproblemen.