Flag of Ukraine
SymfonyCasts stands united with the people of Ukraine

Bundle Config (para controlar los servicios de bundle)

Video not working?

It looks like your browser may not support the H264 codec. If you're using Linux, try a different browser or try installing the gstreamer0.10-ffmpeg gstreamer0.10-plugins-good packages.

Thanks! This saves us from needing to use Flash or encode videos in multiple formats. And that let's us get back to making more videos :). But as always, please feel free to message us.

Ahora utilizamos los servicios HttpClientInterface y CacheInterface. ¡Sí! Pero en realidad no somos responsables de instanciar estos objetos de servicio. No, los crea otra cosa (hablaremos de ello en unos minutos), y luego nos los pasa.

Eso está muy bien, porque todos estos servicios -las "herramientas" de nuestra aplicación- vienen listos para usar, listos para usar. Pero... si otra cosa se encarga de instanciar estos objetos de servicio, ¿cómo podemos controlarlos?

Presentamos: ¡la configuración del bundle!

Configuración del bundle

Ve a ver el directorio config/packages/. Este tiene un número de diferentes archivos YAML, todos los cuales son cargados automáticamente por Symfony cuando se inicia por primera vez. Todos estos archivos tienen exactamente un propósito: configurar los servicios que nos proporciona cada bundle.

Abre twig.yaml. Por ahora, ignora este when@test: hablaremos de ello en unos minutos. Este archivo tiene una clave raíz llamada twig. Y, por tanto, todo el propósito de este archivo es controlar los servicios que proporciona el bundle "Twig". Y, no es el nombre del archivo - twig.yaml - lo que es importante. Podría renombrar esto comopineapple_pizza.yaml y funcionaría exactamente igual y sería delicioso, no me importa lo que pienses.

Cuando Symfony carga este archivo, ve esta clave raíz - twig - y dice:

Oh, vale. Voy a pasar la configuración que haya debajo a TwigBundle.

¡Y recuerda! Los bundles nos dan servicios. Gracias a esta configuración, cuando TwigBundle está preparando sus servicios, Symfony le pasa esta configuración y TwigBundle la utiliza para decidir cómo deben instanciarse sus servicios... como qué nombres de clase usar para cada servicio... o qué primer segundo o tercer argumento del constructor pasar.

Por ejemplo, si cambiáramos el default_path por algo como%kernel.project_dir%/views, el resultado es que el servicio Twig que genera plantillas estaría ahora preconfigurado para buscar en ese directorio.

La cuestión es: la configuración de estos archivos nos da el poder de controlar los servicios que proporciona cada bundle.

Veamos otro: framework.yaml. Como la clave raíz esframework, toda esta configuración se pasa a FrameworkBundle... que la utiliza para configurar los servicios que proporciona.

Y, como he mencionado, el nombre del archivo no importa... aunque el nombre suele coincidir con la clave raíz... sólo por razones de cordura: como framework y framework.yaml. Pero no siempre es así. Abre cache.yaml. ¡Woh! Esto es... ¡más configuración para FrameworkBundle! Vive en su propio archivo... sólo porque es bueno tener un archivo separado para controlar la caché.

Depuración de la configuración del bundle disponible

Llegados a este punto, puede que te preguntes:

Vale, genial... pero ¿qué claves de configuración podemos poner aquí? ¿Dónde puedo encontrar qué opciones están disponibles?

¡Gran pregunta! Porque... no puedes "inventar" las claves que quieras: eso daría un error. En primer lugar, sí, puedes, por supuesto, leer la documentación. Pero hay otra manera: y es una de mis cosas favoritas del sistema de configuración de Symfony.

Si quieres saber qué configuración puedes pasar al bundle "Twig", hay dos comandos debin/console que te ayudarán. El primero es:

php bin/console debug:config twig

Esto imprimirá toda la configuración actual bajo la clave twig, incluyendo cualquier valor por defecto que el bundle esté añadiendo. Puedes ver que nuestrodefault_path está configurado en el directorio templates/, que proviene de nuestro archivo de configuración. Este %kernel.project_dir% es sólo una forma elegante de apuntar a la raíz de nuestro proyecto. Más adelante hablaremos de ello.

Prueba esto: cambia el valor a views, vuelve a ejecutar ese comando y... ¡sí! Vemos "views" en la salida. Déjame que vuelva a cambiarlo.

Así que debug:config nos muestra toda la configuración actual de un bundle específico, como twig... lo que es especialmente útil porque también te muestra los valores predeterminados añadidos por el bundle. Es una buena manera de ver lo que puedes configurar. Por ejemplo, ¡aparentemente podemos añadir una variable global a Twig mediante esta clave globals!

El segundo comando es similar: en lugar de debug:config, es config:dump:

php bin/console config:dump twig

debug:config te muestra la configuración actual... pero config:dumpte muestra un árbol gigante de configuración de ejemplo, que incluye todo lo que es posible. Aquí puedes ver globals con algunos ejemplos de cómo podrías utilizar esa tecla. Esta es una gran manera de ver todas las opciones potenciales que puedes pasar a un bundle... para ayudarle a configurar sus servicios.

Utilicemos este nuevo conocimiento para ver si podemos "enseñar" al servicio de caché a almacenar sus archivos en otro lugar. Eso a continuación.

Leave a comment!

2
Login or Register to join the conversation
BYT Avatar
BYT Avatar BYT | posted hace 6 meses | edited

I want to keep the controller, templates, forms, css and js all in one folder to organize them together in one folder because they are easy to find. When there are thousands of them and spread out across different folder then it's not easy to find them all work on. How can I have that setup? The common templates could stay in the default templates folder.

Reply

Hey BYT,

That will be difficult to achieve because as templates everything in Symfony should be in its specific directory. Form types in src/, CSS and JS files - in assets/, Twig templates - in the templates/ dir, etc. So, I would recommend you to keep everything in its own place.. but use a specific naming. For example, if you have a form named RegistrationForm.php - you can related files in next folders:

  • src/Form/RegistrationForm.php
  • templates/form/registration.html.twig
  • assets/form/registration.js
  • assets/form/registration.css

So as you can see, every file named "registration" and I suppose you will be able to find related files very easily. Or, alternatively, you can name folders instead of files, something like:

  • assets/registration/form.js
  • assets/registration/form.css
  • etc.

I hope this helps!

Cheers!

Reply
Cat in space

"Houston: no signs of life"
Start the conversation!

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": ">=8.1",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "knplabs/knp-time-bundle": "^1.18", // v1.19.0
        "symfony/asset": "6.1.*", // v6.1.0-RC1
        "symfony/console": "6.1.*", // v6.1.0-RC1
        "symfony/dotenv": "6.1.*", // v6.1.0-RC1
        "symfony/flex": "^2", // v2.1.8
        "symfony/framework-bundle": "6.1.*", // v6.1.0-RC1
        "symfony/http-client": "6.1.*", // v6.1.0-RC1
        "symfony/monolog-bundle": "^3.0", // v3.8.0
        "symfony/runtime": "6.1.*", // v6.1.0-RC1
        "symfony/twig-bundle": "6.1.*", // v6.1.0-RC1
        "symfony/ux-turbo": "^2.0", // v2.1.1
        "symfony/webpack-encore-bundle": "^1.13", // v1.14.1
        "symfony/yaml": "6.1.*", // v6.1.0-RC1
        "twig/extra-bundle": "^2.12|^3.0", // v3.4.0
        "twig/twig": "^2.12|^3.0" // v3.4.0
    },
    "require-dev": {
        "symfony/debug-bundle": "6.1.*", // v6.1.0-RC1
        "symfony/maker-bundle": "^1.41", // v1.42.0
        "symfony/stopwatch": "6.1.*", // v6.1.0-RC1
        "symfony/web-profiler-bundle": "6.1.*" // v6.1.0-RC1
    }
}
userVoice