Just something else I had in mind when it comes to this, more of a builder pattern:

<?php

interface ResponseBuilderInterface
{
    public function build(EngineInterface $engine);
}

class TemplatedResponseBuilder implements ResponseBuilderInterface
{
    private $template;
    private $parameters;
    private $statusCode;
    private $headers;

    public function __construct($template, array $parameters = array(), $statusCode = Response::HTTP_OK, array $headers = array())
    {
        $this->template = $template;
        $this->parameters = $parameters;
        $this->statusCode = $statusCode;
        $this->headers = $headers;
    }

    public function build(EngineInterface $engine)
    {
        // or use PSR if you like
        return new Response($engine->render($this->template), ...);
    }
}

Advantage with this setup is that you have 100% control over the view and you can create nice response builders:

class InvoiceResponseBuilder implements ResponseBuilderInterface
{
    private $invoices;

    public function __construct(array $invoices)
    {
        $this->invoices= $invoices;
    }

    public function build(EngineInterface $engine)
    {
        $total = count($this->invoices);

        if (0 === $total) {
            return new Response($engine->render('/invoice_404.html.twig'));
        }

        if (5 > $total) {
            return new Response($engine->render('/invoice_few.html.twig'));
        }

        return new Response($engine->render('/invoice_many.html.twig'));
    }
}

names to be discussed

I think it should be a TemplateResponse class, so that it is a bit more consistent with the JsonResponse and StreamedResponse classes.

It can follow the same concept as you mentioned, but instead of a builder, just apublic function getResponse(EngineInterface $engine) method that can return a response object

I like this idea. However, I think this might be two steps to far for the moment. The @Template annotation is part of the SensioFrameworkExtraBundle and the twig glue that is part of it. What I rather see is a pull request for that bundle that does:

• Remove the @Template annotation
• Adds the TemplateResponse which extends the regular Response
• Make the TemplateListener use the TemplateResponse instead of the array that we have now

The advantage of this is that we can now define the return value of each action to always be Response, which is great for PHP strict types. The other upshot is that you are not mixing concepts which are (for now) spread across different bundles. While I do not mind adding the twig response support to the core, I think it would conflict with the SensioFrameworkExtraBundle as is. They provide the same result in different ways, which I find confusing.

Don't get me wrong though, I like the idea of your PR. This opens the door for other things like PDF responses which set the correct headers or switching templates based on the view data. I just think there needs to be done some prep-work before introducing this to the core.

Remove the @template annotation

I don't think this needs to be removed. The annotation is still a useful feature for anyone that prefers it, but not everyone likes using annotations.

Adds the TemplateResponse which extends the regular Response

That did cross my mind as well, but I wasn't sure how the implementation would look like for it to make sense as a Response class, as I don't think the templating should be tied to the http-kernel or http-foundation components, hence I added it in the framework bundle which ties those components together.

For me the SensioFrameworkExtraBundle adds some nice features to use annotations, but it can be disabled which then means you will lose this feature. Having the ability to create a template response just seems more natural in core

@pierredup I've considered if extending the Response would be a good idea, but this would prevent the view event from being fired:

// call controller
$response = call_user_func_array($controller, $arguments);

// view
if (!$response instanceof Response) {
    $event = new GetResponseForControllerResultEvent($this, $request, $type, $response);
    $this->dispatcher->dispatch(KernelEvents::VIEW, $event);
    // ...
}

If extending the Response, the event can then be tied into to kernel.response instead (which probably also isn't ideal, because that means the event listener will be triggered on every response instead of only when necessary, adding a bit of unnecessary overhead)

Suggested changes made, ready for review

I'm not sure about using Response in the name since the class doesn't extends the Response object. Maybe TemplateView would be a more fitting name.

I'm not sure this should be in the core itself, especially given that it is strongly tied to the Templating component, that we are slowly deprecating.

@stof perhaps this is something useful for the twig bundle instead?

We are indeed moving away from the Templating component, so adding a feature requiring is a no-go. FrameworkExtraBundle will require Twig in its next major version, and @Template will only work with Twig.

I have one more edge case that I possibly would like to see supported; Redirects.

class InvoiceResponse implements TemplateResponseInterface
{
    // ..

    public function build(EngineInterface $engine)
    {
        $total = count($this->invoices);

        if (0 === $total) {
            // ..
        }

        if (1 === $total) {
            // how do I get my route here?
            return ... new RedirectResponse?('app.invoice.one', [$this->invoices[0]]);
        }

        if (5 > $total) {
            // ..
        }

        // ..
    }
}

My personal goal is to have no dependency on the Router, UrlGenerator or Templating/Twig in my controller.

I'm not sure if the route and redirect should be solved in this PR, since the goal here is only to create an easy way to render templates without injecting twig into the controller. But for that issue, what about something like a custom RouteRedirectResponse that takes a route name and parameters instead of a URL?

@pierredup a lazy redirect, where you can just fill in the route + parameters is something I've wanted for quite some time, but was rejected in the past. Could be something explicit for this responder though

What about trying to implement a broader feature that makes views a first-class citizen? We've had the view event since the beginning, but we never really provided anything to make it useful out of the box. ResponsedTemplate is just one implementation of a larger scope.

What about the responder pattern? I'm not too familiar/experienced with it myself but it seems to solve certain challenges between the controller and the view.

@fabpot, do you have something in mind or any ideas about the larger scope?

What about trying to implement a broader feature that makes views a first-class citizen?

@fabpot I'd like to finish this PR, do you perhaps have any ideas about what a view as a first-class citizen would look like?

Let's kick this to 4.1 and see if we can get something really nice and thoughtful done (since we're so close to feature freeze now, I think it would be rushed).

Actually, I'm going to close this one. The proposed feature is not generic enough and should probably be experimented in a bundle first, before being integrated in code.

@iltar ViewBundle. No tests for now.