En fait en Symfony 4 (comme dans beaucoup d'autres framework), on va avoir des middleware (psr7/psr15). Un middleware c'est une classe standard (Plain Old PHP Object ou POPO), callable. Par exemple :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
|
<?php
declare(strict_types=1);
namespace MyBundle\Action;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Symfony\Component\Templating\EngineInterface;
use Zend\Diactoros\Response\HtmlResponse;
final class MyMiddleware
{
private $dependency;
private $renderer;
public function __construct(Dependency $dependency, EngineInterface $renderer)
{
$this->dependency = $dependency;
$this->renderer = $renderer;
}
public function __invoke(ServerRequestInterface $request) : ResponseInterface
{
// do something with $this->dependency
return new HtmlResponse($this->renderer->render('MyModuleBundle:Homepage:index.html.twig', [
]));
}
} |
A partir de cette classe, ce qu'il se passait en Symfony 2 surtout, c'est qu'on dispatchait sur un base controller :
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
Comme tu peux le constater là (http://api.symfony.com/3.3/Symfony/B...ontroller.html), le base controller est ContainerAwareInterface et utilise le ContainerAwareTrait. L'injection du container est donc une setter injection, ce qui t'ouvre au temporal coupling (devoir appeler une methode avant une autre pour que la seconde marche correctement).
Tu pourrais imaginer la même chose pour tes middlewares, avoir un BaseMiddleware (abstract), qui serait ContainerAware, mais je le déconseille fortement, il y a une raison pour que Symfony et ZF ne le proposent plus...
Partager