web-dev-qa-db-fra.com

Vérifier si en mode "dev" dans un contrôleur avec Symfony

Lorsque vous utilisez le mode dev avec une application Symfony2.x, on travaille généralement en locale. Par conséquent, une telle fonction ne fonctionne pas comme prévu (par exemple, essayez d'obtenir l'adresse IP actuelle sous localhost). Cela pourrait être un problème, par exemple quand on essaie d'utiliser un tel service Web basé sur ip. Par conséquent, je veux juste savoir comment vérifier à l'intérieur d'un contrôleur si l'application Symfony2 fonctionne en mode dev ou non. De cette façon, on peut définir le comportement du contrôleur en fonction du mode.

Une idée?

39
JeanValjean

Pour obtenir l'environnement actuel dans un Controller, vous pouvez utiliser:

$this->container->getParameter('kernel.environment');

Vous venez donc de mettre cela dans une instruction if() pour vérifier si elle est égale à dev.

55
tolgap

Depuis Symfony 2.5 cela pourrait se faire comme:

$this->container->get('kernel')->getEnvironment();

Demander directement au noyau son environnement est plus agréable que de rechercher un paramètre.

26
Damaged Organic

Puisque vous voulez savoir si vous êtes en mode dev (pas nécessairement l'environnement nommé "dev"), vous pouvez récupérer le noyau du conteneur de service et vérifier la méthode isDebug return:

$kernel = $this->get('kernel');
$devMode = $kernel->isDebug();

Comme indiqué dans la documentation (c'est moi qui souligne),

L'argument true ou false est le deuxième argument du constructeur AppKernel, mais n'est pas lié au sujet des environnements. Ceci spécifie si l'application doit s'exécuter en "mode débogage". Quel que soit l'environnement, une application Symfony peut être exécutée avec le mode de débogage défini sur vrai ou faux . Cela affecte de nombreuses choses dans l'application, telles que l'affichage des traces de pile sur les pages d'erreur ou si les fichiers de cache sont reconstruits dynamiquement à chaque demande. Bien qu'il ne soit pas obligatoire, le mode de débogage est généralement défini sur true pour les environnements de développement et de test et false pour l'environnement de prod.

En interne, la valeur du mode débogage devient le paramètre kernel.debug utilisé à l'intérieur du conteneur de service.

15
Veve

Voici la version 2017 et Symfony 3.3 + utilisant l'injection de constructeur .

Au lieu de passer votre application entière (= conteneur), vous pouvez passer uniquement le paramètre dont vous avez besoin :

1. Configuration du service

# app/config/services.yml
services:
    _defaults:
        autowire: true

    App\Controller\SomeController:
        arguments: ['%kernel.environment%']

Si vous ne comprenez pas cette syntaxe, consultez cet article expliquant les nouvelles de Symfony DI dans les exemples avant/après .

2. Le contrôleur

namespace App\Controller;

final class SomeController
{
    /**
     * @var string
     */
    private $environment;

    public function __construct(string $environment)
    {
        $this->environment = $environment;
    }

    public function someAction()
    {
        $this->environment...
        // any operations you need
    }
}


Pourquoi éviter de passer Container dans Controller?

La chose la plus importante dans le code est la cohérence .

  • Si vous préférez les localisateurs statiques et de service (= service que vous pouvez passer n'importe où pour obtenir un autre service), utilisez-le.

  • Si vous préférez l'injection de constructeur, le graphique de dépendance d'arbre (! = Dépendances circulaires), utilisez-le.

Mélanger ce concept pourrait vous convenir, si vous savez pourquoi vous les avez utilisés de cette façon. Mais voici venir jouer The Broken Window Theory (version joliment décrite par Coding Horror) . Toute personne venant au code choisira plus probablement la version qui n'est pas destinée à être utilisée de cette façon .

L'ambiguïté dans le code est la première invitation au code hérité

J'ai encadré des équipes de nombreuses applications, qui ont commencé par un simple $this->container dans le code et après quelques années, j'ai fini par m'appeler à l'aide, comment réécrire ou refactoriser tout l'enfer statique.

10
Tomáš Votruba

De Symfony 4.1 à l'intérieur du service

class MyService
{
    private $params;
    public function __construct(ParameterBagInterface $params)
    {
        $this->params = $params;
    }
    public function check($e)
    {
       if($this->params->get("kernel.environment") === "dev") 
       {
            return true;
       }
    }
}
3
Martin Kozibratka

Pour Symfony 4.x et supérieur

Si vous utilisez .env Pour stocker vos variables d'environnement, vous pouvez y accéder dans n'importe quel contrôleur en utilisant simplement $_ENV['name-of-variable']

Pour une installation par défaut, une variable $_ENV["APP_ENV"] Est disponible, qui vous indiquera si vous êtes en mode dev ou non.


Utilisez print_r($_ENV); pour voir toutes les variables d'environnement disponibles.

[ps - Cela fonctionne aussi pour Symfony 3.4]

0
Niket Pathak