</ p>" erstellen möchten, verwenden Sie "{{form.as_p}}".

{% csrf_token%} ist eine CSRF-Kennzahl. Erforderlich, wenn Sie mit Django ein POST-Formular usw. erstellt haben.

https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%AA

http://docs.djangoproject.jp/en/latest/ref/contrib/csrf.html

Sie können auch Formularobjekte wie "ModelForm" verwenden.

Auf diese Weise können Sie Ihre vorhandenen Formularklassen problemlos nutzen.

forms.py

from django import forms
from myapp.model import MyModel

class MyModelForm(forms.ModelForm):
    class Meta:
        model = MyModel
        fields = ("name", )

views.py

from forms import MyModelForm

class MyCreateView(CreateView):
    form_class = MyModelForm

Die Validierung ist auch ein wichtiges Merkmal dieser Formulare. Selbst wenn Sie das Formular mit großem Aufwand senden und ein Fehler bei der Validierung auftritt und es nicht hinzugefügt oder aktualisiert wird, kann es verwirrend sein, wenn Sie den Benutzer nicht benachrichtigen.

Daher werden in diesen allgemeinen Ansichten die Methoden form_valid und form_invalid definiert, und Sie können die erforderliche Verarbeitung ausführen, je nachdem, ob die Validierung bestanden wurde oder nicht.

Beispielsweise wird Benutzern häufig mitgeteilt, ob das von ihnen übermittelte Formular erfolgreich gespeichert wurde. Zu diesem Zeitpunkt verwendet Django das Nachrichten-Framework.

http://docs.djangoproject.jp/en/latest/ref/contrib/messages.html

views.py

from django.views.generic.edit import CreateView
from django.contrib import messages  #Nachrichten-Framework

from myapp.models import MyModel


class MyCreateView(CreateView):
    model = MyModel

    def form_valid(self, form):
        '''Nach bestandener Validierung'''
        messages.success(self.request, "Gerettet")
        return super().form_valid(form)

    def form_invalid(self, form):
        '''Wenn die Validierung fehlschlägt'''
        message.warning(self.request, "Konnte nicht speichern")
        return super().form_invalid(form)

Hier haben wir unsere eigenen Nachrichten zur Methode "form_valid" hinzugefügt, die aufgerufen wird, wenn die Validierung erfolgreich ist, und zur Methode "form_invalid", die aufgerufen wird, wenn die Validierung nicht erfolgreich ist.

Auf diese Weise können Sie Ihre eigene Verarbeitung hinzufügen. Zusätzlich zum obigen Beispiel können Sie eine Verarbeitung einfügen, z. B. den Administrator per E-Mail benachrichtigen, wenn ein Fehler auftritt.

Wenn Sie mit Ihrer eigenen Verarbeitung fertig sind, rufen Sie die Vererbungsmethode auf und geben Sie den Rückgabewert zurück.

Übrigens, um die Nachricht anzuzeigen, gehen Sie wie folgt vor. Der Inhalt des Dokuments ist so wie es ist.

{% if messages %}
<ul class="messages">
    {% for message in messages %}
    <li{% if message.tags %} class="{{ message.tags }}"{% endif %}>{{ message }}</li>
    {% endfor %}
</ul>
{% endif %}

DeleteView

Wie der Name schon sagt, löscht "DeleteView" einen Datensatz. Die Vorlage lautet "(AppName) / (AppName) _confirm_delete.html".

views.py

from django.views.generic.edit import DeleteView
from myapp.models import MyModel


class MyDeleteView(DeleteView):
    model = MyModel

In diesem Fall handelt es sich bei der Vorlage um ein Bestätigungsformular mit der Frage "Möchten Sie es wirklich löschen?".

Vielleicht gibt es Zeiten, in denen Sie nur das Löschflag aktivieren möchten, anstatt es wirklich zu löschen. In einem solchen Fall ist es besser, die Löschmethode zu überschreiben. Ich habe es jedoch nicht ausprobiert, weil ich es gehorsam lösche.

Gemeinsame Gegenstände

Zusätzlich zur oben genannten Verarbeitung kann die klassenbasierte Allzweckansicht den Namen der Vorlagendatei und den Variablennamen frei überschreiben. Darüber hinaus ist die Methode auch üblich, daher werde ich einige vorstellen. Ich denke, es ist normalerweise am besten, den Standardwert zu verwenden und ihn nur bei Bedarf zu überschreiben.

Standardvariable

Wie Sie vielleicht bereits bemerkt haben, haben generische Ansichten eine gewisse Regelmäßigkeit. Im ersten Schritt wurde das Überschreiben von get_context_data, das Ausführen der erforderlichen Verarbeitung und das Festlegen in einer Variablen eingeführt. Wenn Sie Daten an eine Vorlage übergeben möchten, sollte dies ausreichen.

Im Gegenteil, wenn eine Allzweckansicht automatisch Daten abruft, welche Art von Daten wird in welcher Variablen festgelegt?

Die klassenbasierte generische Ansicht ruft automatisch Daten aus der Datenbank entsprechend ihrer beabsichtigten Verwendung ab (erbende Klasse). Legen Sie fest, aus welcher Tabelle die Daten als model = MyModel abgerufen werden sollen.

views.py

class MyListView(ListView):
    model = MyModel  #Holen Sie sich automatisch eine Liste von MyModels

Auf diese Weise erhalten Sie die Daten von "MyModel". Das Ergebnis usw. soll in einer Variablen mit festem Namen gesetzt werden. "Objekt", wenn nur ein Datensatz vorhanden ist, z. B. eine einzelne Seite. Object_list wenn es mehr als eine gibt.

Die Vorlage würde folgendermaßen aussehen:

Einzelne Seiten etc.

{{ object }}

Wenn es mehrere gibt

{% for item in object_list %}
  {{ item }}
{% endfor %}

Ich kann jedoch anhand der Vorlage nicht sagen, was dies bedeutet. Möglicherweise möchten Sie den Variablennamen aussagekräftiger gestalten. Weisen Sie in diesem Fall den Variablennamen context_object_name zu.

views.py

class MyBookList(ListView):
    model = Books
    context_object_name = "my_books"  #Geben Sie den Variablennamen in diese Zeile ein

Auf diese Weise in der Vorlage

<ul>
    {% for book in my_books %}
    <li>{{ book.name }}</li>
    {% endfor %}
</ul>

Sie können es so nennen. Nachdem Sie nun wissen, worauf sich der Variablenname bezieht, können Sie leicht erkennen, worauf sich die Variable bezieht, indem Sie einfach die Vorlage lesen.

Angabe der Datei, die als Vorlage verwendet werden soll

Ansichten sind Controller. Übergeben Sie daher die Daten an die entsprechende Vorlage. Die Vorlage kann explizit angegeben werden, hat jedoch einen Standardvorlagennamen. das ist,

(ModelName)/(ModelName)_(ViewName).html

Das ist.

Sie sind,

• AppName
• Der Name der Anwendung, die von manage.py startapp usw. erstellt wurde.
• ViewName
• Eindeutige Namen wie "Liste" für "ListView" und "Detail" für "DetailView"

Es sollte sein. Das heißt, wenn Sie "ListView" mit "myapp" verwenden, wird standardmäßig nach "myapp / myapp_list.html" gesucht.

Wenn Sie dies ändern möchten

views.py

class MyListView(ListView):
    model = MyModel
    template_name = "my_list_view.html"  #Geben Sie die Vorlage in dieser Zeile an

Machen.

Beiseite

Wenn Sie eine generische Ansicht verwenden, möchten Sie in jeder Ansicht dieselbe Variable definieren. Zum Beispiel "Site-Name". Es ist nicht gut, es in allen Ansichten zu definieren, daher frage ich mich, ob ich eine gemeinsame Klasse erstellen und sie erben soll.

base_view.py

from django.views.generic import ListView

from myapp.models import MyModel


#Erben Sie nicht Mixin usw., sondern das Objekt.
class MyCommonView(object):

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context["SITE_NAME"] = "SITE-NAME"
        return context


class MyListView(ListView, MyCommonView):
    model = MyModel

Wenn Sie den Site-Namen ändern möchten, müssen Sie ihn nur an einer Stelle ändern ...? Das wäre eine Möglichkeit, aber ich denke, es ist besser, den Kontextprozessor gehorsam zu verwenden.

Nachwort

Ich bin müde.

Ich hoffe, es wird denen helfen, die Django benutzen.

Vorerst

• Django 1.9
• python 3.5.1

Ich habe die Operation mit bestätigt, aber bitte sagen Sie mir, wenn etwas nicht stimmt.