Apache >= 2.2
PHP >= 5.4
Ainsi que MySQL, Postgres, SQLite, ou SQL Server
Créez un dossier au nom de votre projet. Pour plus de simplicité, évitez les espaces et autres caractères en dehors de ceux de l'alphabet dans le chemin complet de votre dossier (path). Puis installez Laravel dans ce dossier grâce au composer (un gestionnaire de dépendance pour PHP) :
Une fois composer installé, dans une invite de commande en mode administrateur, placez vous dans votre dossier et faites :
composer create-project laravel/laravel --prefer-distNormallement votre configuration Apache et PHP devrait être OK, si jamais vous rencontrez un problème, vérifiez que le module Apache mod_rewrite est bien activé, ainsi que les modules PHP suivants:
Pour qu'Apache trouve votre projet, créez un "lien symbolique" dans le dossier "htdocs" ou "www" de votre serveur apache. Pour créez un "lien symbolique" sous Windows:
mklink /D laravel C:/chemin/complet/vers/votre/dossier/laravel/publicPour créez un "lien symbolique" sous Mac:
ln -s /chemin/complet/vers/votre/dossier/laravel/public laravelUn .htaccess dans le répertoire public de votre projet redirige toutes les requêtes sur index.php. index.php inclut les fichiers de boostrap disponibles dans le répertoire bootstrap de votre projet. Ceux-ci initialisent l'autoloader, gèrent l'environnement (développement, recette, production ou autre ?), construisent l'instance principale de notre application, enregistrent différentes classes applicatives du Framework dans l’IoC (Inversion of Control, pour l'injection des dépendances), chargent les fichiers de configuration, ... puis à la fin Laravel s'occupe du dispatcher.
Le fichier app/Http/routes.php permet de définir les routes que devra gérer le dispatcher de Laravel. Vous pouvez y router les différents verbes HTTP (GET, POST, PUT, ...) très facilement. N'oubliez pas que les browsers communiquent principalement avec le verbe GET. Donc, si vos données sont destinées à un client qui est un "browser", vous utiliserez principalement ce verbe.
La définition des routes de Laravel est assez souple. On peut par exemple définir des paramètres dans la route. Exemple:
Route::get('user/{id}', function($id)
{
return 'User '.$id;
});Permettra au dispatcher de capturer les requêtes ayant comme chemin (path de l'URL) user/12 ou encore user/foo mais pas user/foo/bar (plus d'informations sur le site officiel).
Vos controllers devront se trouver dans le dossier app/Http/Controllers. Tous vos controllers devront étendre (héritage) la classe Controller (déjà présente dans le dossier du Framework).
Les méthodes public de la classe du Controller que vous venez de créer pourront ensuite être liées à vos routes. Voila un exemple:
Route::get('user/show', 'UserController@show');Si vous voulez éviter de devoir spécifier les routes de toutes les actions disponibles dans le controller, vous pouvez utiliser une fonctionnalité de routage pratique grâce à la syntaxe suivante:
Route::controller('news', 'NewsController');Le routage sera ainsi fait automatiquement vers les méthodes de votre controller si elles sont préfixées du verbe HTTP adéquat.
Attention toutefois, si l'url ne correspond pas à une méthode existante du controller, le Framework générera une exception.
Il est aussi très simple de faire des controller RESTful avec le Framework. En effet, celui-ci offre un outils de génération de squelette de code ainsi qu'une gestion des routes RESTful.
Les paramètres envoyé par le client (via HTTP) sont facilement récupérable par les controllers. Le service Request du Framework permet en effet de récupérer les paramètres GET, POST, les cookies, les fichiers (FILE), ... Même les paramètres transmis au format JSON sont récupérables (documentation).
Si l'on suit un des principes de robustesse d'une application, les données reçues par votre application ne sont pas forcément celles que vous vous attendez à recevoir (problème dans la communication, tentative de hack, mauvaise utilisation du coté client, ...). Bref vous vous devez de respecter une règle simple pour les applications Web: filtrer toutes les entrés, échapper toutes les sorties.
Le filtrage des entrées appliqué au MVC, peut être considéré comme une validation des paramètres reçus par le controller ou le model. Tandis que l'échappement des données se fera dans les views lors de la génération du contenu à envoyer au client. Il faudra donc y éviter tous les caractères interdits (ou réservés) dans le format choisit pour l'envoi vers le client (HTML, JSON, et autres) .
Pour la validation des données, le Framework peut vous aider puisqu'il propose une quarantaine de validateurs qui devrait couvrir la majorité des cas (et dans les autres cas, PHP étant un langage de programmation, vous savez ce qu'il reste à faire).
Maintenant, à vous de débattre si la validation des données doit se faire dans les controllers ou dans les models.
La persistance des données des models se fait la plupart du temps en base de données. Les models se comportent souvent comme des Data Table Gateway, offrant des méthodes afin d'obtenir, de modifier ou de supprimer une ou plusieurs entrées de la base de données. Il est alors logique qu'un Framework offre une abstraction de la gestion des requêtes correspondantes. Avec Laravel, cet outil se nomme Eloquent.
Afin d'utiliser cet outil (ce n'est bien sûr pas une obligation du Framework), vos models doivent être des Class qui étendent Model du Framework. Puisque Model est une sorte de Data Table Gateway, les models seront bien sûr liés à des tables de votre base de données. Par défaut, le Framework lie votre classe à une table de la DB portant le même nom que la classe en minuscule et avec un 's' en suffixe. Comme ce n'est pas forcément le comportement adéquat, vous pouvez spécifier un autre nom de table avec la propriété $table. De manière identique, Laravel s'attend à ce que votre clé primaire soit un identifiant technique ayant comme nom de colonne id, si ce n'est pas le cas, vous pouvez spécifier une autre clé primaire avec la propriété $primaryKey (si votre clé primaire est constituée de plusieurs colonnes de votre table, vous pouvez fournir un tableau des noms des colonnes). De plus, Eloquent s'attend à trouver deux colonnes particulières nommées updated_at et created_at lui permettant des fonctionnalités intéressantes liées au timestamp. Si vous ne voulez pas de ces fonctionnalités, ou que vous ne voulez/pouvez pas de ces colonnes additionnelles dans votre table, vous pouvez désactiver ceci en mettant à false la propriété $timestamps.
Une fois votre class définie, vous pourrez l'utiliser n'importe où dans votre code (mais en pratique sans doute uniquement dans vos controllers). Pour la plupart des requêtes SQL basiques, Eloquent vous épargnera l'écriture des requêtes correspondantes et surtout s'occupera dans la bonne syntaxe SQL à utiliser en fonction du type de base de données (MySQL, Postgres, SQLite, ou SQL Server). Voilà un exemple simple du système Eloquent pour récupérer des données via une clé primaire (ici un identifiant technique):
$myNews = News::find(1);Les colonnes de votre table seront alors directement accessible via des propriétés de l'instance $myNews (exemple: $myNews->title). Lorsque Eloquent vous retourne plusieurs lignes de votre table, vous recevez alors une collection contenant toutes les lignes reçues. Exemple:
$news = News::orderBy('created_at', 'desc')->take(2)->get();$news sera alors un tableau contenant les données des deux dernières news.
Laravel offre aussi des outils pour la gestion de vos tables et données de test. Vous pouvez vous passer des ces outils et créer simplement vos tables dans un autre outils de gestion de base de données (phpMyAdmin par exemple), mais ceux de Laravel ont l'avantage de pouvoir gérer une sorte de contrôle de version de votre base.
Vous pouvez ainsi créer des migrations qui auront pour effet de modifier votre base de données quand elles seront exécutées. De plus si vous codez correctement la migration, le système vous permettra d'annuler vos migrations (rollback). Ceci est très utile lorsque vous êtes en environnement de développement, ainsi que pour les mises à jour des bases de données de recette et de production. Vous trouverez toutes les informations utiles sur le site officiel.
Un autre système vous propose des outils de population (seeding) de vos tables. Surtout utile en environnement de développement, ce système vous permet de peupler vos tables de données fictives (ou non) pour vos tests.
Les views doivent se trouver dans le répertoire resources/views. Elles sont la présentation dans un format spécifique de vos données à envoyer au client. Si votre client est un browser, il y a de grande chance que ce format soit du HTML. Les vues sont de simples fichiers php (et non une classe PHP) contenant un minimum de logique applicative comme de simple echo, des if ou des foreach. Attention: il faut bien sûr faire l'échappement de toutes les données lors de leur affichage. Pour cela, vous pouvez utiliser la fonction PHP htmlspecialchars. Voici un exemple simpliste d'un fichier view HTML (nommons le exemple.php):
<!DOCTYPE html>
<html lang="fr">
<head>
<title>Minimal</title>
<meta charset="utf-8">
</head>
<body>
Hello <?php echo htmlspecialchars($username); ?>
</body>
</html>La génération d'une vue se fait simplement avec la syntaxe suivante:
view('exemple', ['username' => 'World']);Le deuxième paramètre permet de passer les données à la view sous la forme de couple clé/valeur. D'autres syntaxes sont possibles (documentation).
L'utilisation des views peut aussi se faire avec un système de templating. Celui fournit avec le Framework s'appelle Blade, mais n'importe quel moteur de template est utilisable.
Pour bien comprendre tous les avantages que vous offre un Framework, le mieux et de le mettre en pratique.
Premièrement avec un exercice sur le routage Laravel.
Ensuite, essayez de créer le squelette (ou plus si vous avez le temps) d'application nécessaire à l'affichage, et la gestion d'une page de news simpliste. Les spécificités sont:
Je vous conseille l'ordre suivant de développement: