Cours pour apprendre à utiliser le framework Laravel 5.5

Dans l'application d'exemple les utilisateurs inscrits peuvent laisser des commentaires :

On peut commenter un commentaire et ainsi de suite. On a donc une organisation hiérarchique qui en plus correspond à la même entité.

Le niveau d'imbrication est réglable dans l'administration :

L'installation d'un package dans Laravel est en général très simple et se limite le plus souvent à informer composer. Pour le cas de etrepat/baum il suffit de taper :

composer require baum/baum

Et le package se charge dans le dossier vendor. D'autre part le fichier composer.json est modifié :

"require": {
    ...
    "baum/baum": "^1.1",
    ...
},

Il faut ensuite informer Laravel que le package existe dans le fichier config/app.php :

'providers' => [

...

/*
 * Package Service Providers...
 */
Baum\Providers\BaumServiceProvider::class,

Selon les packages il est ensuite parfois nécessaire de lancer d'autres opérations pour publier une configuration spécifique, des vues… Ce n'est pas le cas avec notre package.

VIII-C-1. Les migrations▲

Pour fonctionner notre package a besoin que la table concernée comporte 4 colonnes particulières. Il faut donc les prévoir dans la migration :

 

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

class CreateCommentsTable extends Migration {

  public function up()
  {
      Schema::create('comments', function(Blueprint $table) {
           ...
           $table->integer('parent_id')->nullable()->index();
           $table->integer('lft')->nullable()->index();
           $table->integer('rgt')->nullable()->index();
           $table->integer('depth')->nullable();
           ...
      });
  }

On va donc les retrouver dans la table :

VIII-C-2. Les modèles▲

use Baum\Node;

class Comment extends Node

VIII-C-3. Les relations▲

La table des commentaires (comments) est en relation avec trois autres tables :

• posts : une relation 1:n (clé étrangère : post_id) parce que les articles peuvent avoir plusieurs commentaires ;
• users : une relation 1:n (clé étrangère : user_id) parce que les utilisateurs peuvent écrire plusieurs commentaires ;
• comments : une relation 1:n avec elle-même (clé étrangère : parent_id) parce que les commentaires peuvent avoir plusieurs commentaires enfants.

Peut-être cela vous semble-t-il un peu étrange cette relation réflexive des commentaires sur eux-même mais ça fonctionne.

D'autre part on pourrait à partir de cette situation établir d'autres relations. La table comments peut très bien servir de pivot entre les tables users et posts et on pourrait établir des relations belongsToMany. Mais on n'en a pas besoin parce qu'il n'est pas vraiment utile de connaître pour un utilisateur tous les commentaires qu'il a écrits ou pour un article tous les utilisateurs qui l’ont commenté. Mais rien n'empêche d'établir plusieurs sortes de relations sur une même table, Eloquent permet cette souplesse. Une relation ne sert que lorsqu'elle est utilisée.

Si vous regardez dans le modèle Post vous trouvez ce code :

 

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.

/**
 * One to Many relation
 *
 * @return \Illuminate\Database\Eloquent\Relations\HasMany
 */
public function comments()
{
    return $this->hasMany(Comment::class);
}

/**
 * One to Many relation
 *
 * @return \Illuminate\Database\Eloquent\Relations\hasMany
 */
public function validComments()
{
    return $this->comments()->whereHas('user', function ($query) {
        $query->whereValid(true);
    });
}

/**
 * One to Many relation
 *
 * @return \Illuminate\Database\Eloquent\Relations\hasMany
 */
public function parentComments()
{
    return $this->validComments()->whereParentId(null);
}

Voyons ça de plus près :

• comments : c'est la relation hasMany classique qu'on a déjà vue ;
• validComments : c'est la relation hasMany complétée par une contrainte. En effet lorsqu'un utilisateur commente la première fois il doit être modéré, il n'est pas encore valide, il y a une colonne booléenne valid dans la table users. Ici on vérifie donc que l'utilisateur est valide parce qu'on ne doit pas encore afficher ses commentaires ;
• parentComments : on veut les commentaires valides mais seulement ceux de premier niveau (qui ne sont donc pas un commentaire de commentaire), on teste juste que la clé étrangère a la valeur nulle, qu'il n'y a donc pas de parent.

Dans les deux autres modèles on a des relations classiques, belongsTo dans Comment et hasMany dans User.

VIII-D-1. Les routes▲

Si vous regardez dans le fichier des routes routes/web.php vous trouvez ces deux routes :

 

Sélectionnez

1.
2.
3.
4.
5.
6.
7.

// Posts and comments
Route::prefix('posts')->namespace('Front')->group(function () {
    ...
    Route::name('posts.comments.store')->post('{post}/comments', 'CommentController@store');
    Route::name('posts.comments.comments.store')->post('{post}/comments/{comment}/comments', 'CommentController@store');
    ...
});

Vous remarquez que les routes sont dans un groupe pour mutualiser :

• le préfixe post ;
• l'espace de noms Front pour les contrôleurs.

Les deux routes correspondent à ces URL :

1. post/{post}/comments
2. post/{post}/comments/{comment}/comments

Pourquoi deux routes pour créer les commentaires ?

Parce qu'on a deux cas à traiter :

1 - Le cas du commentaire parent créé avec le formulaire :

Dans ce cas on a une soumission classique du formulaire et on transmet dans l'URL l'identifiant de l'article avec le paramètre {post}.

2 - Le cas de la réponse à un commentaire existant :

Dans ce cas la soumission est faite en Ajax, pour éviter de recharger toute la page, et on transmet dans l'URL l'identifiant du commentaire parent avec le paramètre {comment} en plus de celui de l'article.

VIII-D-2. Le contrôleur▲

/**
 * Store a newly created comment in storage.
 *
 * @param  \App\http\requests\CommentRequest $request
 * @param  \App\Models\Post  $post
 * @param  integer $comment_id
 * @return \Illuminate\Http\Response
 */
public function store(CommentRequest $request, Post $post, $comment_id = null)
{
    Comment::create ([
        'body' => $request->input('message' . $comment_id),
        'post_id' => $post->id,
        'user_id' => $request->user()->id,
        'parent_id' => $comment_id,
    ]);

    ...

    if (!$request->user()->valid) {
        $request->session()->flash('warning', __('Thanks for your comment. It will appear when an administrator has validated it.<br>Once you are validated your other comments immediately appear.'));
    }

    if($request->ajax()) {
        return response()->json();
    }

    return back();
}

public function store(CommentRequest $request, Post $post, $comment_id = null)

Comment::create ([
    'body' => $request->input('message' . $comment_id),
    'post_id' => $post->id,
    'user_id' => $request->user()->id,
    'parent_id' => $comment_id,
]);

if (!$request->user()->valid) {
    $request->session()->flash('warning', __('Thanks for your comment. It will appear when an administrator has validated it.<br>Once you are validated your other comments immediately appear.'));
}

if($request->ajax()) {
    return response()->json();
}

return back();

Dans l'application le rédacteur d'un commentaire peut ensuite le modifier. Il dispose d'un lien en forme d'icône représentant un stylo :

Ça ouvre un formulaire avec le texte actuel :

La soumission se fait en Ajax pour éviter de recharger la page. C'est la méthode update du contrôleur Front/CommentController qui gère cette modification :

public function update(CommentRequest $request, Comment $comment)
{
    ...

    $message = $request->input('message' . $comment->id);
    $comment->body = $message;
    $comment->save();

    return ['id' => $comment->id, 'message' => $message];
}

On a :

• une requête de formulaire pour la validation (CommentRequest) ;
• une liaison implicite entre le paramètre {comment} et le modèle Comment.

La mise à jour se fait classiquement avec la méthode save. On retourne un tableau avec l'identifiant et le texte que Laravel transforme automatiquement en réponse JSON.

Dans l'application le rédacteur d'un commentaire peut ensuite le supprimer s'il a des remords. Il dispose d'un lien en forme d'icône représentant une poubelle :

On a dans la page un formulaire classique caché :

<form action="http://monsite.fr/comments/16" method="POST" class="hide">
  <input type="hidden" name="_token" value="EK86XinyEke12ERSRx5Ddfu8hD6iNBBUIzUSe34y">
  <input type="hidden" name="_method" value="DELETE">
</form>

C'est la méthode destroy du contrôleur Front/CommentController qui gère cette suppression :

public function destroy(Comment $comment)
{
    ...

    $comment->delete();

    return back();
}

On a une liaison implicite entre le paramètre {comment} et le modèle Comment.

La suppression se fait classiquement avec la méthode delete.

L'affichage des commentaires se fait lorsqu'on affiche un article. C'est géré par la méthode show du contrôleur Front/PostController :

public function show(Request $request, $slug)
{
    $user = $request->user();

    return view('front.post', array_merge($this->postRepository->getPostBySlug($slug), compact('user')));
}

On récupère l'utilisateur en cours avec $request->user() et les informations nécessaires dans le repository PostRepository (méthode getPostBySlug). On a déjà commencé à voir cette méthode dans le chapitre sur la relation 1:nLa relation 1:n :

public function getPostBySlug($slug)
{
    // Post for slug with user, tags and categories
    $post = $this->model->with([
        'user' => function ($q) {
            $q->select('id', 'name', 'email');
        },
        'tags' => function ($q) {
            $q->select('tags.id', 'tag');
        },
        'categories' => function ($q) {
            $q->select('title', 'slug');
        }
    ])
    ->with(['parentComments' => function ($q) {
        $q->with('user')
            ->latest()
            ->take(config('app.numberParentComments'));
    }])
    ->withCount('validComments')
    ->withCount('parentComments')
    ->whereSlug($slug)
    ->firstOrFail();

    // Previous post
    $post->previous = $this->getPreviousPost($post->id);

    // Next post
    $post->next = $this->getNextPost($post->id);

    return compact('post');
}

On va s'intéresser cette fois à cette partie du code :

->with(['parentComments' => function ($q) {
    $q->with('user')
        ->latest()
        ->take(config('app.numberParentComments'));
}])
->withCount('validComments')
->withCount('parentComments')

On charge (with) les commentaires de niveau un (parentComments) ainsi que les rédacteurs des commentaires (with('user')), à partir du plus récent (latest) et on ne prend (take) que ce qui est indiqué dans la configuration (app.numberParentComments).

D'autre part on récupère aussi le nombre de commentaires valides (->withCount('validComments')) et le nombre de commentaires de niveau un (->withCount('parentComments')).

Dans la vue front/post.blade.php on a ce code :

@if ($post->valid_comments_count)
    ...
    <ol class="commentlist">
        @include('front/comments/comments', ['comments' => $post->parentComments])
    </ol>
    ...
@endif

Si on a des commentaires valides on inclut (@include) la vue front/comments/comments :

@foreach($comments as $comment)
    @include('front/comments/comments-base')
@endforeach

Dans cette vue pour chaque (@foreach) commentaire on inclut la vue front/comments/comments-base. Je ne vais pas analyser tout le code mais me focaliser sur une partie intéressante :

@unless ($comment->isLeaf())
    ...
    <ul class="children">
        @include('front/comments/comments', ['comments' => $comment->getImmediateDescendants()])
    </ul>
@endunless

À moins que (@unless) le commentaire n'ait plus d'enfant ($comment->isLeaf()) on inclut à nouveau la vue front/comments/comments en passant en paramètre tous les commentaires immédiatement descendants ($comment->getImmediateDescendants()). On itère donc dans tous les commentaires pour les afficher de façon hiérarchique.

On a vu que dans la configuration (config/app.php) on limite le nombre de commentaires de premier niveau à afficher, par défaut la valeur est 2 :

'numberParentComments' => 2,

S'il y a encore des commentaires à afficher on présente un bouton :

On trouve ce code dans la vue front/post.blade.php pour gérer l'apparition conditionnelle du bouton :

@if ($post->parent_comments_count > config('app.numberParentComments'))
    <p id="morebutton" class="text-center">
        <a id="nextcomments" href="{{ route('posts.comments', [$post->id, 1]) }}" class="button">@lang('More comments')</a>
    </p>
    ...
@endif

La requête passe en Ajax pour éviter de recharger la page. Elle est gérée par la méthode comments du contrôleur Front/CommentController :

public function comments(Post $post, $page)
{
    $comments = $this->commentRepository->getNextComments($post, $page);
    $count = $post->parentComments()->count();
    $level = 0;

    return [
        'html' => view('front/comments/comments', compact('post', 'comments', 'level'))->render(),
        'href' => $count <= config('app.numberParentComments') * ++$page ?
            'none'
            : route('posts.comments', [$post->id, $page]),
    ];
}

C'est le repository CommentRepository qui est chargé de récupérer les commentaires :

public function getNextComments(Post $post, $page)
{
    return $post->parentComments()
        ->with('user')
        ->latest()
        ->skip($page * config('app.numberParentComments'))
        ->take(config('app.numberParentComments'))
        ->get();
}

On prend :

• les commentaires de niveau un (parentComments) ;
• en chargeant (with) les rédacteurs (user) ;
• en commençant par les plus récents (latest) ;
• en sautant (skip) ceux qui sont déjà affichés ;
• en prenant (take) la quantité définie dans la configuration.

Je ne vous ai pas encore parlé des factories… Les factories sont des classes principalement consacrées aux tests mais qui peuvent aussi servir en d'autres occasions comme ici pour créer des enregistrements. On les trouve ici :

Par défaut on a juste la classe factory pour le modèle User :

$factory->define(App\User::class, function (Faker $faker) {
    static $password;

    return [
        'name' => $faker->name,
        'email' => $faker->unique()->safeEmail,
        'password' => $password ?: $password = bcrypt('secret'),
        'remember_token' => str_random(10),
    ];
});

Sans entrer dans les détails, on utilise le composant Faker pour générer des données aléatoires pour les propriétés du modèle User. Par exemple avec ce code :

factory(User::class, 15)->create();

On crée directement quinze utilisateurs !

Voici la classe factory pour les commentaires (CommentFactory) :

$factory->define(App\Models\Comment::class, function (Faker $faker) {

    return [
        'body' => $faker->paragraph($nbSentences = 4, $variableNbSentences = true),
    ];
});

Ensuite les commentaires peuvent facilement être créés en ajoutant les informations manquantes dans la classe factory (ou en les surchargeant) :

$comment1 = factory(Comment::class)->create([
    'post_id' => 2,
    'user_id' => 3,
]);

On utilise une méthode du package baum (makeChildOf) pour hiérarchiser les commentaires :

factory(Comment::class)->create([
    'post_id' => 4,
    'user_id' => 5,
    //'parent_id' => $nbrComments,
])->makeChildOf($comment2);

On a vu dans ce chapitre comment utiliser un package pour gérer une situation particulière, ici un arbre de données hiérarchiques en simplifiant ainsi le codage final.