web-dev-qa-db-fra.com

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

Quelle est la différence (en langage un Noyth python/Django peut comprendre) dans une vue entre render(), render_to_response() et direct_to_template()?

par exemple. à partir de 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, que faut-il utiliser dans une situation particulière?

pythondjango
230
Ryan

https://docs.djangoproject.com/fr/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_response in 1.3 qui utilisera automatiquement RequestContext que je vais très certainement utiliser à partir de maintenant.

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

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

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

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

direct_to_template est une vue générique que j'utilise dans mes vues (contrairement à mes URL) car, comme la nouvelle fonction render(), elle utilise automatiquement RequestContext et tous ses context_processors. .

Mais direct_to_template doit être évité car les vues génériques basées sur des fonctions sont déconseillées. Utilisez render ou une classe réelle, voir https://docs.djangoproject.com/fr/1.3/topics/generic-views-migration/

Je suis heureux de ne pas avoir tapé RequestContext depuis très longtemps.

182
Yuji 'Tomita' Tomita

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

  • render_to_response() est "l'original", mais vous devez mettre context_instance=RequestContext(request) dans 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 pour render_to_response() qui fournit automatiquement context_instance=Request.... Il est disponible dans la version de développement Django (1.2.1) mais beaucoup ont créé leur propre des raccourcis tels que celui-ci , celui-ci ou celui qui m'a jeté initialement, Nathans basic.tools.shortcuts.py

39
Ryan

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)

Donc, il n'y a vraiment pas de différence entre render_to_response sauf que cela enveloppe votre contexte pour que les pré-processeurs de modèles fonctionnent.

L'affectation directe au modèle est un vue générique .

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

23
Frost.baka

De Django docs :

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

direct_to_template est quelque chose de différent. Il s’agit d’une vue générique qui utilise un dictionnaire de données pour restituer le code HTML sans avoir besoin du fichier views.py. Vous l’utilisez dans urls.py. Docs ici

12
Fábio Diniz

Juste une note que 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)

Que fait réellement le troisième paramètre context_instance? Étant RequestContext , il établit un contexte de base qui est ensuite ajouté à user_context. Donc, le modèle obtient ce contexte étendu. Les variables ajoutées sont données par TEMPLATE_CONTEXT_PROCESSORS dans settings.py. Par exemple, Django.contrib.auth.context_processors.auth ajoute les variables user et perm, qui sont ensuite accessibles dans le modèle.

6
clime