Cours pour apprendre à utiliser le framework Laravel 5.5

Vous devez dans un premier temps avoir une base de données. Laravel permet de gérer les bases de type MySQL, Postgres, SQLite et SQL Server. Je ferai tous les exemples avec MySQL mais le code sera aussi valable pour les autres types de bases.

Il faut indiquer où se trouve votre base, son nom, le nom de l'utilisateur et le mot de passe dans le fichier de configuration .env :

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

Ici nous avons les valeurs par défaut à l'installation de Laravel. Il faudra évidemment modifier ces valeurs selon votre contexte de développement et définir surtout le nom de la base, le nom de l'utilisateur et le mot de passe. Pour une installation de MySQL en local en général l'utilisateur est root et on n'a pas de mot de passe.

Nous avons déjà utilisé Artisan qui permet de faire beaucoup de choses, vous avez un aperçu des commandes en entrant :

php artisan

Vous avez une longue liste. Pour ce chapitre nous allons nous intéresser uniquement à celles qui concernent les migrations :

On dispose de six commandes :

• fresh : supprime toutes les tables et relance la migration (commande apparue avec la version 5.5) ;
• install : crée et informe la table de référence des migrations ;
• refresh : réinitialise et relance les migrations ;
• rollback : annule la dernière migration ;
• status : donne des informations sur les migrations.

Si vous regardez dans le dossier database/migrations il y a déjà deux migrations présentes :

• table users : c'est une migration de base pour créer une table des utilisateurs ;
• table password_resets : c'est une migration liée à la précédente qui permet de gérer le renouvellement des mots de passe en toute sécurité.

Puisque ces migrations sont présentes autant les utiliser pour nous entraîner.

Commencez par créer une base MySQL et informez .env, par exemple :

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel5
DB_USERNAME=root
DB_PASSWORD=

Lancez alors la commande install :

On se retrouve alors avec une table migrations dans la base avec cette structure :

Pour le moment cette table est vide, elle va se remplir au fil des migrations pour les garder en mémoire.

Si vous ouvrez le fichier database/migrations/2014_10_12_000000_create_users_table.php vous trouvez ce code :

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');
            $table->string('email')->unique();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('users');
    }
}

On dispose dans cette classe de deux fonctions :

• up : ici on a le code de création de la table et de ses colonnes ;
• down : ici on a le code de suppression de la table.

Pour lancer toutes les migrations on utilise la commande migrate :

On voit que les deux migrations présentes ont été exécutées et on trouve les deux tables dans la base :

Pour comprendre le lien entre migration et création de la table associée voici une illustration pour la table users :

La méthode timestamps permet la création des deux colonnes created_at et updated_at.

Pour annuler une migration on utilise la commande rollback :

Les méthodes down des migrations sont exécutées et les tables sont supprimées.

Pour annuler et relancer en une seule opération on utilise la commande refresh :

Pour éviter d'avoir à coder ces méthodes down, la version 5.5 a prévu la commande fresh qui supprime automatiquement les tables concernées.

Il existe une commande d'Artisan pour créer un squelette de migration :

La migration est créée dans le dossier :

Avec ce code de base :

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class Test extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        //
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        //
    }
}

Il faut ensuite compléter ce code selon vos besoins !

Le nom du fichier de migration commence par sa date de création, ce qui conditionne son positionnement dans la liste. L'élément important à prendre en compte est que l'ordre des migrations prend une grande importance lorsqu'on a des clés étrangères !

L'application d'exemple comporte de nombreuses migrations :

Pour le présent chapitre nous allons nous intéresser à la migration de la table contacts :

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;

class CreateContactsTable extends Migration {

  public function up()
  {
    Schema::create('contacts', function(Blueprint $table) {
      $table->increments('id');
      $table->timestamps();
      $table->string('name');
      $table->string('email');
      $table->text('message');
    });
  }

  public function down()
  {
    Schema::drop('contacts');
  }
}

Pour cette table on a :

• une colonne clé incrémentée id (increments) ;
• les colonnes created_at et updated_at créées par la méthode timestamps ;
• une colonne name de type varchar (string) ;
• une colonne email de type varchar (string) ;
• une colonne text de type text (text).

Lorsque vous lancez les migrations la table contacts est créée :

Cette table est destinée dans l'application à mémoriser les messages laissés par les visiteurs lorsqu'ils accèdent au formulaire avec cet item du menu :

Pour les contacts dans l'application il faut deux routes :

• une route pour envoyer le formulaire à l'utilisateur ;
• une route pour la validation du formulaire.

Si vous regardez dans le fichier routes/web.php vous trouvez cette ligne de code :

Route::resource('contacts', 'Front\ContactController', ['only' => ['create', 'store']]);

La méthode resource crée par défaut ces sept routes CRUD :

Il existe une commande d'Artisan pour créer un contrôleur qui digère directement toutes ces routes :

php artisan make:controller ContactController --resource

Je reviendrai sur ce point dans un chapitre ultérieur. Pour le moment notre contrôleur de contact se contentera de deux méthodes (create et store), c'est pour cette raison qu'on utilise le only dans la syntaxe de la route pour générer seulement les deux routes correspondantes. On aurait aussi pu détailler les deux routes :

Route::name('contacts.create')->get('contacts', 'Front\ContactController@create');
Route::name('contacts.store')->post('contacts', 'Front\ContactController@store');

Le contrôleur est rangé ici :

Avec ce code :

<?php

namespace App\Http\Controllers\Front;

use App\ {
    Http\Controllers\Controller,
    Http\Requests\ContactRequest,
    Models\Contact
};

class ContactController extends Controller
{
    /**
     * Create a new ContactController instance.
     *
     */
    public function __construct()
    {
        $this->middleware('guest');
    }

    /**
     * Show the form for creating a new contact.
     *
     * @return \Illuminate\Http\Response
     */
    public function create()
    {
        return view ('front.contact');
    }

    /**
     * Store a newly created contact in storage.
     *
     * @param  ContactRequest $request
     * @return \Illuminate\Http\Response
     */
    public function store(ContactRequest $request)
    {
        Contact::create ($request->all ());

        return back ()->with ('ok', __('Your message has been recorded, we will respond as soon as possible.'));
    }
}

La méthode create ne présente aucune nouveauté : elle se contente de renvoyer une vue avec le formulaire.

La méthode store est chargée de mémoriser les informations dans la table contacts. On voit qu'on utilise la méthode create du modèle pour le réaliser. Il suffit de donner comme paramètres à cette méthode les entrées du formulaire.

Remarquez qu'on utilise une requête de formulaire (ContactRequest) pour la validation avec des règles classiques :

public function rules()
{
    return [
        'name' => 'bail|required|max:255',
        'email' => 'bail|required|email',
        'message' => 'bail|required|max:1000'
    ];
}

Par sécurité ce type d'assignement de masse (on transmet directement un tableau de valeurs issues du client avec la méthode create) est limité pour la sécurité par une propriété au niveau du modèle qui désigne précisément les noms des colonnes susceptibles d'être modifiées. Si vous regardez dans le fichier app/Models/Contact.php vous trouvez cette propriété :

protected $fillable = ['name', 'email', 'message'];

Ce sont les seules colonnes qui seront impactées par la méthode create (et équivalentes). Attention à cela lorsque vous avez un bug mystérieux avec des colonnes qui ne se mettent pas à jour !

Imaginez qu'il y ait une autre colonne avec des données sensibles et non prévue dans le formulaire mais qu'un petit malin l'ajoute à la requête, cette colonne serait mise à jour en même temps que les autres !