Nearly completed - just need to finish Twig extension to render ESI - Symfony2 - symfony

Question

I want to create a Twig extension and use this:
{{ new_func(route-name) }}
To do the same thing as:
{{ render_esi(url(route-name)) }}
...but with some adjustments
It's nearly done but it's this line that needs to be changed, but I can't see how I can call an ESI from this code (outside of Twig):
return $environment->render($route); /// needs to receive route and render an ESI
-
namespace Acme\Bundle\MyBundle\Twig;
class NewTwigFunction extends \Twig_Extension
{
private $request;
public function __construct($container)
{
$this->request = $container->get('request');
}
public function getFunctions() {
return array(
'new_func' => new \Twig_Function_Method($this, 'newFunction', array('needs_environment' => true) )
);
}
public function newFunction(\Twig_Environment $environment, $route) {
$r = $this->request;
return $environment->render($route);
}
public function getName() {
return "new_func";
}
}

Answer 1

I'm not sure I follow why would you need this, but I think it's great as an example of an abstract question:
How do I track down & extend core functionality of Symfony2?
Finding the functionality
Seems that you're having trouble finding where is this render_esi executed, so let's tackle that!
This doesn't seem like a standard Twig feature, so it must be an extension, just like the one you're creating.
It should be located somewhere in Symfony2 core files, so we start looking into vendor/symfony/src folder. Since we already know that we're dealing with an extension of Twig, Component folder is out of the question (because Twig is a separate library from Symfony2 core components).
So we've narrowed it down to Bridge and Bundle. If we look inside them then we see Bundle/TwigBundle or Bridge/Twig. We also know that Symfony2 developers follow a strict code/architecture style, so we know exactly which folder to look for - Extension. Now it's just a matter of checking them both.
Long story short we find what we're looking for in vendor/symfony/src/Symfony/Bridge/Twig/Extension/HttpKernelExtension, where we see a render_* function. Jackpot!
Extending the functionality
Before changing anything, we need to first emulate what's already there, so we create something like this:
use Symfony\Component\HttpKernel\Fragment\FragmentHandler;
class NewTwigFunction extends \Twig_Extension
{
private $handler;
public function __construct(FragmentHandler $handler)
{
$this->handler = $handler;
}
public function getFunctions()
{
return array(
'new_func' => new \Twig_Function_Method($this, 'newFunction', array('is_safe' => array('html')) )
);
}
public function newFunction($uri, $options = array())
{
return $this->handler->render($uri, 'esi', $options);
}
public function getName()
{
return "new_func";
}
}
Now when you call
{{ new_func(url(route-name)) }}
you should see same results as
{{ render_esi(url(route-name)) }}
But we still need to get rid of the url part.
Easy as pie, we just add the router service to our extension! Now our extension could look like this:
use Symfony\Component\Routing\Router;
use Symfony\Component\HttpKernel\Fragment\FragmentHandler;
class NewTwigFunction extends \Twig_Extension
{
private $handler;
private $router;
public function __construct(FragmentHandler $handler, Router $router)
{
$this->handler = $handler;
$this->router = $router;
}
public function getFunctions()
{
return array(
'new_func' => new \Twig_Function_Method($this, 'newFunction', array('is_safe' => array('html')) )
);
}
public function newFunction($routeName, $options = array())
{
$uri = $this->router->generate($routeName);
return $this->handler->render($uri, 'esi', $options);
}
public function getName()
{
return "new_func";
}
}
and {{ new_func(route-name) }} should work as expected.
Hooking in-between
The way I understood it, you want almost the same functionality as render_esi, but with slight changes to output.
So that means that we need to hook somewhere in-between return and $this->handler->render($uri, $strategy, $options);.
How deep down the rabbit hole we need to go depends on the change.
For example, if you want to alter Response object before it's turned into actual html string, you need to find the spot where it's turned in the first place. A good bet would be to look into FragmentHandler:
protected function deliver(Response $response)
{
if (!$response->isSuccessful()) {
throw new \RuntimeException(sprintf('Error when rendering "%s" (Status code is %s).', $this->request->getUri(), $response->getStatusCode()));
}
if (!$response instanceof StreamedResponse) {
return $response->getContent();
}
$response->sendContent();
}
Got it! Now you just need to extend FragmentHandler::deliver() and pass your implementation of it into your twig extenion.
Tracking down configuration
You have to understand that Symfony2 core code is not that different from what you write in your everyday life, it still abides by its own rules.
For example, when normally creating a Twig extension in Symfony2 you need to configure it as a service, right? Well, Symfony2 core extensions are configured in the same way. You just need to find where the configuration files are located.
Following the logic from Extending the functionality we know for sure that they're not located in Component. Bridge is actually a name for a design pattern - not a place where you'd place your service configuration :)
So we're left with Bundle - and obviously that's where we find all the information we need: vendor/symfony/src/Bundle/TwigBundle/Resources/config/twig.xml
Now we simply look up how original HttpKernelExtension is configured and follow its lead:
<service id="twig.extension.httpkernel" class="%twig.extension.httpkernel.class%" public="false">
<argument type="service" id="fragment.handler" />
</service>
Transforming it into a more commonly used .yml format, our extension config could look like this:
new_func:
class: Acme\Bundle\MyBundle\Twig\NewTwigFunction
arguments:
- "#fragment.handler"
# Uncomment when implementing code from 2nd example
# - "#router"
tags:
- { name: twig.extension }
public: false