Recherche…
Introduction
Exemples et bonnes pratiques pour configurer votre application Symfony qui ne figurent pas dans la documentation officielle.
Inclure tous les fichiers de configuration d'un répertoire
Après un certain temps, vous obtenez de nombreux éléments de configuration dans votre config.yml. Il peut vous rendre la configuration plus facile à lire si vous divisez votre configuration sur plusieurs fichiers. Vous pouvez facilement inclure tous les fichiers d'un répertoire de cette manière:
config.yml:
imports:
- { resource: parameters.yml }
- { resource: "includes/" }
Dans le includes
répertoire que vous pouvez mettre par exemple doctrine.yml, swiftmailer.yml, etc.
Utiliser le nom de classe complet (FQCN) comme identifiant de service
Dans de nombreux exemples, vous trouverez un identifiant de service tel que "acme.demo.service.id" (une chaîne avec des points). Votre services.yml
ressemblera à ceci:
services:
acme.demo.service.id:
class: Acme\DemoBundle\Services\DemoService
arguments: ["@doctrine.orm.default_entity_manager", "@cache"]
Dans votre contrôleur, vous pouvez utiliser ce service:
$service = $this->get('acme.demo.service.id');
Bien qu'il n'y ait pas de problème avec cela, vous pouvez utiliser un nom de classe pleinement qualifié (FQCN) comme identifiant de service:
services:
Acme\DemoBundle\Services\DemoService:
class: Acme\DemoBundle\Services\DemoService
arguments: ["@doctrine.orm.default_entity_manager", "@cache"]
Dans votre contrôleur, vous pouvez l'utiliser comme ceci:
use Acme\DemoBundle\Services\DemoService;
// ..
$this->get(DemoService::class);
Cela rend votre code plus compréhensible. Dans de nombreux cas, cela n'a aucun sens d'avoir un identifiant de service qui n'est pas seulement le nom de la classe.
A partir de Symfony 3.3, vous pouvez même supprimer l'attribut class
si votre identifiant de service est un FQCN.
Aucune interface HTTP nécessaire?
Si votre application n'a besoin d'aucune interface HTTP (par exemple pour une application uniquement console), vous souhaiterez désactiver au moins Twig
et SensioFrameworkExtra
Juste commenter ces lignes:
app / AppKernel.php
$bundles = [
//...
// new Symfony\Bundle\TwigBundle\TwigBundle(),
// new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
//...
if (in_array($this->getEnvironment(), ['dev', 'test'], true)) {
//...
// $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
app / config / config.yml
framework:
# ...
# router:
# resource: '%kernel.root_dir%/config/routing.yml'
# strict_requirements: ~
# ...
# templating:
# engines: ['twig']
#...
#twig:
# debug: '%kernel.debug%'
# strict_variables: '%kernel.debug%'
app / config / config_dev.yml
#framework:
# router:
# resource: '%kernel.root_dir%/config/routing_dev.yml'
# strict_requirements: true
# profiler: { only_exceptions: false }
#web_profiler:
# toolbar: true
# intercept_redirects: false
Vous pouvez également supprimer les exigences de fournisseur connexes de composer.json :
"sensio/framework-extra-bundle": "x.x.x",
"twig/twig": "x.x"
L'utilisation de Symfony dans un tel cas est discutable, mais au moins cela peut être temporaire.