Listing and Using Services

Rendering a template is pretty common, so there's a shortcut when you're in a controller. Replace all of this code with a simple return $this->render:

21 lines src/AppBundle/Controller/GenusController.php
... lines 1 - 8
class GenusController extends Controller
... lines 11 - 13
public function showAction($genusName)
return $this->render('genus/show.html.twig', array(
'name' => $genusName

That's it. Make sure this works by refreshing.

So what does this magic-looking render() function actually do? Let's find out! Hold command or control (depending on your OS) and click render() to be taken straight into the base Controller class where this function lives: deep in the heart of Symfony:

398 lines vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Controller/Controller.php
... lines 1 - 38
abstract class Controller implements ContainerAwareInterface
... lines 41 - 185
protected function render($view, array $parameters = array(), Response $response = null)
if ($this->container->has('templating')) {
return $this->container->get('templating')->renderResponse($view, $parameters, $response);
... lines 191 - 202
... lines 204 - 396

Ah, hah! In reality, this function simply goes out to the templating service - just like we did - and calls a method named renderResponse(). This method is like the render() function we called, except that it wraps the HTML in a Response object for convenience.

Here's the point: the base Controller class has a lot of shortcut methods that you'll use. But behind the scenes, these don't activate some weird, core functionality in Symfony. Instead, everything is done by one of the services in the container. Symfony doesn't really do anything: all the work is done by different services. That's awesome.

What Services are there?

Oh, you want to know what other services are hiding in the container? Me too! To find that out, head back to the terminal and use the handy console:

php bin/console

Check out that debug:container command - run that!

php bin/console debug:container

You should see a short list of service. Ah, I mean, you should see over 200 useful objects in Symfony that you get access to out of the box. But don't worry about memorizing these: as you use Symfony, you'll find out which ones are important to you and your project by reading the docs on how to accomplish different things.

But sometimes, you can just guess! For example, does Symfony have a service for logging? Um, maybe?! We could Google that, or we could pass an argument to this command to search for services matching "log":

php bin/console debug:container log

Wow, there are 18! Here's a secret: the service you usually want is the one with the shortest name. In this case: logger. So if you wanted to log something, just grab this out of the container and use it. This command also shows you what class you'll get back, which you can use to find the methods on it.

We just figured this out without any documentation.

There's a lot more to say later about services and the container. In fact, it's one of the most fundamentally important things that makes Symfony so special... and so fast.

Leave a comment!

  • 2016-09-06 Victor Bocharsky

    Hey Nassim,

    What environment do you use? Probably you try to dump() something in prod environment, where debugging is disabled. It is enabled by default only in the dev and test environment of the Symfony Standard Edition. So try to switch to the dev environment to see your dump. Let me know if it helps.

    P.S. You could also check Symfony logs in /var/logs directory.


  • 2016-09-05 Nassim Bennouna


    Just in case you could give me a hint, when i try

    {{ dump() }}
    I got a "500 Internal Server Error"
    If i remove th dump expression, the template displays correctly
    Nothing in the apache error log

    Any idea ?