III. Chapitre 3 : Architecture et configuration▲
Nous allons maintenant voir comment est organisé Laravel 4. À l'issue de l'installation nous avons quelques fichiers et quatre dossiers :
Le dossier public est le seul qui doit être accessible à l'utilisateur. C'est le dossier qui va héberger vos images, vos fichiers CSS, vos scripts.
Le dossier vendor contient toutes les bibliothèques utilisées par Laravel et vous n'avez normalement pas à intervenir directement dans celles-ci.
Le dossier app est celui qui va contenir votre application, c'est votre terrain de jeu, vous y mettrez vos modèles, vos contrôleurs, vos vues, vos assets.
Le dossier bootstrap contient des fichiers qui gèrent le démarrage de Laravel.
Voici un schéma résumé de cette organisation :
III-A. Le dossier public▲
Au départ ce dossier ne contient pas grand-chose, essentiellement le fichier index.php qui est la porte d'entrée de l'application et un fichier .htaccess :
Il contient aussi un fichier d'icône vide favicon.ico. Les navigateurs cherchent par défaut ce fichier pour afficher l'icône du site. Vous pouvez donc l'adapter à vos besoins (une image de 16 * 16 px).
Il contient aussi le fichier robots.txt qui indique aux robots d'indexation de sites les pages qu'ils doivent explorer. Par défaut tout est indexé. Si vous désirez un comportement différent, vous devez renseigner ce fichier en conséquence.
III-A-1. Le fichier index.php▲
C'est la porte d'entrée unique de l'application. Il ne contient que très peu de code dont voici l'essentiel :
-
Lancement du chargement automatique créé par Composer :
Sélectionnezrequire __DIR__
.
'
/../bootstrap/autoload.php
'
;
-
Inclusion du fichier de démarrage :
Sélectionnez$app
=
require_once __DIR__.
'
/../bootstrap/start.php
'
;
-
Lancement de l'application :
Sélectionnez$app
->
run();
- Et pour finir :
$app
->
shutdown();
Vous voyez donc que l'essentiel de la machinerie se situe dans la partie cachée.
III-A-2. Le dossier app▲
C'est le dossier dans lequel vous allez créer votre application, il contient deux fichiers et il est subdivisé en sous-dossiers.
Voyons d'abord les deux fichiers :
- routes : contient les définitions des chemins d'entrées pour l'utilisateur, autrement dit les URI possibles et les dirige sur la classe qui doit traiter l'information ;
- filters : contient les définitions des filtres appliqués aux chemins, autrement dit les actions à effectuer juste avant ou après.
Voyons maintenant les dossiers :
- commands : prévu pour contenir vos commandes personnelles pour « Artisan », un utilitaire en ligne de commande de Laravel ;
- config : contient des éléments de configuration pour changer l'aspect et le fonctionnement de Laravel ;
- controllers : contient les contrôleurs (schéma MVC). Il est à noter que l'utilisation de contrôleurs n'est pas indispensable avec ce framework parce que le système de routage est très performant comme nous le verrons par la suite ;
- lang : contient des fichiers avec du texte évidemment en anglais à la base ;
- models : contient les classes qui représentent le modèle de données de l'application (schéma MVC) ;
- start : contient les fichiers de démarrage de votre application ;
- storage : stockage d'informations temporaires diverses : sessions, logs, vues compilées, caches…
- views : contient les vues, ce sont les fichiers destinés à présenter la réponse à l'utilisateur (schéma MVC), utilisées par les routes et les contrôleurs ;
- tests : pour vos tests unitaires à lancer avec Artisan ;
- database : contient les migrations (modifications de la base de données) et les seeds (remplissage des données).
III-A-3. Configuration▲
Laravel nécessite très peu de configuration. Ouvrez le fichier app/config/app.php et trouvez cette ligne :
'
key
'
=>
'
YourSecretKey!!!
'
,
Ici vous devez entrer votre clé secrète composée de 32 caractères alphanumériques. Il est possible d'en créer une dans l'invite de commande avec l'outil « Artisan ». Pour le moment vous pouvez l'utiliser pour générer la clé :
La clé est directement inscrite dans le fichier app/config/app.php.
Vous trouvez dans le même fichier cette ligne :
'
locale
'
=>
'
en
'
,
Évidemment vous pouvez entrer fr à la place, mais auparavant il aura fallu prévoir les fichiers correspondant avec la traduction ! Nous verrons cela plus tard, pour le moment laissez en.
Laravel est prévu à la base avec un fichier .htaccess pour ne pas voir apparaître index.php dans les URL :
2.
3.
4.
5.
6.
7.
<IfModule mod_rewrite.c>
Options
-MultiViews
RewriteEngine
On
RewriteCond
%{REQUEST_FILENAME} !-d
RewriteCond
%{REQUEST_FILENAME} !-f
RewriteRule
^ index.php [L]
</IfModule>
Mais évidemment ça ne fonctionne que si le module mod_rewrite est activé dans votre version d'Apache. Si ce n'est pas le cas, il faudra supporter des URI plus longs et moins esthétiques…
III-A-4. L'environnement▲
Selon l'environnement dans lequel nous utilisons Laravel, nous n'avons pas les mêmes besoins. Par exemple nous allons éviter d'avoir des erreurs qui s'affichent sur un serveur de production alors que l'affichage des erreurs est utile lors du développement. Si nous utilisons une base de données elle ne sera pas forcément en localhost en production. En cours de développement nous voudrons aussi sans doute intercepter l'envoi des emails.
Regardez ce code dans le fichier bootstrap/start.php :
Laravel détecte automatiquement l'environnement dans lequel il s'exécute. C'est ici qu'il va regarder pour définir l'environnement. On se rend compte qu'il a pour le moment peu de choix.
homestead fait référence à un environnement Vagrant disponible pour Laravel depuis la version 4.2.
C'est à vous de définir les environnements dont vous avez besoin. En général il vous suffit d'un environnement local de développement. Par exemple :
Ici j'ai défini l'environnement local en spécifiant le nom de ma machine (ce que retourne la fonction gethostname()). Il existe un dossier app/config/local. Il suffit de mettre dans ce dossier les fichiers de configuration avec seulement les valeurs que l'on veut spécifier. Par défaut il y a déjà un fichier app/php qui fixe la valeur du debug (débogage) à true. Il y a aussi un fichier database.php parce que forcément la configuration de la base sera différente en local et à distance.
Depuis la version 4.1 on ne prend plus en compte l'URL comme référence à cause de problèmes de sécurité.