Django-de

Django Dokumentation

Generische Views

Diese Dokumentation gilt für Djangos Entwicklerversion, die zum Teil erhebliche Unterschiede zur letzten veröffentlichen Version aufweist.

Das Entwickeln von Webanwendungen kann sehr monoton sein, weil man bestimmte Muster wieder und wieder anwendet. In Django wurden die meisten dieser Muster in so genannte “generische Views” abstrahiert. Dadurch wird es möglich, alltägliche Darstellungen bestimmter Objekte zu erstellen, ohne überhaupt Python-Code zu schreiben.

Django bietet generische Views für die folgenden Fälle:

  • Ein Satz Views für Listen und Detail-Ansichten (z.B. Djangos Dokumentations Index und Detail Seiten).
  • Ein Satz Views für Archiv Seiten mit einer chronologischen Struktur (Jahr/Monat/Tag) und die dazugehörigen Detail und “latest” Seiten (z.B. die Jahr, Monat, Tag, Detail und Latest Seiten aus Djangos Weblog.)
  • Ein Satz Views für das Anlegen, Bearbeiten und Löschen von Objekten.

Alle diese Views werden benutzt, indem man in der URL-Konfiguration ein Dictionary anlegt, welches dann als dritter Parameter im URLconf-Tupel an ein bestimmtes URL-Muster übergeben wird. Als Beispiel ist nachfolgend die URL-Konfiguration für das einfache Weblog auf djangoproject.com zu sehen:

from django.conf.urls.defaults import *
from django_website.apps.blog.models import Entry

info_dict = {
    'queryset': Entry.objects.all(),
    'date_field': 'pub_date',
}

urlpatterns = patterns('django.views.generic.date_based',
   (r'^(?P<year>\d{4})/(?P<month>[a-z]{3})/(?P<day>\w{1,2})/(?P<slug>[-\w]+)/$', 'object_detail', info_dict),
   (r'^(?P<year>\d{4})/(?P<month>[a-z]{3})/(?P<day>\w{1,2})/$',               'archive_day',   info_dict),
   (r'^(?P<year>\d{4})/(?P<month>[a-z]{3})/$',                                'archive_month', info_dict),
   (r'^(?P<year>\d{4})/$',                                                    'archive_year',  info_dict),
   (r'^$',                                                                    'archive_index', info_dict),
)

Wie man sehen kann, definiert diese URL-Konfiguration einige Optionen im info_dict. 'queryset' gibt dem generischen View ein QuerySet mit den zu benutzenden Objekten (in diesem Fall alle Entry Objekte) und teilt dem generischen View so mit, welches Model benutzt werden soll.

Es folgt die Dokumentation aller generischen Views, zusammen mit einer Liste aller Keyword-Argumente, die ein generischer View erwartet. Merke dass, wie im Beispiel weiter oben, Argumente entweder aus dem URL-Muster (hier: month, day, year, etc.) oder aus dem zusätzlichen Dictionary (hier: queryset, date_field) kommen können.

Die meisten generischen Views benötigen den queryset Parameter, welcher eine QuerySet-Instanz ist. Weitere Information über QuerySet-Objekte findet man in der Datenbank-API Dokumentation.

Die meisten generischen Views akzeptieren optional ein extra_context-Dictionary, welches man benutzen kann, um zusätzliche Information an den View zu übergeben. Die Werte im extra_context-Dictionary können entweder Funktionen (bzw. Callables) oder andere Objekte sein. Funktionen werden ausgewertet, bevor sie an das Template übergeben werden. Beachte aber, dass QuerySets ihre Daten cachen, wenn sie das erste Mal ausgewertet werden. Will man also ein QuerySet im extra_context übergeben, welches immer aktuelle Daten enthält, muss man es in einer Funktion oder Lambda-Konstrukt kapseln, welches das QuerySet zurück gibt.

“Einfache” generische Views

Das Modul django.views.generic.simple enthält einfache Views, die einige der alltäglichen Fälle abdecken: Templates rendern, wenn keine Logik nötig ist und das Auslösen von Redirects.

simple.direct_to_template

Vollständiger Pfad zum View: django.views.generic.simple.direct_to_template

Beschreibung:

Rendert ein Template und übergibt dabei die Template-Variable {{ params }}, welches ein Dictionary mit den erfassten Werten aus dem URL-Muster ist.

Erforderliche Argumente:

  • template: Der vollständige Name des Templates, welches gerendert werden soll.

Optionale Argumente:

  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.
  • mimetype: Der MIME-Typ, der für das entstehende Dokument benutzt werden soll. Standardmäßig wird der Wert der Einstellung DEFAULT_CONTENT_TYPE benutzt.

Beispiel:

Vorausgesetzt es existiert das folgende URL-Muster:

urlpatterns = patterns('django.views.generic.simple',
    (r'^foo/$',             'direct_to_template', {'template': 'foo_index.html'}),
    (r'^foo/(?P<id>\d+)/$', 'direct_to_template', {'template': 'foo_detail.html'}),
)

… ein Aufruf von /foo/ würde das Template foo_index.html rendern und ein Aufruf von /foo/15/ würde das Template foo_detail.html mit der Context-Variablen {{ params.id }} mit dem Wert 15 rendern.

simple.redirect_to

Vollständiger Pfad zum View: django.views.generic.simple.redirect_to

Beschreibung:

Löst eine HTTP-Umleitung zu einer gegebenen URL aus.

Die gegebene URL kann Dictionary String Formatierungen enthalten, welche dann mit den Werten, welche im URL-Muster erfasst werden, gefüllt werden.

Entspricht die gegebene URL None, wird Django ein HttpResponseGone (410) senden.

Erforderliche Argumente:

  • url: Die URL, auf die umgeleitet werden soll, entweder ein String oder None, um einen HTTP Fehler 410 (Verschwunden) auszulösen.

Beispiel:

Dieses Beispiel leitet von /foo/<id>/ nach /bar/<id>/ um:

urlpatterns = patterns('django.views.generic.simple',
    ('^foo/(?P<id>\d+)/$', 'redirect_to', {'url': '/bar/%(id)s/'}),
)

Dieses Beispiel gibt für Anfragen nach /bar/ einen HTTP Fehler 410 zurück:

urlpatterns = patterns('django.views.generic.simple',
    ('^bar/$', 'redirect_to', {'url': None}),
)

Datumsbasierte generische Views

Datumsbasierte generische Views (im Modul django.views.generic.date_based) sind Views zur Darstellung von chronologischen Daten.

date_based.archive_index

Vollständiger Pfad zum View: django.views.generic.date_based.archive_index

Beschreibung:

Eine übergeordnete Übersichtsseite, welche die “neusten” Objekte anzeigt, geordnet nach Datum. Objekte mit einem Datum in der Zukunft werden nicht angezeigt, außer es wird explizit allow_future auf True gesetzt.

Erforderliche Argumente:

  • queryset: Ein QuerySet mit Objekten für welche das Archiv dargestellt werden soll.
  • date_field: Der Name des DateField oder DateTimeField im dem QuerySet zugrunde liegenden Model.

Optionale Argumente:

  • num_latest: Die Anzahl der letzten (neuesten) Objekte, die an den Template-Context gesendet werden sollen. Standardmäßig sind es 15 Stück.
  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).
  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.
  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.
  • allow_empty: Ein boolscher Wert, welcher angibt ob die Seite auch angezeigt werden soll, wenn keine Objekte vorhanden sind. Ist der Wert False und keine Objekte sind vorhanden, wird der View einen 404 auslösen, statt eine leere Seite anzuzeigen. Standardmäßig ist dieser Wert True.
  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.
  • mimetype: Der MIME-Typ, der für das entstehende Dokument benutzt werden soll. Standardmäßig wird der Wert der Einstellung DEFAULT_CONTENT_TYPE benutzt.
  • allow_future: Ein boolscher Wert, welcher angibt ob Objekte mit einem Datum in der Zukunft dargestellt werden sollen. Ein Datum liegt in der Zukunft, wenn der Wert des Feldes, welches in date_field angegeben wurde, größer als das aktuelle Datum (bzw. Datum mit Uhrzeit) ist. Standardmäßig ist allow_future auf False gesetzt.
  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'latest'.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_archive.html benutzen, wobei:

  • <model_name> ist der Name des Datenmodells, komplett in Kleinbuchstaben. Für ein Model StaffMember wäre es staffmember.
  • <app_label> ist der letzte Teil des kompletten Python-Pfades zu der (Django-) Anwendung, in dem sich das Model befinde. Wenn das Model zum Beispiel in apps/blog/models.py definiert ist, wäre das app_label 'blog'.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • date_list: Eine Liste mit datetime.date Objekten. Die Objekte repräsentieren alle Jahre, für die Objekte laut queryset vorhanden sind. Die Sortierung ist rückwärts und die Daten sind gleichbedeutend mit queryset.dates(date_field, 'year')[::-1].

  • latest: Die num_latest letzten Objekte im System, geordnet absteigend nach date_field. Wenn zum Beispiel num_latest den Wert 10 hat, dann ist latest eine Liste der 10 neusten Objekte im QuerySet queryset.

    Der Variablenname hängt vom Parameter template_object_name ab, standardmäßig ist der Name 'latest'. Hat template_object_name den Wert 'foo', dann heißt diese Template-Variable foo.

date_based.archive_year

Vollständiger Pfad zum View: django.views.generic.date_based.archive_year

Beschreibung:

Eine Archiv-Seite, welche alle verfügbaren Monate in einem gegeben Jahr anzeigt. Objekte mit einem Datum in der Zukunft, werden nur angezeigt, wenn allow_future auf True gesetzt ist.

Erforderliche Argumente:

  • year: Das Jahr, bestehend aus vier Ziffern, für welches die Archiv-Seite sein soll.
  • queryset: Ein QuerySet mit Objekten für welche das Archiv dargestellt werden soll.
  • date_field: Der Name des DateField oder DateTimeField im dem QuerySet zugrunde liegenden Model.

Optionale Argumente:

  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).
  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.
  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.
  • allow_empty: Ein boolscher Wert, welcher angibt ob die Seite auch angezeigt werden soll, wenn keine Objekte vorhanden sind. Ist der Wert False und keine Objekte sind vorhanden, wird der View einen 404 auslösen, statt eine leere Seite anzuzeigen. Standardmäßig ist dieser Wert True.
  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.
  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'object'. Der View wird '_list' an den Wert dieser Variablen anhängen, um den endgültigen Namen der Template-Variablen zu bestimmen.
  • make_object_list: Ein boolschwer Wert, welcher angibt, ob eine komplette Liste mit Objekten für dieses Jahr erstellt und an das Template übergeben werden soll. Ist der Wert True, wird die Liste als object_list an das Template übergeben. (Der Name kann anders sein; näheres dazu weiter unten in der “Template-Context” Dokumentation.) Standardmäßig ist der Wert False.
  • mimetype: Der MIME-Typ, der für das entstehende Dokument benutzt werden soll. Standardmäßig wird der Wert der Einstellung DEFAULT_CONTENT_TYPE benutzt.
  • allow_future: Ein boolscher Wert, welcher angibt ob Objekte mit einem Datum in der Zukunft dargestellt werden sollen. Ein Datum liegt in der Zukunft, wenn der Wert des Feldes, welches in date_field angegeben wurde, größer als das aktuelle Datum (bzw. Datum mit Uhrzeit) ist. Standardmäßig ist allow_future auf False gesetzt.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_archive_year.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • date_list: Eine Liste mit datetime.date Objekten. Die Objekte repräsentieren alle Monate im gegebenen Jahr, für die Objekte laut queryset vorhanden sind. Die Sortierung ist aufsteigend.

  • year: Das gegebene Jahr als String mit 4 Zeichen.

  • object_list: Wenn make_object_list den Wert True hat, wird diese Variable eine Liste mit allen für dieses Jahr verfügbaren Objekten enthalten, geordnet nach dem date_field.

    Der Variablenname hängt ab vom Parameter template_object_name, standardmäßig ist der Name 'object'. Hat template_object_name den Wert 'foo', dann heißt diese Template-Variable foo_list.

    Hat make_object_list den Wert False, wird object_list als leere Liste an das Template übergeben.

date_based.archive_month

Vollständiger Pfad zum View: django.views.generic.date_based.archive_month

Beschreibung:

Eine Archiv-Seite, welche alle Objekte für einen gegebenen Monat anzeigt. Objekte mit einem Datum in der Zukunft, werden nur angezeigt, wenn allow_future auf True gesetzt ist.

Erforderliche Argumente:

  • year: Das Jahr, bestehend aus vier Ziffern, für welches die Archiv-Seite sein soll (als String).
  • month: Der Monat, für den das Archiv dargestellt werden soll, formatiert nach dem in month_format angegebenen Format.
  • queryset: Ein QuerySet mit Objekten, für welche das Archiv dargestellt werden soll.
  • date_field: Der Name des DateField oder DateTimeField im dem QuerySet zugrunde liegenden Model.

Optionale Argumente:

  • month_format: Ein Format-String, welcher angibt, wie der Paramter month formatiert ist. Die Syntax sollte der Python Funktion time.strftime entsprechen (Siehe dazu: strftime Dokumentation). Standardmäßig ist es auf "%b" gesetzt, welches einer Abkürzung der Monate in drei Buchstaben entspricht. Um Zahlen zu verwenden, kann es auf "%m" geändert werden.
  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).
  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.
  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.
  • allow_empty: Ein boolscher Wert, welcher angibt ob die Seite auch angezeigt werden soll, wenn keine Objekte vorhanden sind. Ist der Wert False und keine Objekte sind vorhanden, wird der View einen 404 auslösen, statt eine leere Seite anzuzeigen. Standardmäßig ist dieser Wert True.
  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.
  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'object'. Der View wird '_list' an den Wert dieser Variablen anhängen, um den endgültigen Namen der Template-Variablen zu bestimmen.
  • mimetype: Der MIME-Typ, der für das entstehende Dokument benutzt werden soll. Standardmäßig wird der Wert der Einstellung DEFAULT_CONTENT_TYPE benutzt.
  • allow_future: Ein boolscher Wert, welcher angibt ob Objekte mit einem Datum in der Zukunft dargestellt werden sollen. Ein Datum liegt in der Zukunft wenn, der Wert des Feldes, welches in date_field angegeben wurde, größer als das aktuelle Datum (bzw. Datum mit Uhrzeit) ist. Standardmäßig ist allow_future auf False gesetzt.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_archive_month.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • month: Der gegebene Monat als datetime.date-Objekt.
  • next_month: Ein datetime.date-Objekt, welches den ersten Tag des nächsten Monats repräsentiert. Liegt das Datum in der Zukunft ist der Wert None.
  • previous_month: Ein datetime.date-Objekt, welches den ersten Tag des vorherigen Monats repräsentiert. Anders als bei next_month wird dieser Wert nie None sein.
  • object_list: Eine Liste mit allen für den Monat month verfügbaren Objekten. Der Variablenname hängt ab vom Parameter template_object_name, standardmäßig ist der Name 'object'. Hat template_object_name den Wert 'foo', dann heißt diese Template-Variable foo_list.

date_based.archive_week

Vollständiger Pfad zum View: django.views.generic.date_based.archive_week

Beschreibung:

Eine Archiv-Seite, welche alle Objekte für eine gegebene Woche anzeigt. Objekte mit einem Datum in der Zukunft, werden nur angezeigt, wenn allow_future auf True gesetzt ist.

Erforderliche Argumente:

  • year: Das Jahr, bestehend aus vier Ziffern, für welches die Archiv-Seite sein soll (als String).
  • week: Die Woche, für die das Archiv dargestellt werden soll (als String). Wochen beginnen am Sonntag.
  • queryset: Ein QuerySet mit Objekten für welche das Archiv dargestellt werden soll.
  • date_field: Der Name des DateField oder DateTimeField im dem QuerySet zugrunde liegenden Model.

Optionale Argumente:

  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).
  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.
  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.
  • allow_empty: Ein boolscher Wert, welcher angibt ob die Seite auch angezeigt werden soll, wenn keine Objekte vorhanden sind. Ist der Wert False und keine Objekte sind vorhanden, wird der View einen 404 auslösen, statt eine leere Seite anzuzeigen. Standardmäßig ist dieser Wert True.
  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.
  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'object'. Der View wird '_list' an den Wert dieser Variablen anhängen, um den endgültigen Namen der Template-Variablen zu bestimmen.
  • mimetype: Der MIME-Typ, der für das entstehende Dokument benutzt werden soll. Standardmäßig wird der Wert der Einstellung DEFAULT_CONTENT_TYPE benutzt.
  • allow_future: Ein boolscher Wert, welcher angibt ob Objekte mit einem Datum in der Zukunft dargestellt werden sollen. Ein Datum liegt in der Zukunft wenn, der Wert des Feldes, welches in date_field angegeben wurde, größer als das aktuelle Datum (bzw. Datum mit Uhrzeit) ist. Standardmäßig ist allow_future auf False gesetzt.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_archive_week.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • week: Ein datetime.date-Objekt, welches den ersten Tag der angegebenen Woche repräsentiert.
  • object_list: Eine Liste mit allen für die Woche week verfügbaren Objekten. Der Variablenname hängt ab vom Parameter template_object_name, standardmäßig ist der Name 'object'. Hat template_object_name den Wert 'foo', dann heißt diese Template-Variable foo_list.

date_based.archive_day

Vollständiger Pfad zum View: django.views.generic.date_based.archive_day

Beschreibung:

Eine Archiv-Seite, welche alle Objekte für einen gegebenen Tag anzeigt. Tage mit einem Datum in der Zukunft lösen einen HTTP 404 Fehler (Nicht gefunden) aus, unabhängig davon, ob Objekte für den Tag vorhanden sind oder nicht, es sei denn allow_future ist auf True gesetzt.

Erforderliche Argumente:

  • year: Das Jahr, bestehend aus vier Ziffern, für welches die Archiv-Seite sein soll (als String).
  • month: Der Monat, für den das Archiv dargestellt werden soll, formatiert nach dem in month_format angegebenen Format.
  • day: Der Tag, für den das Archiv dargestellt werden soll, formatiert nach dem in day_format angegebenen Format.
  • queryset: Ein QuerySet mit Objekten für welche das Archiv dargestellt werden soll.
  • date_field: Der Name des DateField oder DateTimeField im dem QuerySet zugrunde liegenden Model.

Optionale Argumente:

  • month_format: Ein Format-String, welcher angibt, wie der Paramter month formatiert ist. Die Syntax sollte der, der Python Funktion time.strftime entsprechen (Siehe dazu: strftime Dokumentation). Standardmäßig ist es auf "%b" gesetzt, welches einer Abkürzung der Monate in drei Buchstaben entspricht. Um Zahlen zu verwenden, kann es auf "%m" geändert werden.
  • day_format: Genau wie month_format, aber für den Parameter day. Standardmäßig auf "%d" gesetzt (Tag des Monats als Dezimalzahl, 01-31).
  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).
  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.
  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.
  • allow_empty: Ein boolscher Wert, welcher angibt ob die Seite auch angezeigt werden soll, wenn keine Objekte vorhanden sind. Ist der Wert False und keine Objekte sind vorhanden, wird der View einen 404 auslösen, statt eine leere Seite anzuzeigen. Standardmäßig ist dieser Wert True.
  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.
  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'object'. Der View wird '_list' an den Wert dieser Variablen anhängen, um den endgültigen Namen der Template-Variablen zu bestimmen.
  • mimetype: Der MIME-Typ, der für das entstehende Dokument benutzt werden soll. Standardmäßig wird der Wert der Einstellung DEFAULT_CONTENT_TYPE benutzt.
  • allow_future: Ein boolscher Wert, welcher angibt ob Objekte mit einem Datum in der Zukunft dargestellt werden sollen. Ein Datum liegt in der Zukunft wenn, der Wert des Feldes, welches in date_field angegeben wurde, größer als das aktuelle Datum (bzw. Datum mit Uhrzeit) ist. Standardmäßig ist allow_future auf False gesetzt.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_archive_day.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • day: Der gegebene Tag als datetime.date-Objekt.
  • next_day: Der nächste Tag als datetime.date-Objekt. Liegt das Datum in der Zukunft ist der Wert None.
  • previous_day: Der vorherige Tag als datetime.date-Objekt. Anders als bei next_day wird dieser Wert nie None sein.
  • object_list: Eine Liste mit allen für den Tag day verfügbaren Objekten. Der Variablenname hängt ab vom Parameter template_object_name, standardmäßig ist der Name 'object'. Hat template_object_name den Wert 'foo', dann heißt diese Template-Variable foo_list.

date_based.archive_today

Vollständiger Pfad zum View: django.views.generic.date_based.archive_today

Beschreibung:

Eine Archiv-Seite, die alle Objekte für Heute anzeigt. Der View funktioniert, genauso, wie der archive_day-View mit dem Unterschied, dass die year/month/day Argumente nicht benutzt werden, stattdessen wir das aktuelle Datum verwendet.

date_based.object_detail

Vollständiger Pfad zum View: django.views.generic.date_based.object_detail

Beschreibung:

Eine Seite, die ein einzelnes Objekt repräsentiert. Hat das Objekt ein Datum in der Zukunft, wird der View einen 404 Fehler auslösen, es sei denn allow_future hat den Wert True.

Erforderliche Argumente:

  • year: Das Jahr des Objekts, als String aus vier Ziffern.

  • month: Der Monat des Objekts, formatiert nach dem in month_format angegebenen Format.

  • day: Der Tag des Objekts, formatiert nach dem in day_format angegebenen Format.

  • queryset: Ein QuerySet, welches das Objekt enthält.

  • date_field: Der Name des DateField oder DateTimeField im dem QuerySet zugrunde liegenden Model, welches der View verwenden soll um an Hand von year, month und day das Objekt zu finden.

  • Entweder object_id oder (slug und slug_field) ist erforderlich.

    Ist object_id gegeben, sollte es den Wert des Primary-Key Feldes für das Objekt haben, welches angezeigt werden soll.

    Andernfalls sollte slug der Slug des Objekts sein und slug_field sollte den Wert des Feldes im dem QuerySet zugrunde liegenden Model sein. Standardmäßig hat slug_field den Wert 'slug'.

Optionale Argumente:

  • month_format: Ein Format-String, welcher angibt, wie der Paramter month formatiert ist. Die Syntax sollte der, der Python Funktion time.strftime entsprechen (Siehe dazu: strftime Dokumentation). Standardmäßig ist es auf "%b" gesetzt, welches einer Abkürzung der Monate in drei Buchstaben entspricht. Um Zahlen zu verwenden, kann es auf "%m" geändert werden.

  • day_format: Genau wie month_format, aber für den Parameter day. Standardmäßig auf "%d" gesetzt (Tag des Monats als Dezimalzahl, 01-31).

  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).

  • template_name_field: Der Name des Feldes im Model, dessen Wert angibt, welches Template benutzt werden soll. Damit ist es möglich Template-Namen direkt in den Daten zu speichern. Anders gesagt: wenn das Objekt ein Feld the_template hat, welches den Wert foo.html hat und template_name_field aus 'the_template' gesetzt ist, wird der generische View für dieses Objekt das Template 'foo.html' benutzen.

    Klingt auf den ersten Blick kompliziert, ist aber manchmal sehr hilfreich.

  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.

  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.

  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.

  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'object'.

  • mimetype: Der MIME-Typ, der für das entstehende Dokument benutzt werden soll. Standardmäßig wird der Wert der Einstellung DEFAULT_CONTENT_TYPE benutzt.

  • allow_future: Ein boolscher Wert, welcher angibt ob Objekte mit einem Datum in der Zukunft dargestellt werden sollen. Ein Datum liegt in der Zukunft, wenn der Wert des Feldes, welches in date_field angegeben wurde, größer als das aktuelle Datum (bzw. Datum mit Uhrzeit) ist. Standardmäßig ist allow_future auf False gesetzt.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_detail.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • object: Das Objekt. Der Variablenname hängt vom Parameter template_object_name ab, standardmäßig ist der Name 'object'. Hat template_object_name den Wert 'foo', dann heißt diese Template-Variable foo.

Generische List- und Detail-Views

Das list-detail Generic-View-Framework (im django.views.generic.list_detail Modul) ist dem datum-basierten ähnlich, abgesehen davon, dass es nur zwei Views hat: einen für eine Liste von Objekten und einen für eine einzelne Objekt-Seite.

list_detail.object_list

Vollständiger Pfad zum View: django.views.generic.list_detail.object_list

Beschreibung:

Eine Seite, die eine Liste von Objekten darstellt.

Erforderliche Argumente:

  • queryset: Ein QuerySet das die Objekte repräsentiert.

Optionale Argumente:

  • paginate_by: Ein Integer, der angibt wie viele Objekte auf einer Seite angezeigt werden sollen. Ist ein Wert angegeben, werden paginate_by Objekte pro Seite angezeigt. Der View erwartet dann entweder einen Query-String Parameter oder eine Variable page, welche über die URL-Konfiguration übergeben wird. Beachte bitte die weiteren Hinweise zum Thema Pagination weiter unten.
  • page query string parameter (via GET)
  • page: Die aktuelle Seitenzahl als Integer. Gezählt wird ab 1. Beachte bitte die weiteren Hinweise zum Thema Pagination weiter unten.
  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).
  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.
  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.
  • allow_empty: Ein boolscher Wert, welcher angibt ob die Seite auch angezeigt werden soll, wenn keine Objekte vorhanden sind. Ist der Wert False und keine Objekte sind vorhanden, wird der View einen 404 auslösen, statt eine leere Seite anzuzeigen. Standardmäßig ist dieser Wert True.
  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.
  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'object'. Der View wird '_list' an den Wert dieser Variablen anhängen, um den endgültigen Namen der Template-Variablen zu bestimmen.
  • mimetype: Der MIME-Typ, der für das entstehende Dokument benutzt werden soll. Standardmäßig wird der Wert der Einstellung DEFAULT_CONTENT_TYPE benutzt.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_list.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • object_list: Die Liste der Objekte. Der Variablenname hängt vom Parameter template_object_name ab, standardmäßig ist der Name 'object'. Hat template_object_name den Wert 'foo', dann heißt diese Template-Variable foo_list.
  • is_paginated: Ein boolscher Wert, der angibt ob die Ergebnisse auf mehrere Seiten verteilt sind. Der Wert ist False für den Fall, dass weniger oder gleich viele Objekte vorhanden sind, wie in paginate_by angegeben.

Wenn die Ergebnisse über mehrere Seite verteilt sind, wird der Template-Context folgende zusätzliche Variablen enthalten:

  • paginator: Eine Instanz von django.core.paginator.Paginator.
  • page_obj: Eine Instanz von django.core.paginator.Page.

In älteren Django-Versionen, bevor paginator und page_obj zum Template-Context hinzugefügt wurden, enthielt der Template-Context einige andere Variablen zum Thema Pagination. Diese Variablen sollten nicht mehr benutzt werden, stattdessen bitte nur noch paginator und page_obj benutzen, da man mit diesen alles erreichen kann, was auch mit den alten Variablen möglich war (und sogar mehr!). Für alle, die noch eine alte Django-Version benutzen, folgt hier eine Liste der alten Variablen:

  • results_per_page: Die Anzahl der Objekte pro Seite. (Entspricht dem paginate_by Parameter.)
  • has_next: Ein boolscher Wert, der angibt, ob es eine nächste Seite gibt.
  • has_previous: Ein boolscher Wert, der angibt, ob es eine vorherige Seite gibt.
  • page: Die aktuelle Seitenzahl als Integer, gezählt ab 1.
  • next: Die nächste Seitenzahl als Integer. Gibt es keine nächste Seite, ist dieser Wert die theoretisch nächste Seite. Ebenfalls gezählt ab 1.
  • previous: Die vorherige Seitenzahl als Integer, gezählt ab 1.
  • last_on_page: Die Nummer des letzten Ergebnisses auf der aktuellen Seite. Gezählt ab 1.
  • first_on_page: Die Nummer des ersten Ergebnisses auf der aktuellen Seite. Gezählt ab 1.
  • pages: Die Anzahl der verfügbaren Seiten als Integer.
  • hits: Die Anzahl aller Objekte, gezählt über alle Seiten, nicht nur auf der aktuellen.
  • page_range: Eine Liste mit allen Seitenzahlen die verfügbar sind. Gezählt ab 1.

Hinweise zum Thema Pagination

Ist paginate_by gesetzt, wird Django die Ergebnisse automatisch auf nummerierte Seiten aufteilen. Man kann die Seitenzahl in der URL auf zwei Arten angeben:

  • Mit dem page Parameter in der URL-Konfiguration. Die URL-Konfiguration könnte zum Beispiel so aussehen:

    (r'^objects/page(?P<page>[0-9]+)/$', 'object_list', dict(info_dict))

  • Die Seitenzahl kann im Querystring als Parameter page an die URL angehängt werden. Eine URL könnte zum Beispiel so aussehen:

    /objects/?page=3

  • Um über alle verfügbaren Seitenzahlen zu iterieren gibt es die Variable page_range Mit einer Schleife über alle Zahlen in page_range kann man z.B. einen Link zu jeder Seite der Ergebnisse erstellen.

Alle Werte und Listen fangen bei 1 an, nicht bei 0. Das heißt, die erste Seite ist Seite 1.

Ein Beispiel für die Anwendung von Pagination gibt es im Objekt Pagination Beispiel-Model.

Als Sonderfall kann man auch last als Wert für page verwenden:

/objects/?page=last

Dies erlaubt es, einfach die letzte Seite der Ergebnisse zu erreichen, ohne zuerst zu ermitteln, wie viele Seiten es gibt.

Beachte: page muss entweder eine gültige Seitenzahl oder den Wert last besitzen, andernfalls wird ein HTTP 404 Fehler ausgelöst.

list_detail.object_detail

Vollständiger Pfad zum View: django.views.generic.list_detail.object_detail

Beschreibung:

Eine Seite, die ein einzelnes Objekt repräsentiert.

Erforderliche Argumente:

  • queryset: Ein QuerySet, welches das Objekt enthält.

  • Entweder object_id oder (slug und slug_field) ist erforderlich.

    Ist eine object_id gegeben, so ist es der Wert für das Primary-Key Feld des anzuzeigenden Objekts.

    Andernfalls ist slug der Slug für das anzuzeigende Objekt und slug_field sollte der Name des Slug-Feldes im Model des QuerySet``s sein. Standardmäßig hat ``slug_field den Wert 'slug'.

Optionale Argumente:

  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).

  • template_name_field: Der Name des Feldes im Model, dessen Wert angibt, welches Template benutzt werden soll. Damit ist es möglich Template-Namen direkt in den Daten zu speichern, anders gesagt, wenn das Objekt ein Feld the_template hat, welches den Wert foo.html hat und template_name_field aus 'the_template' gesetzt ist, wird der generische View für dieses Objekt das Template 'foo.html' benutzen.

    Klingt auf den ersten Blick kompliziert, ist aber manchmal sehr hilfreich.

  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.

  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.

  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.

  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'object'.

  • mimetype: Der MIME-Typ, der für das entstehende Dokument benutzt werden soll. Standardmäßig wird der Wert der Einstellung DEFAULT_CONTENT_TYPE benutzt.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_detail.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • object: Das Objekt. Der Variablenname hängt vom Parameter template_object_name ab, welcher standardmäßig den Wert 'object' hat. Hat template_object_name den Wert 'foo', lautet der Variablenname foo.

Generische Views zum Anlegen/Aktualisieren/Löschen

Das Modul django.views.generic.create_update enthält einen Satz von Funktionen um Objekte zu erstellen, zu bearbeiten und zu löschen.

create_update.create_object

Vollständiger Pfad zum View: django.views.generic.create_update.create_object

Beschreibung:

Eine Seite, die ein Formular zum anlegen und speichern von Objekten anzeigt. Bei Validierungsfehler wird die Seite zusammen mit den Fehlermeldungen (wenn es welche gibt) noch einmal angezeigt. Dieser View benutzt die automatischen Manipulatoren, die jedes Django-Datenmodell besitzt.

Erforderliche Argumente:

  • model: Die Django-Model-Klasse, für welche das Formular Objekte anlegen soll.

Optionale Argumente:

  • post_save_redirect: Die URL, auf die der View nach dem Speichern per HTTP-Redirect umleiten wird. Standardmäßig ist es object.get_absolute_url().

    post_save_redirect kann Dictionary String Formatierungen enthalten, welche gegen die Attribute des Objekts interpoliert werden. Zum Beispiel post_save_redirect="/polls/%(slug)s/".

  • login_required: Ein boolscher Wert, welcher angibt ob ein Benutzer eingeloggt sein muss um die Seite zu sehen und Änderungen zu speichern. Diese klinkt sich in Djangos Authentifizierungs System ein. Standardmäßig ist dieser Wert False.

    Ist der Wert True, wird ein nicht eingeloggter Benutzer, der versucht die Seite aufzurufen oder das Formular abzusenden, per HTTP-Redirect nach /accounts/login/ weitergeleitet. (Anm. Übersetzer: eigentlich nach django.contrib.auth.LOGIN_URL)

  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).

  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.

  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.

  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_form.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • form: Eine django.oldforms.FormWrapper Instanz, welche das Formular zum editieren des Objekts enthält. Dadurch kann man im Template sehr einfach auf die Formularfelder zugreifen.

    Hier ein Beispiel, model hat die beiden Felder name und address:

    <form action="" method="post">
<p><label for="id_name">Name:</label> {{ form.name }}</p>
<p><label for="id_address">Address:</label> {{ form.address }}</p>
</form>

    Mehr über den Gebrauch von FormWrapper-Objekten in Templates steht in der Manipulator und Formfeld Dokumentation.

create_update.update_object

Vollständiger Pfad zum View: django.views.generic.create_update.update_object

Beschreibung:

Eine Seite, die ein Formular zum editieren eines bestehendes Objektes. Bei Validierungsfehler wird die Seite erneut angezeigt (mit entsprechender Fehlermeldung), ansonsten werden die Änderungen für das Objekt abgespeichert. Dieser View benutzt die automatischen Manipulatoren, die in Djangos Models eingebaut sind.

Erforderliche Argumente:

  • model: Die Django-Model-Klasse, für welche das Formular Objekte anlegen soll.

  • Entweder object_id oder (slug und slug_field) ist erforderlich.

    Ist eine object_id gegeben, so ist es der Wert für das Primary-Key Feld des anzuzeigenden Objekts.

    Andernfalls ist slug der Slug für das anzuzeigende Objekt und slug_field sollte der Name des Slug-Feldes im Model des QuerySet``s sein. Standardmäßig hat ``slug_field den Wert 'slug'.

Optionale Argumente:

  • post_save_redirect: Die URL, auf die der View nach dem Speichern per HTTP-Redirect umleiten wird. Standardmäßig ist es object.get_absolute_url().

    post_save_redirect kann Dictionary String Formatierungen enthalten, welche gegen die Attribute des Objekts interpoliert werden. Zum Beispiel post_save_redirect="/polls/%(slug)s/".

  • login_required: Ein boolscher Wert, welcher angibt ob ein Benutzer eingeloggt sein muss um die Seite zu sehen und Änderungen zu speichern. Dies klinkt sich in Djangos Authentifizierungs System ein. Standardmäßig ist dieser Wert False.

    Ist der Wert True, wird ein nicht eingeloggter Benutzer, der versucht die Seite aufzurufen oder das Formular abzusenden, per HTTP-Redirect nach /accounts/login/ weitergeleitet. (Anm. Übersetzer: eigentlich nach django.contrib.auth.LOGIN_URL)

  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).

  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.

  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.

  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.

  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'object'.

Template name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_form.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • form: Eine django.oldforms.FormWrapper Instanz, welche das Formular zum editieren des Objekts enthält. Dadurch kann man im Template sehr einfach auf die Formularfelder zugreifen.

    Hier ein Beispiel, model hat die beiden Felder name und address:

    <form action="" method="post">
<p><label for="id_name">Name:</label> {{ form.name }}</p>
<p><label for="id_address">Address:</label> {{ form.address }}</p>
</form>

    Mehr über den Gebrauch von FormWrapper-Objekten in Templates steht in der Manipulator und Formfeld Dokumentation.

  • object: Das Objekt, das grade editiert wird. Der Variablenname hängt vom Parameter template_object_name ab, welcher standardmäßig den Wert 'object' hat. Hat template_object_name den Wert 'foo', lautet der Variablenname foo.

create_update.delete_object

Vollständiger Pfad zum View: django.views.generic.create_update.delete_object

Beschreibung:

Ein View, der eine Bestätigungsseite anzeigt und ein bestehendes Objekt löscht. Das Objekt wird nur gelöscht, wenn der Aufruf via POST geschieht, wird die Seite via GET aufgerufen, wird eine Bestätigungsseite angezeigt, welche ein Formular enthalten sollte, das per POST auf die selbe URL gesendet werden kann.

Erforderliche Argumente:

  • model: Die Django-Model-Klasse, für welche das Formular Objekte anlegen soll.

  • Entweder object_id oder (slug und slug_field) ist erforderlich.

    Ist eine object_id gegeben, so ist es der Wert für das Primary-Key Feld des anzuzeigenden Objekts.

    Andernfalls ist slug der Slug für das anzuzeigende Objekt und slug_field sollte der Name des Slug-Feldes im Model des QuerySet``s sein. Standardmäßig hat ``slug_field den Wert 'slug'.

  • post_delete_redirect: Eine URL, auf die nach dem Löschen per HTTP-Redirect umgeleitet wird.

Optionale Argumente:

  • login_required: Ein boolscher Wert, welcher angibt ob ein Benutzer eingeloggt sein muss um die Seite zu sehen und Änderungen zu speichern. Dies klingt sich in Djangos Authentifizierungs System ein. Standardmäßig ist dieser Wert False.

    Ist der Wert True, wird ein nicht eingeloggter Benutzer, der versucht die Seite aufzurufen oder das Formular abzusenden, per HTTP-Redirect nach /accounts/login/ weitergeleitet. (Anm. Übersetzer: eigentlich nach django.contrib.auth.LOGIN_URL)

  • template_name: Der volle Name des Templates, mit dem die Seite gerendert werden soll. Hiermit lässt sich das Standard-Template überschreiben (siehe unten).

  • template_loader: Der Template-Loader, der zum Laden des Templates benutzt werden soll, standardmäßig ist es django.template.loader.

  • extra_context: Ein Dictionay mit Werten, welche zum Templates-Context hinzugefügt werden. Standardmäßig handelt es sich hierbei um ein leeres Dictionary. Wenn ein Wert in dem Dictionary ausführbar ist, wird der generische View ihn direkt vor dem Rendern auswerten.

  • context_processors: Eine Liste mit Template-Context Prozessoren, welche auf das Template angewendet werden sollen. Siehe dazu die RequestContext Dokumentation.

  • template_object_name: Gibt den Namen der Template-Variablen an, die im Template-Context verwendet werden soll. Standardmäßig ist der Name 'object'.

Template-Name:

Wenn template_name nicht angegeben ist, wird dieser View das Template mit dem Namen <app_label>/<model_name>_confirm_delete.html benutzen.

Template-Context:

Zusätzlich zum extra_context wird der Template-Context folgendes enthalten:

  • object: Das Objekt, das grade editiert wird. Der Variablenname hängt vom Parameter template_object_name ab, welcher standardmäßig den Wert 'object' hat. Hat template_object_name den Wert 'foo', lautet der Variablenname foo.

Informationen

Schnellzugriff