Mientras que la solución de mover el contact_email a parameters.yml es fácil, tal como se propone en otras respuestas, que pueden Clutter fácilmente los parámetros del archivo si usted trata con muchos paquetes o si se trata de bloques de configuración anidados.
- En primer lugar, voy a responder estrictamente a la pregunta.
- Más adelante, daré un enfoque para obtener esas configuraciones de los servicios sin pasar por un espacio común como parámetros.
primera aproximación: bloque de configuración Separado, obteniendo como parámetro
Con una extensión (more on extensions here) se puede mantener esto fácilmente "separados" en diferentes bloques en el config.yml y luego inyectar que, como parámetro gettable desde el controlador.
Dentro de la clase de extensión dentro del directorio DependencyInjection escribir esto:
class MyNiceProjectExtension extends Extension
{
public function load(array $configs, ContainerBuilder $container)
{
// The next 2 lines are pretty common to all Extension templates.
$configuration = new Configuration();
$processedConfig = $this->processConfiguration($configuration, $configs);
// This is the KEY TO YOUR ANSWER
$container->setParameter('my_nice_project.contact_email', $processedConfig[ 'contact_email' ]);
// Other stuff like loading services.yml
}
Luego, en su config.yml, config_dev.yml y por lo tanto se puede establecer
my_nice_project:
contact_email: [email protected]
Para poder procesar esa config.yml dentro de su MyNiceBundleExtension también necesitará una clase Configuration en el mismo espacio de nombres:
class Configuration implements ConfigurationInterface
{
public function getConfigTreeBuilder()
{
$treeBuilder = new TreeBuilder();
$rootNode = $treeBuilder->root('my_nice_project');
$rootNode->children()->scalarNode('contact_email')->end();
return $treeBuilder;
}
}
entonces se puede obtener la configuración de su controlador, como usted desee en su pregunta original, pero manteniendo el parameters.yml limpio, y se establece en el config.yml en secciones separadas:
$recipient = $this->container->getParameter('my_nice_project.contact_email');
segundo enfoque: Separado config block, inyectando la configuración en un servicio
Para lectores que buscan algo similar, pero para obtener la configuración de un servicio, hay incluso una manera más agradable que nunca ocupa el espacio común de "parámetros" e incluso no necesita el container para pasar al servicio (pasar el contenedor entero es una práctica para evitar).
Este truco anterior todavía "inyecta" en los parámetros de espacio de su configuración.
Sin embargo, después de cargar su definición del servicio, puede agregar una llamada a un método como por ejemplo setConfig() que inyecta ese bloque solo al servicio.
Por ejemplo, en la clase Extensión:
class MyNiceProjectExtension extends Extension
{
public function load(array $configs, ContainerBuilder $container)
{
$configuration = new Configuration();
$processedConfig = $this->processConfiguration($configuration, $configs);
// Do not add a paramater now, just continue reading the services.
$loader = new YamlFileLoader($container, new FileLocator(__DIR__ . '/../Resources/config'));
$loader->load('services.yml');
// Once the services definition are read, get your service and add a method call to setConfig()
$sillyServiceDefintion = $container->getDefinition('my.niceproject.sillymanager');
$sillyServiceDefintion->addMethodCall('setConfig', array($processedConfig[ 'contact_email' ]));
}
}
Luego, en su services.yml a definir su servicio como de costumbre, sin ningún cambio absoluto:
services:
my.niceproject.sillymanager:
class: My\NiceProjectBundle\Model\SillyManager
arguments: []
Y luego en su clase SillyManager, justo agregue el método:
class SillyManager
{
private $contact_email;
public function setConfig($newConfigContactEmail)
{
$this->contact_email = $newConfigContactEmail;
}
}
Nota tha ¡Esto también funciona para matrices en lugar de valores escalares!Imagínese que configure una cola de conejo y necesita anfitrión, usuario y contraseña:
my_nice_project:
amqp:
host: 192.168.33.55
user: guest
password: guest
Por supuesto que necesita para cambiar su árbol, pero luego se puede hacer:
$sillyServiceDefintion->addMethodCall('setConfig', array($processedConfig[ 'amqp' ]));
y luego en el servicio de hacer :
class SillyManager
{
private $host;
private $user;
private $password;
public function setConfig($config)
{
$this->host = $config[ 'host' ];
$this->user = $config[ 'user' ];
$this->password = $config[ 'password' ];
}
}
Espero que ayude!
¿Cómo funcionaría esto con los entornos Dev/Prod? Entonces para probar quiero que los correos electrónicos se envíen a un correo electrónico de prueba y la producción reciba otro correo electrónico –
@Phill: Si está utilizando el swiftmailer estándar en su symfony2, puede usar la siguiente configuración en su config_dev.yml: 'swiftmailer: delivery_address: dev @ example.com' Puede encontrar más información en el [Symfony2 cookbook] (http://symfony.com/doc/current/cookbook/email/dev_environment.html) – Pierre
Debería inyectar una clase de contenedor en todas partes (controlador, entidad, clase) cuando uso esta declaración ** $ this-> container-> getParameter ('contact_email'); **? o hay una manera más simple de hacerlo sin inyectar clase de contenedor? – webblover