Il est arrivé, il est tout chaud avec son lot de nouveautés de de nouvelles possibilités ! C’est la version 5.2 de notre framework préféré ! Dans cet article je vais faire le point des princuipales caractéristiques de cette version.

L’authentification

Le scaffold

C’est le grand retour du scaffold ! La version 5.0 avait vu la disparition des routes et vues pour l’authentification. Il y a eu de nombreuses discussions sur le sujet, des packages sotn apparus pour combler la lacune, comme par exemple le mien qui a connu un certain succès, ce qui prouve bien que c’était une suppression inopportune !

Et bien la version 5.2 arrive toujours sans le scaffold mais… il y a la commande d’artisan make:auth qui peut créer routes et vues… en gros tout ce qui est nécessaire pour s’enregistrer, se connecter, se déconnecter, récupérer un mot de passe…

Voyons ce que donne cette commande :

php artisan make:auth
Created View: \resources/views/auth/login.blade.php
Created View: \resources/views/auth/register.blade.php
Created View: \resources/views/auth/passwords/email.blade.php
Created View: \resources/views/auth/passwords/reset.blade.php
Created View: \resources/views/auth/emails/password.blade.php
Created View: \resources/views/layouts/app.blade.php
Created View: \resources/views/home.blade.php
Created View: \resources/views/welcome.blade.php
Installed HomeController.
Updated Routes File.
Authentication scaffolding generated successfully!

On voit que sont créées des vues, un contrôleur et des routes.

Voyons les vues :

• auth/login.blade.php : la vue de connexion
• auth/register.blade.php : la vue pour l’enregistrement
• auth/passwords/email.blade.php : la vue pour la demande de renouvellement du mot de passe
• auth/password/reset.blade.php : la vue pour le renouvellement du mot de passe
• auth/emails/password.blade.php : la vue pour le texte de l’email pour le renouvellement du mot de passe
• layouts/app.blade.php : le template
• home.blade.php : la vue pour les utilisateurs authentifiés
• welcome.blade.php : la vue pour les utilisateurs non authentifiés

Au niveau des routes on a ce groupe ajouté :

Route::group(['middleware' => 'web'], function () {
    Route::auth();

    Route::get('/home', 'HomeController@index');
});

je parle plus loin du middleware « web ». Pour le moment on va se contenter de comprendre ce Route::auth(). Cette simple commande a pour effet de générer toutes les routes pour l’authentification :

C’est comme si on écrivait toutes ces routes :

Route::get('login', 'Auth\AuthController@showLoginForm');
Route::post('login', 'Auth\AuthController@login');
Route::get('logout', 'Auth\AuthController@logout');

Route::get('register', 'Auth\AuthController@showRegistrationForm');
Route::post('register', 'Auth\AuthController@register');

Route::get('password/reset/{token?}', 'Auth\PasswordController@showResetForm');
Route::post('password/email', 'Auth\PasswordController@sendResetLinkEmail');
Route::post('password/reset', 'Auth\PasswordController@reset');

Voyons le contrôleur créé :

<?php

namespace App\Http\Controllers;

use App\Http\Requests;
use Illuminate\Http\Request;

class HomeController extends Controller
{
    /**
     * Create a new controller instance.
     *
     * @return void
     */
    public function __construct()
    {
        $this->middleware('auth');
    }

    /**
     * Show the application dashboard.
     *
     * @return \Illuminate\Http\Response
     */
    public function index()
    {
        return view('home');
    }
}

Rien de bien particulier là dedans…

Les vues générées n’ont rien d’extaordinaire :

Elle sont sobres et efficaces, on peut bien évidemment les changer pour les adapter à la charte graphique d’un site.

Les middlewares de groupe

Les middleware dans Laravel on connait ça depuis la version 5.0. Mais c’est quoi un middleware de groupe ? Ouvrez le fichier app/Http/Kernel.php :

<?php

namespace App\Http;

use Illuminate\Foundation\Http\Kernel as HttpKernel;

class Kernel extends HttpKernel
{
    /**
     * The application's global HTTP middleware stack.
     *
     * These middleware are run during every request to your application.
     *
     * @var array
     */
    protected $middleware = [
        \Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class,
    ];

    /**
     * The application's route middleware groups.
     *
     * @var array
     */
    protected $middlewareGroups = [
        'web' => [
            \App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
        ],

        'api' => [
            'throttle:60,1',
        ],
    ];

    /**
     * The application's route middleware.
     *
     * These middleware may be assigned to groups or used individually.
     *
     * @var array
     */
    protected $routeMiddleware = [
        'auth' => \App\Http\Middleware\Authenticate::class,
        'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
        'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
        'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class,
    ];
}

On trouve la nouvelle rubrique $middlewareGroups qui justement contient les nouveaux middlewares de groupe. La différence avec les autres middlewares est qu’on peut y définir de nombreux middlewares au lieu d’un seul.

On voit par exemple que pour le middleware « web » on a pas moins de 5 middlewares rassemblés qui regroupe les principales fonctionnalités dont on a besoin pour gérer un site :

• les cookies
• les sessions
• la protection CSRF

Jusqu’à la version 5.1 on avait systématiquement tout ça quelle que soit la route, maintenant on a le choix de le mettre ou pas. Mais il ne faut surtout pas l’oublier !

Si on regarde les routes on voit que lors de l’action qu’on a vue précédemment pour créer celles de l’authentification on se retrouve justement dans un groupe avec le middleware « web » :

Route::group(['middleware' => 'web'], function () {
    Route::auth();
    Route::get('/home', 'HomeController@index');
});

Mais alors à quoi sert l’autre middleware de groupe « api » ?

Comme son nom l’indique on va l’utiliser quand on construit une API. Ce middleware va limiter le nombre d’accès par unité de temps. L’objectif est d’éviter de se retrouver avec une quantité d’accès telle que notre application se retrouve à genoux.

Par défaut Laravel admet 60 accès par minutes et en cas de dépassement le délai d’attente est d’une minute pour pouvoir à nouveau accéder. Mais on peut changer ces valeurs en prévoyant des paramètres pour le middleware :

Route::group(['prefix' => 'api', 'middleware' => 'throttle:30,2'], function () {
    // Routes
});

Ici on limite le nombre d’accès à 30 par minute et le délai d’attente est de 2 minutes.

Validation des tableaux

Une autre nouveauté qui était très attendue est la simplification de la validation des tableaux. Il arrive souvent que dans un formulaire au ait un nombre non défini de contrôles que l’on peut créer dynamiquement côté client. Dans ce cas on utilise un tableau :

{!! Form::text('answers[]', $answer->answer, ['class' => 'form-control']) !!}

Ici j’ai nommé answer le tableau.

Avec Laravel 5.1 pour la validation on est obliger d’utiliser une boucle pour avroi les règles pour chaque élément du tableau :

$rules = [
    'question' => 'required|max:255|unique:polls'
];

$nbr = count($this->input('answers')) - 1;
foreach(range(0, $nbr) as $index) {
    $rules['answers.' . $index] = 'required|max:255';
}

Avec la version 5.2 c’est bien plus simple ! On peut utiliser un joker :

$rules = [
	'question' => 'required|max:255|unique:polls',
	'answers.*' => 'required|max:255'
];

Liaison implicite d’un modèle dans les routes

On pouvait déjà lier un modèle à une route mais pour ça il fallait le déclarer dans un provider (le RouteServiceProvider) :

$router->model('user', 'App\User');

Ensuite dès qu’apparaît un paramètre « user » dans une route Laravel sait qu’il doit générer le modèle correspondant :

Route::resource('user', 'UserController');

Et on récupère le modèle directement dans le contrôleur :

public function edit(User $user)
{
	// Traitement
}

Et bien maintenant on n’a même plus besoin de faire la déclaration !