# Environnements

Une application peut fonctionner différemment en fonction de l'environnement courant. Symfony propose de base 3 environnements:

• dev: lorsque l'on travaille sur l'application
• test: lors de l'exécution de tests automatisés
• prod: l'environnement de production, lorsque l'application est en ligne

Cette distinction est nécessaire car vous aurez besoin d'activer ou désactiver certains comportements en fonction de l'environnement.

Exemple de comportement: envoi d'email à l'adresse de utilisateur@mail.org

• prod: on envoie l'email à l'adresse indiquée, il faut que l'utilisateur reçoive réellement cet email
• dev: vous testez une fonctionnalité, vous ne voulez pas réellement envoyer cet email à l'utilisateur, vous allez plutôt l'envoyer sur une boite mail de test durant le développement.
• test: vous voulez seulement tester que l'envoi d'email se fasse, vous aller donc désactiver l'envoi de l'email pour ne pas polluer votre boite mail de test

Le choix de l'environnement se fait par une variable d'environnement nommée APP_ENV. Par défaut elle est configurée sur dev et déclarée dans le fichier .env:

###> symfony/framework-bundle ###
APP_ENV=dev
APP_SECRET=6326be4fb3ca566b696a646a45e46a38
###< symfony/framework-bundle ###

Ces lignes ont été ajoutées par la recipe de symfony/framework-bundle. D'autres bundles pourront ajouter des variables d'environnement mais vous pouvez parfaitement créer les vôtres.

Notez que comme indiqué vers le début du fichier, vous pouvez disposer de plusieurs fichiers de variables d'environnement qui peuvent se surcharger entre eux:

#  * .env                           contains default values for the environment variables needed by the app
#  * .env.local                   uncommitted file with local overrides
#  * .env.$APP_ENV          committed environment-specific defaults
#  * .env.$APP_ENV.local  uncommitted environment-specific overrides

Puisque nous sommes en environnement de dev, vous pourriez surcharger le fichier principal avec un fichier .env.dev. Les fichiers se terminant par .local sont ignorés par Git, ils permettent de surcharger localement les variables si vous avez une configuration différente de vos collègues.

# Bundles

# Activation

La liste des bundles activés dans l'application se trouve dans le fichier /config/bundles.php qui contient actuellement l'unique bundle installé pour le framework:

return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
];

Certains bundles n'étant utiles que pour le développement ou les tests, ils peuvent être activés par environnement. Ici FrameworkBundle est nécessaire peu importe l'environnement. Si un bundle était nécessaire uniquement et dev et test, nous aurions:

return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    Package\BundleImaginaire::class => ['dev' => true, 'test' => true],
];

# Configuration

La configuration des bundles se situe dans /config/packages/ sous la forme de fichiers YAML. Le nom des fichiers n'a absolument aucune importance, les fichiers cache.yaml, framework.yaml et routing.yaml actuellement présents concernent tous le FrameworkBundle.

Ouvrez le fichier framework.yaml:

# see https://symfony.com/doc/current/reference/configuration/framework.html
framework:
    secret: '%env(APP_SECRET)%'
    #csrf_protection: true
    http_method_override: false

    # Enables session support. Note that the session will ONLY be started if you read or write from it.
    # Remove or comment this section to explicitly disable session support.
    session:
        handler_id: null
        cookie_secure: auto
        cookie_samesite: lax
        storage_factory_id: session.storage.factory.native

    #esi: true
    #fragments: true
    php_errors:
        log: true

when@test:
    framework:
        test: true
        session:
            storage_factory_id: session.storage.factory.mock_file

La ligne 2 indique en clé de premier niveau framework, c'est ce qui va indiquer à Symfony que la configuration correspond au FrameworkBundle, peu importe le nom du fichier.
La clé secret à la ligne 3 utilise une syntaxe particulière %env()% pour récupérer la variable d'environnement APP_SECRET.
La ligne 20 indique une surcharge de la configuration pour l'environnement de test grâce à la syntaxe when@.

# Routing

Symfony est un framework basé sur l'architecture MVC (Model, View, Controller), une "page" dans l'application ne correspond pas à un fichier PHP comme on pourrait le faire avec une application PHP procédurale.
On fonctionnera à la place avec des routes: un chemin qui va correspondre à un controlleur.

Exemple: le chemin /connexion exécuteraAuthentificationController::connexion().

Une de manières d'ajouter des routes de l'application est de les déclarer dans le /config/routes.yaml dans lequel se trouve un exemple commenté.

Note: nous déclarerons nos routes différemment, directement dans les controlleurs.

Les bundles peuvent également ajouter des routes à votre application !
Dans /config/routes/ vous trouverez un fichier framework.yaml qui déclare des routes pour tester les pages d'erreur en environnement de développement:

when@dev:
    _errors:
        resource: '@FrameworkBundle/Resources/config/routing/errors.xml'
        prefix: /_error

Ouvrez un onglet à l'adresse http://localhost:8000/_error/503 pour voir la page d'erreur par défaut avec le message correspondant à l'erreur HTTP 503.

# Services

La pièce maîtresse de la configuration est le fichier /config/services.yaml: la définition de vos services !

La première clé parameters vous permet de déclarer des paramètres pour configurer votre application. Ils seront stockés dans le conteneur de services. Vous pourrez ensuite les récupérer dans vos services mais le plus intéressant est leur réutilisation dans la configuration YAML (de vos services et dans les bundles) avec la syntaxe %mon_parametre%.

La clé services correspond à la configuration de vos services. Le bloc App\ rend la plupart des classes dans /src/ disponibles en tant que services.