Accediendo a la variable de entorno AppKernel en Symfony 2

Question

Estoy usando Symfony 2 y tenemos 2 configuraciones, dev y prod. Necesito saber si puedo averiguar cuál estoy usando dentro de una Entidad o Modelo.

Busco algo similar a este código que se encuentra en AppKernel.php:

$this->getEnvironment() 

Si pudiera cargar el kernel de llamar a este que sería grande, pero no puedo encontrar una manera de hacerlo esta. Después de analizar esto, parece que los eventos de Symfony pueden devolver el Kernel, pero no sé cómo ni dónde capturar estos eventos para poder llamar a getKernel() sobre ellos. http://symfony.com/doc/current/book/internals.html

Por ejemplo, que la lista de este ejemplo:

uso Symfony \ Component \ HttpKernel \ Event \ FilterControllerEvent;

public function onKernelController(FilterControllerEvent $event) 
{ 
    $controller = $event->getController(); 
    // ... 

    // the controller can be changed to any PHP callable 
    $event->setController($controller); 
} 

No tengo claro dónde colocar este bloque de código. Me parece que debería ir en Kernel, y si tuviera Kernel, no estaría teniendo este problema.

Mi pregunta es, ¿existe una manera fácil para mí para determinar si estoy en 'dev' o 'prod' como se establece en el kernel, desde un servicio o modelo. Gracias

Answer 1

Las clases de entidad predeterminadas generadas por la consola no heredan nada. Esto significa que no son "ContainerAware" de ninguna manera.

Y en general, no creo que deberían serlo. Se supone que depende de lo que estás haciendo pero se puede manejar esto con un poco de inyección básica dependencia

En un controlador:

$entity = new \Your\Bundle\Entity\Foo(
    $this->container->get('kernel')->getEnvironment() 
); 

Y luego, en src/Su/Bundle/Entidad/foo.php

private $env; 

public function __construct($env=null) 
{ 
    $this->env = $env; 
} 

¿Funcionaría para usted?

P.S. El oyente del evento sobre el que publicaste es para Controladores, no para clases arbitrarias.

Answer 2

También es posible obtener eso como un parámetro. Si echa un vistazo a la clase \Symfony\Component\HttpKernel\Kernel, encontrará un método getKernelParameters() que expone todos los parámetros del kernel.

/** 
* Returns the kernel parameters. 
* 
* @return array An array of kernel parameters 
*/ 
protected function getKernelParameters() 
{ 
    $bundles = array(); 
    foreach ($this->bundles as $name => $bundle) { 
     $bundles[$name] = get_class($bundle); 
    } 

    return array_merge(
     array(
      'kernel.root_dir' => realpath($this->rootDir) ?: $this->rootDir, 
      'kernel.environment' => $this->environment, 
      'kernel.debug' => $this->debug, 
      'kernel.name' => $this->name, 
      'kernel.cache_dir' => realpath($this->getCacheDir()) ?: $this->getCacheDir(), 
      'kernel.logs_dir' => realpath($this->getLogDir()) ?: $this->getLogDir(), 
      'kernel.bundles' => $bundles, 
      'kernel.charset' => $this->getCharset(), 
      'kernel.container_class' => $this->getContainerClass(), 
     ), 
     $this->getEnvParameters() 
    ); 
} 

Así que en un archivo services.yml puede obtener el medio ambiente con %kernel.environment% mientras que en una clase consciente de contenedores lo puede conseguir haciendo:

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

see Kernel.php class on github

Answer 3

Por supuesto que es la rápida y sucia forma de globos globales ...

function quickAndDirty() { 
    global $kernel; 

    if ($kernel->getEnvironment() == 'dev') { 
     // we're in dev mode 
    } 
} 

Su mal y el mal y que debe lavarse después de usarlo, pero en el caso de una gran base de código existente que quizá heredado, se ahorra una potencial pesadilla refactorización.

Por supuesto, si se puede vivir con uno mismo después de usar un método de este tipo, depende de usted;)