# Django 1.8.18.dev20170123152445 documentation

# Simple mixins

## ContextMixin

class `django.views.generic.base.``ContextMixin`

  Methods

  `get_context_data`(**kwargs)

    Returns a dictionary representing the template context. The keyword arguments provided will make up the returned context. Example usage:

        def get_context_data(self, **kwargs):
            context = super(RandomNumberView, self).get_context_data(**kwargs)
            context['number'] = random.randrange(1, 100)
            return context

    The template context of all class-based generic views include a `view` variable that points to the `View` instance.

    Use `alters_data` where appropriate

    Note that having the view instance in the template context may expose potentially hazardous methods to template authors. To prevent methods like this from being called in the template, set `alters_data=True` on those methods. For more information, read the documentation on rendering a template context.

## TemplateResponseMixin

class `django.views.generic.base.``TemplateResponseMixin`

  Provides a mechanism to construct a `TemplateResponse`, given suitable context. The template to use is configurable and can be further customized by subclasses.

  Attributes

  `template_name`

    The full name of a template to use as defined by a string. Not defining a `template_name` will raise a `django.core.exceptions.ImproperlyConfigured` exception.

  `template_engine`

    The `NAME` of a template engine to use for loading the template. `template_engine` is passed as the `using` keyword argument to `response_class`. Default is `None`, which tells Django to search for the template in all configured engines.

  `response_class`

    The response class to be returned by `render_to_response` method. Default is `TemplateResponse`. The template and context of `TemplateResponse` instances can be altered later (e.g. in template response middleware).

    In older versions of Django, `TemplateResponse` used `RequestContext` in such a way that values from template context processors would override template variables defined in your views. For example, if you subclassed `DetailView` and set `context_object_name` to `user`, the `django.contrib.auth.context_processors.auth` context processor would overwrite your variable with the current user. Now, for consistency with the `render()` shortcut, values in the context provided by the class override values from context processors.

    If you need custom template loading or custom context object instantiation, create a `TemplateResponse` subclass and assign it to `response_class`.

  `content_type`

    The content type to use for the response. `content_type` is passed as a keyword argument to `response_class`. Default is `None` – meaning that Django uses `DEFAULT_CONTENT_TYPE`.

  Methods

  `render_to_response`(context, **response_kwargs)

    Returns a `self.response_class` instance.

    If any keyword arguments are provided, they will be passed to the constructor of the response class.

    Calls `get_template_names()` to obtain the list of template names that will be searched looking for an existent template.

  `get_template_names`()

    Returns a list of template names to search for when rendering the template.

    If `template_name` is specified, the default implementation will return a list containing `template_name` (if it is specified).