If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeEn tu terminal, ejecuta:
bin/console debug:container --parameters
Uno de los parámetros de kernel
se llama kernel.debug
. Además de los entornos, Symfony tiene este concepto de "modo de depuración". Es verdadero para el entorno dev
y falso para prod
. Y, de vez en cuando, ¡es muy útil!
He aquí nuestro nuevo reto (sobre todo para ver si podemos hacerlo). Dentro deMixRepository
, quiero averiguar si estamos en modo de depuración. Si el modo de depuración es verdadero, guardaremos el caché durante 5 segundos. Si es falso, quiero almacenar en caché durante 60 segundos
Retrocedamos un momento. Supón que estás trabajando dentro de un servicio comoMixRepository
. De repente te das cuenta de que necesitas algún otro servicio como el logger. ¿Qué haces para conseguir el registrador? La respuesta: haces el baile de la inyección de dependencia. Añades un argumento y una propiedad de private LoggerInterface $logger
... y luego lo utilizas en tu código. Harás esto muchas veces en Symfony.
Permíteme deshacer eso... porque en realidad no necesitamos el registrador ahora mismo. Pero lo que sí necesitamos es algo parecido. Ahora mismo estamos dentro de un servicio y de repente nos hemos dado cuenta de que necesitamos alguna configuración (la bandera kernel.debug
) para hacer nuestro trabajo. ¿Qué hacemos para conseguir esa configuración? Lo mismo Añadirla como argumento a nuestro constructor. Digamos private bool $isDebug
, y aquí abajo, úsalo: si $this->isDebug
, caché durante 5 segundos, si no, caché durante 60 segundos.
Pero... hay una pequeña complicación... y seguro que ya sabes cuál es. Cuando refrescamos la página... ¡vaya! Nos sale un error en Cannot resolve argument
. Si saltas un poco, dice
No se puede autoconectar el servicio
App\Service\MixRepository
: el argumento$isDebug
del método__construct()
es de tipobool
, debes configurar su valor explícitamente.
Eso tiene sentido. El autocableado sólo funciona para los servicios. No puedes tener un argumento bool$isDebug
y esperar que Symfony se dé cuenta de alguna manera de que queremos el parámetrokernel.debug
. Puede que sea un mago, pero no tengo un hechizo para eso. Sin embargo, puedo hacer desaparecer un trozo de pastel entero. Con magia. Sin duda.
¿Cómo solucionamos esto? Abre un archivo que aún no hayamos mirado:config/services.yaml
. Hasta ahora, no hemos necesitado añadir ninguna configuración para nuestro servicioMixRepository
. El contenedor vio la clase MixRepository
en cuanto la creamos... y el autocableado ayudó al contenedor a saber qué argumentos pasar al constructor. Pero ahora que tenemos un argumento no autocable, tenemos que dar una pista al contenedor. Y eso lo hacemos en este archivo.
Dirígete a la parte inferior y añade el espacio de nombres completo de esta clase:App\Service\MixRepository
. Debajo de eso, utiliza la palabra bind
. Y debajo de eso, dale al contenedor una pista para indicarle qué debe pasar al argumento diciendo$isDebug
set to %kernel.debug%
Estoy utilizando $isDebug
a propósito. Eso tiene que coincidir exactamente con el nombre del argumento en la clase. Gracias a esto, el contenedor pasará el valor del parámetrokernel.debug
.
Y cuando lo probamos... ¡funciona! Los dos argumentos del servicio siguen estando autocableados, pero hemos rellenado el único argumento que faltaba para que el contenedor pueda instanciar nuestro servicio. ¡Muy bien!
Quiero hablar más del propósito de este archivo y de toda la configuración aquí arriba. Resulta que mucha de la magia que hemos estado viendo relacionada con los servicios y el autocableado se puede explicar con este código. Eso a continuación.
hey @blanx
let's think different, you need 1 little variable (string, bool or any type) so you are injecting the whole big Container to use just this 1 value? Won't it be easier to inject only var you need with services.yaml
?
As for me it will be much cleaner way and also it will be more performant way
Cheers!
Hey @sadikoff, thx for your reply!
You have a good point :) The trade off, that it is more complicated. I thought it was no big deal, since the Kernel is loaded anyway and Symfony is so smart it only uses a reference...but maybe this was wishful thinking.
IIRC it has nothing with Symfony, but PHP and of course it will be a reference to class, but what will be better to have value immediately or get some class from reference and then call some method to get same raw value?
Cheers!
// 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
}
}
If I need the a Kernel Variable I simply inject the KernelInterface
public function __construct( private KernelInterface $kernel)
{
}
This way I don't need a binding in services.yaml
Is this an other way or bad practice?