Standard HttpResponse objects are static structures.
They are provided with a block of pre-rendered content at time of
construction, and while that content can be modified, it isn’t in a form that
makes it easy to perform modifications.

However, it can sometimes be beneficial to allow decorators or
middleware to modify a response after it has been constructed by the
view. For example, you may want to change the template that is used,
or put additional data into the context.

TemplateResponse provides a way to do just that. Unlike basic
HttpResponse objects, TemplateResponse objects retain
the details of the template and context that was provided by the view to
compute the response. The final output of the response is not computed until
it is needed, later in the response process.

The full name of a template, or a sequence of template names.
Template instances can also be used.

context

A dictionary of values to add to the template context. By default,
this is an empty dictionary. Context objects
are also accepted as context values.

status

The HTTP Status code for the response.

content_type

Changed in Django 1.5.

Historically, this parameter was only called mimetype (now
deprecated), but since this is actually the value included in the HTTP
Content-Type header, it can also include the character set
encoding, which makes it more than just a MIME type specification. If
mimetype is specified (not None), that value is used.
Otherwise, content_type is used. If neither is given,
DEFAULT_CONTENT_TYPE is used.

Converts context data into a context instance that can be used for
rendering a template. Accepts a dictionary of context data or a
context object. Returns a Context
instance containing the provided data.

Resolves the template instance to use for rendering. Accepts a
path of a template to use, or a sequence of template paths.
Template instances may also be provided.
Returns the Template instance to be
rendered.

The full name of a template, or a sequence of template names.
Template instances can also be used.

context

A dictionary of values to add to the template context. By default,
this is an empty dictionary. Context objects
are also accepted as context values. If you pass a
Context instance or subclass, it will be used
instead of creating a new RequestContext.

status

The HTTP Status code for the response.

content_type

Changed in Django 1.5.

Historically, this parameter was only called mimetype (now
deprecated), but since this is actually the value included in the HTTP
Content-Type header, it can also include the character set
encoding, which makes it more than just a MIME type specification. If
mimetype is specified (not None), that value is used.
Otherwise, content_type is used. If neither is given,
DEFAULT_CONTENT_TYPE is used.

Before a TemplateResponse instance can be
returned to the client, it must be rendered. The rendering process takes the
intermediate representation of template and context, and turns it into the
final byte stream that can be served to the client.

There are three circumstances under which a TemplateResponse will be
rendered:

When the content of the response is explicitly set by assigning
response.content.

After passing through template response middleware, but before
passing through response middleware.

A TemplateResponse can only be rendered once. The first call to
SimpleTemplateResponse.render() sets the content of the response;
subsequent rendering calls do not change the response content.

However, when response.content is explicitly assigned, the
change is always applied. If you want to force the content to be
re-rendered, you can re-evaluate the rendered content, and assign
the content of the response manually:

Some operations – such as caching – cannot be performed on an
unrendered template. They must be performed on a fully complete and
rendered response.

If you’re using middleware, the solution is easy. Middleware provides
multiple opportunities to process a response on exit from a view. If
you put behavior in the Response middleware is guaranteed to execute
after template rendering has taken place.

However, if you’re using a decorator, the same opportunities do not
exist. Any behavior defined in a decorator is handled immediately.

To compensate for this (and any other analogous use cases),
TemplateResponse allows you to register callbacks that will
be invoked when rendering has completed. Using this callback, you can
defer critical processing until a point where you can guarantee that
rendered content will be available.

To define a post-render callback, just define a function that takes
a single argument – response – and register that function with
the template response:

defmy_render_callback(response):# Do content-sensitive processingdo_post_processing()defmy_view(request):# Create a responseresponse=TemplateResponse(request,'mytemplate.html',{})# Register the callbackresponse.add_post_render_callback(my_render_callback)# Return the responsereturnresponse

my_render_callback() will be invoked after the mytemplate.html
has been rendered, and will be provided the fully rendered
TemplateResponse instance as an argument.

If the template has already been rendered, the callback will be
invoked immediately.