Django - jaka jest różnica między render (), render_to_response () a direct_to_template ()?

Jaka jest różnica (w języku, w którym python / django noob może zrozumieć) w widoku pomiędzy render(), render_to_response()a direct_to_template()?

np. z podstawowych przykładów aplikacji Nathana Borrora

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,
    })

Ale też widziałem

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

I

    return direct_to_template(request, template_name, my_data_dictionary)

Jaka jest różnica, czego użyć w konkretnej sytuacji?

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

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

render()to nowy skrót od marki render_to_response1.3, który automatycznie użyje RequestContexttego, z którego będę zdecydowanie korzystać od teraz.

EDYCJA 2020: Należy zauważyć, że render_to_response()został usunięty w 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_responseto standardowa funkcja renderowania używana w samouczkach i tym podobne. Aby użyć RequestContext, musisz określićcontext_instance=RequestContext(request)

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

direct_to_templateto ogólny widok, którego używam w moich widokach (w przeciwieństwie do moich adresów URL), ponieważ podobnie jak nowa render()funkcja, automatycznie używa RequestContexti wszystkich swoich context_processor.

direct_to_template Należy jednak tego unikać, ponieważ widoki ogólne oparte na funkcji są przestarzałe. Albo użyj renderalbo rzeczywistą klasę, patrz https://docs.djangoproject.com/en/1.3/topics/generic-views-migration/

Cieszę się, że od RequestContextdawna nie pisałem .

Odświeżanie odpowiedzi Yuriego, Fábio i Frostsa dla Django noob (tj. Mnie) - prawie na pewno uproszczenie, ale dobry punkt wyjścia?

• render_to_response()jest „oryginalny”, ale wymaga przez context_instance=RequestContext(request)cały czas posiadania PITA.

• direct_to_template()jest przeznaczony do użycia tylko w urls.py bez widoku zdefiniowanego w views.py, ale można go używać w views.py, aby uniknąć konieczności wpisywania RequestContext

• render()jest skrótem do render_to_response()tego, który automatycznie dostarcza context_instance=Request... Jest dostępny w wersji rozwojowej django (1.2.1), ale wielu stworzyło własne skróty, takie jak ten , ten lub ten, który początkowo rzucił mi Nathans basic.tools. shortcuts.py

Renderowanie jest

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

Tak więc naprawdę nie ma różnicy, render_to_responsez wyjątkiem tego, że otacza kontekst, dzięki czemu preprocesory szablonu działają.

Bezpośrednio do szablonu jest ogólny widok .

Naprawdę nie ma sensu używać go tutaj, ponieważ narzuca się narzut render_to_responsew postaci funkcji widoku.

Z dokumentów django :

Render () to to samo, co wywołanie render_to_response () z argumentem context_instance, który wymusza użycie obiektu RequestContext.

direct_to_templateto coś innego. To ogólny widok, który używa słownika danych do renderowania html bez potrzeby views.py, używasz go w urls.py. Dokumenty tutaj

Tylko jedną notatkę nie znalazłem w powyższych odpowiedziach. W tym kodzie:

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

Co context_instancefaktycznie robi trzeci parametr ? Będąc RequestContext ustawia podstawowy kontekst, który jest następnie dodawany user_context. Szablon otrzymuje więc ten rozszerzony kontekst. Jakie zmienne są dodawane są TEMPLATE_CONTEXT_PROCESSORSw pliku settings.py. Na przykład django.contrib.auth.context_processors.auth dodaje zmiennąuser i zmienne, permktóre są następnie dostępne w szablonie.