Laravel 5.1

La version 5.1 de Laravel est sortie. Quoi de neuf ?

Support sur le long terme

Vous êtes peut-être lassé de la fréquence de sortie des versions de Laravel et de la nécessité de se mettre à jour à cause de la rapide obsolescence  de la version que vous avez utilisée pour une application. Et bien soyez soulagé parce que la version 5.1 sera suivie sur le long terme. Voici ce qu’en a dit Taylor :

The last Symfony LTS release was Symfony 2.3 in June of 2013. Two years ago Laravel was not nearly the size it is today. It wasn’t really clear that Laravel would become as widely adopted as it has, thus the need for an LTS release wasn’t as obvious. It is now used by many more very large corporations.

Since Symfony 2.7 will be the next LTS release in May / June of this year, this is the first real opportunity to get on board with LTS releases in a few years, since we would not want do an LTS release without the underlying HttpFoundation component also having the same LTS support.

Vous êtes allergique à l’anglais ? Bon je vous en fais une petite traduction (bon désolé pour les linguistes c’est approximatif) :

La dernière version de Symfony LTS était Symfony 2.3 en Juin 2013. Il y a deux ans Laravel n’avait pas la taille qu’il a aujourd’hui. Ce ne fut pas vraiment clair que Laravel deviendrait aussi largement adopté, donc le besoin d’une version LTS n’était pas aussi évident. Il est maintenant utilisé par beaucoup de très grandes entreprises.

Etant donné que Symfony 2.7 sera la prochaine version LTS en Mai / Juin de cette année, ceci est la première véritable occasion de monter à bord avec les versions LTS, car nous ne voulons pas faire une version LTS sans la composante de HttpFoundation sous-jacente aussi ayant le même support LTS.

On voit bien la dépendance entre Laravel et Symfony avec cette citation. Le résultat est que désormais Laravel pourra être utilisé de façon plus sereine grâce à ce support sur le long terme !

Les commandes

Avec la version 5 de Laravel sont apparues les commandes dans le dossier app/Commands. Ce dossier va disparaître au profit de app/Jobs :

img01

Quel intérêt de changer ce nom ? Sans doute pour mieux indiquer que la raison première de ces commandes, ou plutôt « travaux », est d’être utilisées dans une file de travaux (queued jobs). Pour la mise à niveau il n’y aura aucun souci, il suffira de transférer les commandes existantes dans ce dossier.

Injection de service dans Blade

Une nouvelle possibilité dans Blade consiste à pouvoir injecter un service avec la directive @inject. cette directive attend deux paramètres :

  • le nom de la variable qui va référencer le service,
  • le nom de la classe ou de l’interface que l’on veut instancier.

On va pouvoir donc écrire ce genre de code :

@inject('maths', 'App\Services\Maths')
...
Montant: {{ $maths->calcul($value) }}.

Jusque là il fallait tout envoyer dans les vues, on va maintenant pouvoir effectuer certains traitements, à condition évidemment de se limiter à de l’affichage et de ne pas effectuer ici des traitement qui n’ont pas leur place.Paramètre de middleware

Voilà une fonctionnalité plutôt attendue et il y a eu de nombreuses questions sur les forums à ce sujet. Comment cela va se présenter ? prenons un exemple dans une route  :

Route::get('post', [
    'uses' => 'PostController@post',
    'middleware' => 'redac:post'
]);

J’ai une route et je veux filtrer les rédacteurs, mais uniquement ceux qui sont affectés aux articles. Ici je transmet le paramètre post au middleware. Je peux ainsi le récupérer dans le middleware :

public function handle($request, Closure $next, $redac)
{
	$user = $request->user();

	if ($user && $user->isRedac($redac))
	{
		return $next($request);
	}
	return new RedirectResponse(url('/'));
}

Plutôt pratique !

Diffusion des événements

Laravel est bien équipé en gestion des événements mais la version 5.1 va encore plus loin. On va pouvoir désormais diffuser les événements vers Javascript. Taylor a fait une vidéo sur le sujet alors je vous propose tout simplement de la visionner pour prendre connaissance de cette nouvelle fonctionnalité.

Exception CSRF

Voilà encore un sujet qui a fait couler pas mal d’encre (virtuelle). La version 5 a vu l’arrviée d el’application systématique d ela protection CRSF et les demandes se sont faites nombreuses pour éviter cette protection, principalement pour des API. De nombreux bricolages ont été proposés mais désormais on va avoir une méthode simple et efficace pour le faire.

Un tableau des urls à exclure est prévu dans le middleware :

<?php namespace App\Http\Middleware;

use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as BaseVerifier;

class VerifyCsrfToken extends BaseVerifier
{
    /**
     * The URIs that should be excluded from CSRF verification.
     *
     * @var array
     */
    protected $except = [
        'posts/*',
    ];
}

Il suffit donc de lister toutes les urls qui ne doivent pas subir la protection CSRF dans ce tableau.

J’avais proposé une solution bricolée dans ce goût là sur le forum de Laracasts.

L’authentification

Les vues et les routes pour l’authentification vont disparaître. Donc une installation fraîche de laravel 5.1 comportera seulement la page d’accueil. Par contre toute l’intendance sera présente. Pour retrouver ce qui était présent dans la version 5.0 j’ai créé un package que je décris dans cet article.

La documentation

Taylor a accompli un gros travail au niveau de la documentation. Allez par exemple voir celle des collections !

La mise à niveau

La mise à niveau à partir d’une version 5.0 se fera sans douleur. Il y a un guide bien fait ici.

Laisser un commentaire