Tutoriel Laravel pour les débutants

Qu'est-ce que Laravel?

Laravel est un framework Web MVC open source pour PHP. Laravel est un framework robuste qui permet de développer facilement des applications Web PHP avec des fonctionnalités telles qu'un système de packaging modulaire avec un gestionnaire de dépendances dédié, un accès aux bases de données relationnelles et d'autres utilitaires pour le déploiement et la maintenance des applications.

Laravel a été créé par Taylor Otwell. Depuis sa sortie initiale en juin 2011 (version 1), il n'a cessé de gagner en popularité dans le secteur des frameworks PHP du développement web. Cette popularité s'explique en grande partie par ses nombreuses fonctionnalités conçues pour les développeurs et intégrées par défaut.

Pourquoi Laravel ?

Vers 2000, la plupart code PHP était procédural et pouvait être trouvé sous la forme de « scripts » qui auraient un fouillis de code spaghetti. Même les pages les plus simples n'avaient pas séparation des préoccupationsDe ce fait, une application pouvait rapidement devenir un véritable cauchemar en termes de maintenance. Le monde avait besoin d'une meilleure solution. C'est ainsi qu'est apparu PHP 5 et divers frameworks PHP, qui ont tenté d'apporter la structure indispensable et de meilleures solutions aux problèmes rencontrés dans les applications web.

Depuis, de nombreux frameworks ont vu le jour, ouvrant la voie aux frameworks populaires d'aujourd'hui. Actuellement, le trio de tête est (selon nous) Zend Framework, Symfony et bien sûr Laravel. Bien que chacun de ces frameworks repose sur des principes similaires et vise à résoudre (en gros) les mêmes problèmes courants, leurs principales différences résident dans leur implémentation. Chacun a ses propres particularités quant à la résolution des problèmes. En examinant le code produit par chacun d'eux, on constate une nette distinction entre eux. À notre avis, Laravel est le meilleur.

En savoir plus sur le différence entre Laravel et Codeallumeur.

Comment télécharger et installer Laravel avec Composer

À noter: Ce tutoriel a été rédigé pour Laravel 5.8, mais les concepts de routage, de contrôleur, de requête et de Blade restent inchangés dans les versions actuelles. En 2026, la dernière version est Laravel 13 (sortie en mars 2026), qui requiert PHP 8.3 ou une version ultérieure, tandis que Laravel 12 requiert PHP 8.2.

À noter: Il est supposé que vous avez déjà installé PHP sur votre système. Sinon, vous pouvez consulter la procédure d'installation. ici.

Composer est à la fois un gestionnaire de packages et de dépendances. Pour l'installer, ouvrez un terminal et cd dans un nouveau répertoire. Exécutez cette commande :

curl -Ss getcomposer.org/installer | php

Les résultats de cette commande ressembleront à ceci :

À noter: Pour des instructions plus détaillées sur la configuration de Laravel, consultez la documentation de Laravel. ici.

Vous verrez le téléchargement et la compilation du script composer.phar, qui nous sert à installer Laravel. Bien qu'il existe plusieurs façons de configurer une nouvelle application Laravel, nous utiliserons le script Composer de Laravel. Pour installer ce script, exécutez :

composer global require laravel/installer

Ce qui ressemblera à ceci :

Cela téléchargera et installera tous les fichiers du framework ainsi que toutes les dépendances nécessaires. Les paquets seront enregistrés dans le répertoire vendor. Une fois le téléchargement et l'installation terminés, il suffit d'exécuter la commande suivante :

laravel new uploadApp

Vous verrez quelque chose comme le résultat suivant :

Composer installe tous les paquets nécessaires au fonctionnement de Laravel. Cela peut prendre quelques minutes, veuillez patienter. Une fois l'installation terminée, exécutez la commande `ls -al` pour consulter la liste des paquets installés.

Voici une brève description des répertoires dans une application Laravel courante :

• application/ : Il s'agit du dossier source où se trouve le code de notre application. Tous les contrôleurs, politiques et modèles sont contenus dans ce dossier.
• amorcer/ : Contient le script de démarrage de l'application et quelques fichiers de mappage de classes.
• configuration/ : Contient les fichiers de configuration de l'application. Ces fichiers ne sont généralement pas modifiés directement, mais dépendent plutôt des valeurs définies dans le fichier .env (environnement) à la racine de l'application.
• base de données/ : Contient les fichiers de base de données, y compris les migrations, les fichiers de démarrage et les environnements de test.
• publique/ : Dossier accessible au public contenant les ressources compilées et, bien sûr, un fichier index.php.
• ressources/ : Contient des éléments front-end tels que JavaFichiers de script, fichiers de langue, fichiers CSS/SASS et tous les modèles utilisés dans l'application (appelés modèles Blade).
• itinéraires/ : Toutes les routes de l'application se trouvent ici. Il existe plusieurs niveaux de définition des routes, mais nous nous concentrerons sur le fichier web.php.
• stockage/ : Tous les fichiers de cache temporaires utilisés par l'application, les fichiers de session, les scripts de vue compilés et les fichiers journaux.
• essais/ : Contient les fichiers de test de l'application, tels que les tests unitaires et les tests fonctionnels.
• fournisseur/ : Tous les paquets de dépendances ont été installés avec Composer.

Passons maintenant à la compilation du reste de l'application et à son exécution avec une commande Artisan spécifique (pour nous épargner la fastidieuse installation et configuration d'un serveur web comme Apache ou nginx). Le fichier `.env` contient toutes les valeurs de configuration utilisées par les fichiers du répertoire `/config` pour configurer l'application.

Conception d’applications : un aperçu rapide de nos exigences

Dans ce didacticiel Laravel en ligne, nous allons créer une application très simple qui ne fera que deux choses :

1. gérer les téléchargements de fichiers à partir d'un formulaire Web
2. Afficher les fichiers précédemment téléchargés sur une page différente.

Pour ce projet, notre application sera en écriture seule : l’utilisateur pourra uniquement écrire des fichiers et consulter la liste des fichiers qu’il a téléchargés. Cette application est très simple, mais elle vous permettra de vous familiariser avec Laravel et d’acquérir de nouvelles compétences. Par souci de concision, nous avons omis la modélisation de la base de données, les migrations et l’authentification, mais dans une application réelle, ce sont des éléments supplémentaires à prendre en compte.

Voici une liste des composants dont nous aurons besoin pour que l'application fonctionne comme prévu :

• A route cela permettra au monde extérieur (Internet) d'utiliser l'application, et spécifiera également le point de terminaison qui indiquera où se trouve la logique d'enregistrement du fichier téléchargé.
• A contrôleur qui gère le flux requête-réponse.
• A modèle qui servira à afficher la liste des fichiers précédemment téléchargés ainsi que le formulaire de téléchargement proprement dit.
• A demandez que le contrôleur utilisera pour valider les données transmises par le formulaire web.

Qu’est-ce qu’un itinéraire ?

Dans Laravel, une route est un point de terminaison spécifié par une URI qui sert de « pointeur » vers une fonctionnalité de l'application. Le plus souvent, une route pointe vers une méthode d'un contrôleur et définit également les méthodes HTTP autorisées à accéder à cette URI. Une route ne désigne pas toujours une méthode de contrôleur ; elle peut aussi déléguer l'exécution de l'application à une fonction anonyme ou une closure.

Pourquoi utiliser un itinéraire ?

Les routes sont stockées dans des fichiers sous le dossier /routes dans le répertoire racine du projet. Par défaut, il existe quelques fichiers différents correspondant aux différents « côtés » de l'application (« côtés » vient de la méthodologie de l'architecture hexagonale). Ils comprennent:

• web.php : les routes publiques accessibles via le navigateur. Ce sont les plus courantes et celles auxquelles le navigateur web accède. Elles fonctionnent grâce au groupe de middleware web et contiennent également des fonctionnalités pour Protection CSRF (ce qui permet de se défendre contre les attaques malveillantes basées sur des formulaires) et contiennent généralement un certain degré d’« état » (par là, nous entendons qu’ils utilisent des sessions).
• api.php : routes correspondant à un groupe d’API et dont le middleware d’API est donc activé par défaut. Ces routes sont sans état et n’utilisent ni session ni mémoire partagée entre les requêtes (une requête ne partage ni données ni mémoire avec une autre ; chacune est auto-encapsulée).
• console.php : ces routes correspondent aux commandes Artisan personnalisées que vous avez créées pour votre application.
• channels.php : enregistre les routes pour la diffusion d’événements.

Le fichier clé à prendre en compte pour le moment est le fichier spécifique au navigateur, web.php. Une route est déjà définie par défaut : celle que vous empruntez en accédant à la racine web de votre application (située dans le répertoire public). Pour que notre application d'upload fonctionne, nous aurons besoin de trois routes différentes :

• /upload : il s’agira de l’URI de la page principale affichant notre formulaire web de téléchargement de fichiers.
• /process : c’est ici que le formulaire situé à l’URI /upload enverra les données soumises (l’« action » du formulaire).
• /list : cette commande affichera la liste de tous les fichiers téléchargés sur le site.

À noter: Le point de terminaison /list ne serait peut-être pas nécessaire si nous souhaitions placer toute la logique d'affichage du formulaire de téléchargement et de la liste des fichiers sur une seule page ; cependant, nous les avons gardés séparés pour le moment afin d'apporter un peu plus de matière au sujet traité.

//inside routes/web.php
Route::get('/upload', 'UploadController@upload')->name('upload');
Route::get('/download', 'UploadController@download')->name('download');
Route::post('/process', 'UploadController@process')->name('process');
Route::get('/list', 'UploadController@list')->name('list');

Dans ce tutoriel sur le framework Laravel, pour chaque route souhaitée, nous la déclarerons explicitement dans le fichier de routes web.php en utilisant l'une des méthodes de requête HTTP disponibles (get(), post(), put(), delete(), patch() ou options()). Pour une description détaillée de chacune d'elles, consultez ceci. Ces méthodes permettent de spécifier les verbes HTTP autorisés à accéder à une route donnée. Si une route doit accepter plusieurs verbes HTTP (par exemple, si vous utilisez une seule page pour afficher les données initiales et envoyer les données d'un formulaire), vous pouvez utiliser la méthode `Route::any()`.

Le deuxième argument des méthodes `Route::get()` et `Route::post()` (ainsi que de toutes les autres méthodes liées aux verbes HTTP de la façade `Route`) est le nom d'un contrôleur spécifique et la méthode, au sein de ce contrôleur, qui est exécutée lors de l'accès au point de terminaison de la route avec une requête HTTP autorisée (GET, POST, PATCH, etc.). Nous utilisons le contrôleur `UploadController` pour toutes les routes et les avons spécifiées de la manière suivante :

La dernière méthode que nous appelons sur chaque route est sa fonction name(), qui accepte une seule chaîne de caractères comme argument et sert en quelque sorte à « étiqueter » une route particulière avec un nom facile à retenir (dans nos cas, upload, process et list). Donner un nom à chaque route peut sembler superflu, mais… URL Le nom est exactement le même, mais c'est vraiment pratique lorsqu'on a une route spécifique comme /users/profile/dashboard/config, qu'il serait plus facile de retenir sous le nom de profile-admin ou user-config.

Note sur les façades :

• Les façades fournissent une interface « statique » aux classes disponibles dans le conteneur de services de l'application.
• Ils fournissent une syntaxe concise et mémorable qui vous permet d'utiliser les fonctionnalités de Laravel sans vous souvenir des noms de classe longs qui doivent être injectés ou configurés manuellement.

Dans les définitions de routes ci-dessus, nous utilisons la façade Route au lieu d'instancier manuellement un nouvel objet Illuminate/Routing/Router et d'appeler les méthodes correspondantes sur cet objet. Il s'agit simplement d'un raccourci qui permet de gagner du temps.pingLes façades sont largement utilisées dans le framework Laravel ; vous pouvez et devriez vous familiariser davantage avec elles. La documentation relative aux façades est disponible ici : ici.

Qu'est-ce qu'un contrôleur ?

Un contrôleur est le « C » de l’architecture « MVC » (Model-View-Controller), sur laquelle est basé Laravel. Le travail d'un contrôleur peut se résumer à cette simple définition : Il reçoit la requête du client et lui renvoie une réponse. Voici la définition de base, qui constitue également l'exigence minimale de tout contrôleur. Ce qu'il fait entre ces deux éléments est généralement considéré comme l'« action » du contrôleur (ou l'« implémentation de la route »). Il sert de second point d'entrée vers l'application (le premier étant la requête) pour le client, qui envoie la charge utile de la requête (que nous aborderons ensuite) à l'application, en attendant une réponse (page de succès, redirection, page d'erreur ou tout autre type de réponse HTTP).

Un contrôleur fait (en gros) la même chose qu'une définition de route, avec une fonction anonyme définie comme « action » lorsque cette route est atteinte. La différence réside dans le fait qu'un contrôleur respecte le principe de séparation des responsabilités, tandis qu'une route est définie directement dans le code. URL définition, ce qui signifie en gros que nous associons l'URI attribuée à la route à l'implémentation de la route, c'est-à-dire au code qui s'exécute lorsque cette route est atteinte.

Par exemple, les deux morceaux de code suivants permettront d’obtenir le même résultat :

Exemple n°1 : définition et implémentation de la route dans un seul appel de méthode (dans le fichier routes web.php)

//inside routes/web.php
<?php
Route::get('/hello-world', function(Request $request) {
$name = $request->name;
return response()->make("<h1>Hello World! This is ".$name, 200);
});

Exemple n° 2 : La définition de la route se trouve dans le fichier routes/web.php, mais son implémentation réside dans la classe /app/Http/Controllers/HelloWorldController.

//inside routes/web.php
<?php

Route::get('/hello-world', 'HelloWorldController@index')->name('hello-world');

------------------------------------------------------------------------------------
//inside app/Http/Controllers/HelloWorldController.php
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;

class HelloWorldController extends Controller
{
public function index(Request $request)
{
$name = $request->name;
return response()->make("<h1>Hello World! This is ".$name, 200);
}
}

Bien que l'exemple Laravel n° 2 semble demander beaucoup plus de travail (ce qui n'est pas le cas, juste un peu plus de code), voyez les avantages que nous obtenons en plaçant la logique d'action pour la route « hello-world » donnée dans un contrôleur plutôt que dans la définition de la route sous forme de fonction de rappel :

1. Notre logique est clairement séparée dans sa propre classe (séparation des préoccupations).
2. Notre contrôleur est conçu pour être étendu ultérieurement si nous devions y ajouter des fonctionnalités supplémentaires. Supposons que nous voulions ajouter une fonctionnalité « au revoir ». Dans ce cas, nous renommerions le contrôleur en un nom plus générique, « HelloController », puis définirions deux méthodes distinctes. Bonjour() et au revoir(). Nous aurions également besoin de définir deux itinéraires distincts qui cartographient le /salut et / Au revoir Les URI sont associées à la méthode appropriée dans le contrôleur. Cette approche est préférable à l'encombrement d'un fichier de routes contenant l'implémentation de chaque route définie par des fonctions de rappel.
3. Laravel a la capacité intégrée de mettre en cache toutes les définitions d'itinéraire dans l'application afin d'accélérer le temps nécessaire pour trouver un itinéraire donné (augmente les performances de l'application) ; Cependant, Vous ne pourrez en profiter que si toutes vos routes définies dans l'application sont configurées à l'aide d'une carte spécifique au contrôleur.pings (voir l'exemple n° 2 ci-dessus).

Exécutons cette commande qui générera un nouveau contrôleur pour nous.

// ...inside the project's root directory:
php artisan make:controller UploadController

Cette commande génère un stub pour un contrôleur nommé « UploadController » dans le répertoire principal des contrôleurs, à l'emplacement /app/Http/Controllers/UploadController.php. Vous pouvez ouvrir ce fichier pour l'examiner. Il est très simple : il s'agit d'une version incomplète du contrôleur, avec le chemin d'accès correct à l'espace de noms et les classes dont il hérite.

Générer la demande

Avant de poursuivre ce tutoriel PHP Laravel et d'apporter quelques modifications au stub généré de l'UploadController, il est plus judicieux de créer d'abord la classe de requête. En effet, la méthode du contrôleur qui gère la requête doit typer l'objet requête dans sa signature, ce qui lui permet de valider automatiquement les données du formulaire entrant (comme spécifié dans la méthode rules() ; nous y reviendrons plus tard). Pour l'instant, utilisons à nouveau la commande artisan pour générer notre stub de requête :

php artisan make:request UploadFileRequest

Cette commande générera un fichier nommé UploadFileRequest dans app/Http/Requests/UploadFileRequest. Ouvrez ce fichier et jetez-y un œil. Vous constaterez qu'il est très simple et ne contient que deux méthodes : authorize() et rules().

Création de la logique de validation

Modifions le modèle de requête pour qu'il corresponde aux besoins de notre application. Modifiez le fichier pour qu'il ressemble à ceci :

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UploadFileRequest extends FormRequest
{
/**
* Determine if the user is authorized to make this request.
*
* @return bool
*/
public function authorize()
{
return true;
}

/**
* Get the validation rules that apply to the request.
*
* @return array
*/
public function rules()
{
return [
'fileName' => 'required|string',
'userFile' => 'required|file'
];
}
}

Peu de changements, mais notez que la méthode `authorize()` renvoie désormais `true` au lieu de `false`. Cette méthode détermine si la requête est autorisée à accéder à l'application. Si elle renvoie `false`, la requête est bloquée. C'est l'endroit idéal pour implémenter des contrôles d'autorisation de l'utilisateur ou toute autre logique permettant de décider si la requête peut être transmise au contrôleur. Pour l'instant, nous renvoyons simplement `true` afin d'autoriser toute opération à utiliser la requête.

L'autre méthode, rules(), est celle où toute la magie opère en matière de validation. L'idée est simple : renvoyer un tableau contenant un ensemble de règles sous la forme :

'formFieldName' => 'constraints this field has separated by pipe characters (|)'

Il existe de nombreuses contraintes de validation différentes qui sont prises en charge par Laravel dès la sortie de la boîte. Pour une liste complète d'entre eux, consultez la documentation en ligne iciPour notre application d'envoi de fichiers, deux champs seront transmis via une requête POST depuis un formulaire côté client. Le paramètre `fileName` doit figurer dans le corps du formulaire (il est donc obligatoire) et servira de nom de fichier pour l'enregistrement (cette opération est effectuée dans le contrôleur ; nous y reviendrons plus tard). Nous précisons également que le nom de fichier doit être une chaîne de caractères en ajoutant une barre verticale (`|`) et le mot « chaîne ». Les contraintes sont toujours délimitées par des barres verticales, ce qui permet de spécifier des critères supplémentaires pour le champ concerné sur une seule ligne.

Le deuxième paramètre, userFile, est le fichier que l'utilisateur télécharge à partir d'un formulaire sur une page web. userFile est également obligatoire et doit être un fichier. À noter: Si nous nous attendions à ce que le fichier téléchargé soit une image, nous utiliserions la contrainte d'image, qui limiterait les types de fichiers acceptés aux formats d'image courants (JPEG, PNG, BMP, GIF ou SVG). Puisque nous souhaitons permettre à l'utilisateur de télécharger tout type de fichier, nous conserverons la contrainte de validation de fichier.

L'objet requête résume assez bien la situation. Son rôle principal est de contenir l'ensemble des critères (contraintes) que les paramètres du corps du formulaire doivent respecter pour que l'application puisse poursuivre son exécution. Il est également important de noter que ces deux champs (userFile et fileName) doivent être spécifiés dans le code HTML sous forme de champs de saisie (leur nom correspondant à celui de l'objet requête).

Vous vous demandez peut-être : ceci définit les caractéristiques que doit contenir une requête de formulaire, mais où s’effectue concrètement la vérification de ces contraintes ? Nous aborderons ce point plus loin.

Modification du contrôleur

Ouvrez l'application/Http/Controllers/UploadController et apportez-y les modifications suivantes :

<?php

namespace App\Http\Controllers;

use Illuminate\Contracts\Container\BindingResolutionException;
use Illuminate\Http\Request;
use App\Http\Requests\UploadFileRequest; //our new request class
use Illuminate\Support\Facades\Storage;

class UploadController extends Controller
{
/**
* This is the method that will simply list all the files uploaded by name and provide a
* link to each one so they may be downloaded
*
* @param $request : A standard form request object
* @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
* @throws BindingResolutionException
*/
public function list(Request $request)
{
$uploads = Storage::allFiles('uploads');

return view('list', ['files' => $uploads]);
}

/**
* @param $file
* @return \Symfony\Component\HttpFoundation\BinaryFileResponse
* @throws BindingResolutionException
*/
public function download($file)
{
return response()->download(storage_path('app/'.$file));
}

/**
* @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
* @throws BindingResolutionException
*/
public function upload()
{
return view('upload');
}

/**
* This method will handle the file uploads. Notice that the parameter's typehint
* is the exact request class we generated in the last step. There is a reason for this!
*
* @param $request : The special form request for our upload application
* @return array|\Illuminate\Http\UploadedFile|\Illuminate\Http\UploadedFile[]|null
* @throws BindingResolutionException
*/
public function process(UploadFileRequest $request)
{
//At this point, the parameters passed into the $request (from form) are
//valid--they satisfy each of the conditions inside the rules() method

$filename = $request->fileName; //parameters have already been validated
$file = $request->file('userFile'); //so we don't need any additional isset()

$extension = $file->getClientOriginalExtension(); //grab the file extension
$saveAs = $filename . "." . $extension; //filename to save file under

$file->storeAs('uploads', $saveAs, 'local'); //save the file to local folder

return response()->json(['success' => true]); //return a success message
}
}

Il s'agit donc d'une méthode relativement simple pour enregistrer les fichiers téléchargés sur le disque. Voici une explication détaillée de la méthode process() ci-dessus :

• Indiquez le type de la classe de requête dans la méthode du contrôleur qui effectue la fonctionnalité principale afin que nous puissions valider automatiquement les données entrantes.
• Récupérez le fichier à partir de l'objet de requête (désormais validé) dans la méthode du contrôleur.
• Extrayez le nom du fichier de la requête.
• Générez le nom de fichier final qui sera utilisé pour enregistrer le fichier sous. La méthode getClientOriginalExtension() récupère simplement l'extension d'origine du fichier téléchargé.
• Stockez le fichier sur le système de fichiers local à l'aide de sa méthode storeAs(), en passant le chemin nommé dans le répertoire /storage comme premier argument et le nom de fichier sous lequel l'enregistrer comme second.
• Renvoyer une réponse JSON indiquant que la requête a abouti.

Le modèle de lame

La dernière pièce maîtresse de ce puzzle est le modèle de lame, qui contiendra tout le HTML, le CSS et le JavaVoici le script de notre application simple. Le code est disponible ici ; nous l’expliquerons plus tard.

<body>
<h1>Upload a file</h1>
<form id="uploadForm" name="uploadForm" action="{{route('process')}}" enctype="multipart/form-data">
@csrf
<label for="fileName">File Name:</label>
<input type="text" name="fileName" id="fileName" required /><br />
<label for="userFile">Select a File</label>
<input type="file" name="userFile" id="userFile" required />
<button type="submit" name="submit">Submit</button>
</form>
<h2 id="success" style="color:green;display:none">Successfully uploaded file</h2>
<h2 id="error" style="color:red;display:none">Error Submitting File</h2>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script>
$('#uploadForm').on('submit', function(e) {
e.preventDefault();
var form = $(this);
var url = form.attr('action');
$.ajax({
url: url,
type: "POST",
data: new FormData(this),
processData: false,
contentType: false,
dataType: "JSON",
success: function(data) {
$("#fileName").val("");
$("#userFile").val("");
}
}).done(function() {
$('#success').css('display', 'block');
window.setTimeout(()=>($("#success").css('display', 'none')), 5000);
}).fail(function() {
$('#error').css('display', 'block');
window.setTimeout(()=>($("#error").css('display', 'none')), 5000);
});
});
</script>
</body>
</html>

Voici ce que notre /télécharger la page ressemble à :

Voici un exemple très typique de fichier Blade contenant un formulaire HTML et JavaScript/jQuery pour ajouter une fonctionnalité asynchrone (afin que la page ne se recharge pas). Il existe une structure de base. Une balise sans attribut `method` (que nous expliquerons dans un instant) et avec un attribut `action` particulier ayant la valeur `{{route('process')}}`. Dans Blade, c'est ce qu'on appelle une… Directive. Une directive est simplement un terme technique pour désigner une fonction ; il s’agit de fonctions spécifiques aux modèles Blade qui effectuent différentes opérations courantes dans la construction de pages et d’applications web. Pour mieux comprendre toutes les possibilités offertes par Blade, consultez la documentation. iciDans le cas ci-dessus, nous utilisons la directive de route pour générer un URL pour soumettre notre formulaire.

Rappelez-vous que nous avons défini nos routes précédemment dans l'application, dans le fichier web.php, en spécifiant un nom facile à retenir pour chacune d'elles. La directive {{route()}} accepte le nom d'une route, le recherche dans la liste des routes mises en cache en interne et génère un fichier complet. URL En fonction de la définition de cette route dans le fichier web.php, nous spécifions, dans ce premier cas, que nous souhaitons que le formulaire envoie ses données soumises à /process. URL de notre application, qui est définie comme une POSTEZ trajet.

Vous avez peut-être ensuite remarqué la balise `@csrf` juste en dessous de la balise d'ouverture du formulaire. Dans Blade, cette balise génère un paramètre `_token` sur le formulaire, qui est vérifié par l'application avant que les données du formulaire ne soient traitées. Cela garantit que les données du formulaire proviennent d'une origine valide et empêche les attaques de type CSRF (Cross-Site Request Forgery). Pour plus d'informations à ce sujet, consultez la documentation. docs.

Après cela, nous définissons notre formulaire comme d'habitude ; cependant, veuillez noter que les noms de nos paramètres de formulaire, userFile et fileName, sont les exactement la même tel que défini dans notre objet requête. Si nous oublions de renseigner un paramètre défini dans l'objet requête (ou si nous le renseignant mal), la requête échouera et une erreur sera renvoyée, empêchant ainsi la requête du formulaire d'origine d'atteindre la méthode du contrôleur située dans UploadController@process.

N'hésitez pas à l'essayer et à soumettre quelques fichiers à l'application via ce formulaire. Ensuite, accédez à /liste pour voir le contenu du dossier de téléchargement, avec les fichiers que vous avez téléchargés répertoriés dans un tableau :

The Bigger Picture

Prenons un peu de recul et examinons ce que nous avons réalisé dans ce tutoriel Laravel.

Ce diagramme représente l'application dans son état actuel (détails généraux exclus) :

Il est important de rappeler que l'objet requête créé au début de ce tutoriel Laravel doit avoir les mêmes paramètres définis dans sa méthode `rules` que ceux du formulaire dans le template Blade (sinon, relisez la section « Création de la logique de validation »). L'utilisateur remplit le formulaire sur une page web générée par le moteur de template Blade et le soumet. Le code jQuery du template, situé en bas de page, empêche la soumission par défaut (qui redirigerait automatiquement vers une autre page), crée une requête AJAX, la charge avec les données du formulaire et le fichier téléchargé, puis envoie le tout à la première couche de notre application : la requête.

L'objet requête est initialisé en associant les paramètres de la méthode `rules()` aux paramètres du formulaire soumis, puis les données sont validées selon chaque règle spécifiée. Si toutes les règles sont respectées, la requête est transmise à la méthode du contrôleur correspondant aux valeurs définies dans le fichier de route `web.php`. Dans ce cas, il s'agit de la méthode `process()` du contrôleur `UploadController`. Une fois le contrôleur atteint, la validation de la requête est confirmée ; il est donc inutile de vérifier à nouveau si le nom de fichier fourni est bien une chaîne de caractères ou si le paramètre `userFile` contient bien un fichier. L'exécution peut se poursuivre normalement.

La méthode du contrôleur récupère ensuite les paramètres validés de l'objet requête, génère un nom de fichier complet en concaténant le paramètre `fileName` transmis avec l'extension d'origine du fichier utilisateur, enregistre le fichier dans un répertoire de l'application, puis renvoie une réponse JSON simple confirmant la réussite de la requête. Cette réponse est reçue par la logique jQuery, qui effectue quelques tâches d'interface utilisateur supplémentaires, comme l'affichage du message de succès (ou d'erreur) pendant 5 secondes, puis son masquage, ainsi que la suppression des données précédemment saisies dans le formulaire. Ainsi, l'utilisateur est certain que la requête a abouti et peut, s'il le souhaite, téléverser un autre fichier.

Notez également, dans le schéma ci-dessus, la limite entre le client et le serveur. Il est essentiel de bien comprendre ce concept ; il vous aidera à résoudre les problèmes que vous pourriez rencontrer ultérieurement, par exemple lors de la gestion de plusieurs requêtes asynchrones simultanées. Cette séparation se situe à la limite de l'objet requête. Cet objet peut être considéré comme la « passerelle » vers le reste de l'application. Il effectue la validation initiale et l'enregistrement des valeurs du formulaire transmises par le navigateur web. Si elles sont jugées valides, la requête est transmise au contrôleur. Tout ce qui précède se déroule côté client (le terme « client » désigne littéralement l'ordinateur de l'utilisateur). La réponse est renvoyée par l'application au client, où notre code jQuery attend patiemment son arrivée et effectue quelques tâches d'interface utilisateur simples dès sa réception.

Nous avons également traité de nombreuses questions fréquemment posées. Questions d'entretien liées à Laravel et PHP pour les débutants comme pour les candidats expérimentés pour obtenir le bon emploi.

FAQ