Mentre la soluzione di spostare il contact_email-parameters.yml è facile, come proposto in altre risposte, che può facilmente ingombrare i parametri di file se avete a che fare con molte pacchetti o se gestisci blocchi di configurazione annidati.
- In primo luogo, risponderò rigorosamente alla domanda.
- Successivamente, darò un approccio per ottenere tali configurazioni dai servizi senza passare mai attraverso uno spazio comune come parametri.
primo approccio: blocco config separato, ottenendo come parametro
Con un prolungamento (more on extensions here) questa può essere mantenuta facilmente "separati" in vari blocchi nella config.yml e poi iniettare che come parametro ricavato dal controller.
Dentro la classe di estensione all'interno della directory DependencyInjection scrivere questo:
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
}
Poi, nel tuo config.yml, config_dev.yml e in modo da poter impostare
my_nice_project:
contact_email: [email protected]
Per essere in grado di elaborare che config.yml all'interno del tuo MyNiceBundleExtension avrai anche bisogno di una classe Configuration nello stesso spazio dei nomi:
class Configuration implements ConfigurationInterface
{
public function getConfigTreeBuilder()
{
$treeBuilder = new TreeBuilder();
$rootNode = $treeBuilder->root('my_nice_project');
$rootNode->children()->scalarNode('contact_email')->end();
return $treeBuilder;
}
}
allora si può ottenere la configurazione dal controller, come avete voluto nella tua domanda iniziale, ma mantenendo il parameters.yml pulita, e l'impostazione nel config.yml in sezioni separate:
$recipient = $this->container->getParameter('my_nice_project.contact_email');
secondo approccio: Separato blocco config, iniettando la configurazione in un servizio
per i lettori alla ricerca di qualcosa di simile, ma per ottenere la configurazione da un servizio, v'è anche un modo più bello che mai ingombra il "paramaters" spazio comune e che addirittura non hanno bisogno della container da passare al servizio (passare l'intero container è una pratica da evitare).
Questo trucco sopra ancora "inietta" nei parametri dello spazio di configurazione.
Tuttavia, dopo aver caricato la definizione del servizio, è possibile aggiungere un metodo-chiamata come ad esempio setConfig() che inietta tale blocco solo per il servizio.
Per esempio, nella classe di estensione:
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' ]));
}
}
Poi, nel tuo services.yml si definisce il vostro servizio, come al solito, senza alcuna variazione assoluta:
services:
my.niceproject.sillymanager:
class: My\NiceProjectBundle\Model\SillyManager
arguments: []
E poi nella classe SillyManager, basta aggiungere il metodo:
class SillyManager
{
private $contact_email;
public function setConfig($newConfigContactEmail)
{
$this->contact_email = $newConfigContactEmail;
}
}
Nota tha questo funziona anche per gli array al posto dei valori scalari!Immaginate che si configura una coda di coniglio e bisogno di accoglienza, utente e password:
my_nice_project:
amqp:
host: 192.168.33.55
user: guest
password: guest
Naturalmente è necessario cambiare il vostro albero, ma allora si può fare:
$sillyServiceDefintion->addMethodCall('setConfig', array($processedConfig[ 'amqp' ]));
e poi nel servizio fare :
class SillyManager
{
private $host;
private $user;
private $password;
public function setConfig($config)
{
$this->host = $config[ 'host' ];
$this->user = $config[ 'user' ];
$this->password = $config[ 'password' ];
}
}
Spero che questo aiuti!
Come funzionerebbe con gli ambienti Dev/Prod? Quindi per i test voglio che le e-mail vengano inviate a una e-mail di prova e la produzione riceverà un'altra email –
@Phill: Se si utilizza lo swiftmailer standard in symfony2, è possibile utilizzare la seguente impostazione nel file config_dev.yml: 'swiftmailer: delivery_address: dev @ example.com 'Puoi trovare maggiori informazioni nel [ricettario di Symfony2] (http://symfony.com/doc/current/cookbook/email/dev_environment.html) – Pierre
Devo inserire il container class ovunque (controller, entità, classe) quando uso questa dichiarazione ** $ this-> container-> getParameter ('contact_email'); **? o c'è un modo più semplice per farlo senza iniettare classe contenitore? – webblover