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

Question

Quelle est la différence (en langue que comprenne un noob python/django) dans une vue entre , et `` ?

par exemple, des exemples d’applications de base de Nathan Borror

Mais j’ai aussi vu

Et

Quelle est la différence, ce qu’il faut utiliser dans n’importe quelle situation particulière ?

Answer 1

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

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

render() est une marque fessée nouveau raccourci pour render_to_response 1.3 qui utilisera automatiquement RequestContext que je vais certainement utiliser à partir de maintenant.

---

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

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

render_to_response de votre fonction rendu utilisé dans les tutoriels et autres. Pour utiliser RequestContext vous devez spécifier context_instance=RequestContext(request)

---

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

direct_to_template est une vue générique que j'utilise dans mon point de vue (par opposition à dans mon url) parce que, comme le nouveau render() de la fonction, il utilise automatiquement RequestContext et tous ses context_processors.

Mais direct_to_template doit être évitée en fonction en fonction générique vues sont obsolètes. Utiliser render ou une classe réelle, voir https://docs.djangoproject.com/en/1.3/topics/generic-views-migration/

Je suis heureux que je n'ai pas tapé RequestContext dans un long, long temps.

Answer 2

Reformuler Yuri, Fábio, et les Gelées réponses 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 exige de vous mettre context_instance=RequestContext(request) dans presque tous les temps, un pain PITA.

• direct_to_template() est conçu pour être utilisé seulement 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 pour render_to_response() qui fournit automatiquement context_instance=Request.... Son disponible dans la version de développement de django (1.2.1), mais beaucoup ont créé leurs propres raccourcis tels que cette de un, ce un ou de celui qui m'a jeté d'abord, Nathans basic.tools.shortcuts.py

Answer 3

Render est

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

Donc, il n'y a vraiment aucune différence entre render_to_response sauf qu'il enveloppe votre contexte en faisant fonctionner les pré-processeurs du modèle.

Direct au modèle est une vue générique .

Il n'y a aucun sens à l'utiliser ici car il y a un overhead sur render_to_response sous la forme de fonction de vue.

Answer 4

De django docs:

render() est la même qu'un appel à l' render_to_response() avec un context_instance argument que les forces de l'utilisation d'un RequestContext.

direct_to_template est quelque chose de différent. C'est une vue générique qui utilise un dictionnaire de données pour afficher le code html sans avoir besoin de la views.py vous pouvez utiliser dans urls.py. Docs ici

Answer 5

Juste une remarque, je ne pouvais pas trouver dans les réponses ci-dessus. Dans ce code:

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

Le troisième paramètre context_instance fait réellement? Étant RequestContext il met en place certaines contexte de base qui est ensuite ajouté à l' user_context. Donc, le modèle est de cette extension du contexte. Quelles sont les variables ajoutée est donnée par TEMPLATE_CONTEXT_PROCESSORS dans settings.py. Par exemple django.contrib.auth.context_processors.auth ajoute la variable user et variable perm qui sont alors accessibles dans le modèle.