Django - quelle est la différence entre render (), render_to_response () et direct_to_template ()?

Quelle est la différence (dans un langage qu'un noob python / django peut comprendre) dans une vue entre render(), render_to_response()et direct_to_template()?

par exemple à partir des exemples d'applications de base de Nathan Borror

def comment_edit(request, object_id, template_name='comments/edit.html'):
    comment = get_object_or_404(Comment, pk=object_id, user=request.user)
    # ...
    return render(request, template_name, {
        'form': form,
        'comment': comment,
    })

Mais j'ai aussi vu

    return render_to_response(template_name, my_data_dictionary,
              context_instance=RequestContext(request))

Et

    return direct_to_template(request, template_name, my_data_dictionary)

Quelle est la différence, quoi utiliser dans une situation particulière?

https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render

render(request, template[, dictionary][, context_instance][, content_type][, status][, current_app])

render()est un nouveau raccourci flambant neuf pour render_to_response1.3 qui utilisera automatiquement ce RequestContextque j'utiliserai très certainement à partir de maintenant.

EDIT 2020: Il convient de noter qu'il a render_to_response()été supprimé dans Django 3.0

https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render-to-response

render_to_response(template[, dictionary][, context_instance][, mimetype])¶

render_to_responseest votre fonction de rendu standard utilisée dans les tutoriels et autres. Pour l'utiliser, RequestContextvous devez spécifiercontext_instance=RequestContext(request)

https://docs.djangoproject.com/en/1.8/ref/generic-views/#django-views-generic-simple-direct-to-template

direct_to_templateest une vue générique que j'utilise dans mes vues (par opposition à dans mes URL) car comme la nouvelle render()fonction, elle utilise automatiquement RequestContextet tous ses context_processors.

Mais direct_to_template doit être évité car les vues génériques basées sur les fonctions sont obsolètes. Soit utiliser rendersoit une classe réelle, voir https://docs.djangoproject.com/en/1.3/topics/generic-views-migration/

Je suis content de ne pas avoir tapé RequestContextdepuis très longtemps.

Reformuler les réponses de Yuri, Fábio et Frosts pour le Django noob (c'est-à-dire moi) - presque certainement une simplification, mais un bon point de départ?

• render_to_response()est "l'original", mais vous oblige à mettre context_instance=RequestContext(request)presque tout le temps, un PITA.

• direct_to_template()est conçu pour être utilisé uniquement dans urls.py sans une vue définie dans views.py mais il peut être utilisé dans views.py pour éviter d'avoir à taper RequestContext

• render()est un raccourci render_to_response()qui fournit automatiquement context_instance=Request.... Il est disponible dans la version de développement de django (1.2.1) mais beaucoup ont créé leurs propres raccourcis comme celui-ci , celui-ci ou celui qui m'a lancé initialement, Nathans basic.tools. shortcuts.py

Le rendu est

def render(request, *args, **kwargs):
    """ Simple wrapper for render_to_response. """
    kwargs['context_instance'] = RequestContext(request)
    return render_to_response(*args, **kwargs)

Il n'y a donc vraiment aucune différence, render_to_responsesauf qu'il enveloppe votre contexte pour faire fonctionner les pré-processeurs de modèle.

Direct to template est une vue générique .

Il n'y a vraiment aucun sens à l'utiliser ici car il y a des frais généraux render_to_responsesous la forme d'une fonction d'affichage.

Depuis les documents de Django :

render () est identique à un appel à render_to_response () avec un argument context_instance qui force l'utilisation d'un RequestContext.

direct_to_templateest quelque chose de différent. C'est une vue générique qui utilise un dictionnaire de données pour rendre le html sans avoir besoin de views.py, vous l'utilisez dans urls.py. Documents ici

Juste une note que je n'ai pas pu trouver dans les réponses ci-dessus. Dans ce code:

context_instance = RequestContext(request)
return render_to_response(template_name, user_context, context_instance)

Que context_instancefait réellement le troisième paramètre ? Étant RequestContext, il définit un contexte de base qui est ensuite ajouté à user_context. Le modèle obtient donc ce contexte étendu. Les variables ajoutées sont données par TEMPLATE_CONTEXT_PROCESSORSdans settings.py. Par exemple, django.contrib.auth.context_processors.auth ajoute une variable useret une variable permqui sont ensuite accessibles dans le modèle.