Django - qual è la differenza tra render (), render_to_response () e direct_to_template ()?

Qual è la differenza (nel linguaggio che un python / django noob può capire) in una vista tra render(), render_to_response()e direct_to_template()?

ad es. dagli esempi di app di base di 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,
    })

Ma ho anche visto

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

E

    return direct_to_template(request, template_name, my_data_dictionary)

Qual è la differenza, cosa usare in una situazione particolare?

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

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

render()è un marchio che sculaccia la nuova scorciatoia per la render_to_response1.3 che utilizzerà automaticamente RequestContextquello che sicuramente userò d' ora in poi.

2020 EDIT: Va notato che è render_to_response()stato rimosso in 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_responseè la tua funzione di rendering standard utilizzata nei tutorial e simili. Per usare RequestContextdovresti specificarecontext_instance=RequestContext(request)

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

direct_to_templateè una vista generica che utilizzo nei miei punti di vista (al contrario dei miei URL) perché, come la nuova render()funzione, utilizza automaticamente RequestContexte tutti i suoi messaggi context_processor.

Ma direct_to_template dovrebbe essere evitato poiché le viste generiche basate sulla funzione sono deprecate. Utilizzare rendero una classe effettiva, consultare https://docs.djangoproject.com/en/1.3/topics/generic-views-migration/

Sono felice di non aver digitato RequestContextper molto, molto tempo.

Ridefinendo le risposte di Yuri, Fábio e Frosts per il noob di Django (cioè io) - quasi certamente una semplificazione, ma un buon punto di partenza?

• render_to_response()è "originale", ma richiede di inserire context_instance=RequestContext(request)quasi sempre un PITA.

• direct_to_template()è progettato per essere utilizzato solo in urls.py senza una vista definita in views.py ma può essere utilizzato in views.py per evitare di digitare RequestContext

• render()è una scorciatoia render_to_response()che fornisce automaticamente context_instance=Request.... È disponibile nella versione di sviluppo di django (1.2.1) ma molti hanno creato le proprie scorciatoie come questa , questa o quella che mi ha lanciato inizialmente, Nathans basic.tools. shortcuts.py

Il rendering è

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

Quindi non c'è davvero alcuna differenza tra render_to_responsetranne se avvolge il tuo contesto facendo funzionare i pre-processori di template.

Diretto al modello è una vista generica .

Non ha davvero senso usarlo qui perché c'è un sovraccarico render_to_responsesotto forma di funzione di visualizzazione.

Dai documenti di django :

render () è lo stesso di una chiamata a render_to_response () con un argomento context_instance che forza l'uso di un RequestContext.

direct_to_templateè qualcosa di diverso. È una vista generica che utilizza un dizionario di dati per rendere l'html senza la necessità di views.py, lo usi in urls.py. Documenti qui

Solo una nota che non ho trovato nelle risposte sopra. In questo codice:

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

Cosa context_instancefa effettivamente il terzo parametro ? Essendo RequestContext , imposta un contesto di base a cui viene aggiunto user_context. Quindi il modello ottiene questo contesto esteso. Quali variabili vengono aggiunte sono indicate TEMPLATE_CONTEXT_PROCESSORSin settings.py. Ad esempio django.contrib.auth.context_processors.auth aggiunge variabili usere variabili permche sono quindi accessibili nel modello.