{% csrf_token%} est une mesure CSRF. Requis si vous avez créé un formulaire POST, etc. avec Django.

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

Vous pouvez également utiliser des objets de formulaire tels que «ModelForm».

De cette manière, vous pouvez facilement exploiter vos classes de formulaire existantes.

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

La validation est également une caractéristique importante de ces formulaires. Même si vous soumettez le formulaire avec beaucoup d'efforts, si une erreur se produit lors de la validation et qu'il n'est pas ajouté ou mis à jour, cela peut être déroutant si vous n'en informez pas l'utilisateur.

Par conséquent, les méthodes form_valid et form_invalid sont définies dans ces vues générales et vous pouvez effectuer le traitement nécessaire selon que la validation a réussi ou non.

Par exemple, nous disons souvent aux utilisateurs si le formulaire qu'ils ont soumis a été enregistré avec succès. A cette époque, Django utilise le framework de messages.

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

views.py

from django.views.generic.edit import CreateView
from django.contrib import messages  #Cadre de message

from myapp.models import MyModel


class MyCreateView(CreateView):
    model = MyModel

    def form_valid(self, form):
        '''Une fois la validation réussie'''
        messages.success(self.request, "Enregistré")
        return super().form_valid(form)

    def form_invalid(self, form):
        '''Lorsque la validation échoue'''
        message.warning(self.request, "Impossible d'enregistrer")
        return super().form_invalid(form)

Ici, nous avons ajouté nos propres messages à la méthode form_valid, qui est appelée lorsque la validation est réussie, et à form_invalid, qui est appelée lorsque la validation échoue.

En faisant cela, vous pouvez ajouter votre propre traitement, donc en plus de l'exemple ci-dessus, vous pouvez insérer un traitement tel que notifier l'administrateur par e-mail lorsqu'une erreur se produit.

Lorsque vous avez terminé votre propre traitement, appelez la méthode d'héritage et renvoyez la valeur de retour.

À propos, pour afficher le message, procédez comme suit. Le contenu du document est tel qu'il est.

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

DeleteView

Comme son nom l'indique, «DeleteView» supprime un enregistrement. Le modèle est (AppName) / (AppName) _confirm_delete.html.

views.py

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


class MyDeleteView(DeleteView):
    model = MyModel

Le modèle dans ce cas sera un formulaire de confirmation demandant "Êtes-vous sûr de vouloir le supprimer?"

Il y a peut-être des moments où vous souhaitez simplement activer l'indicateur de suppression au lieu de le supprimer vraiment. Dans un tel cas, il est préférable de remplacer la méthode delete. Cependant, je ne l'ai pas essayé parce que je le supprime docilement.

Articles communs

En plus du traitement mentionné ci-dessus, la vue à usage général basée sur les classes peut remplacer librement le nom du fichier modèle et le nom de la variable. De plus, la méthode est également courante, je vais donc en présenter quelques-unes. Je pense qu'il est généralement préférable d'utiliser la valeur par défaut et de la remplacer uniquement lorsque cela est nécessaire.

Variable par défaut

Comme vous l'avez peut-être déjà remarqué, les vues génériques ont une certaine régularité. Remplacer get_context_data, effectuer le traitement nécessaire et le définir dans une variable a été introduit dans la première étape. Si vous souhaitez transmettre des données à un modèle, cela devrait suffire.

Donc, au contraire, lorsqu'une vue polyvalente récupère automatiquement des données, quel type de données est défini dans quelle variable?

La vue générique basée sur les classes récupère automatiquement les données de la base de données en fonction de leur utilisation prévue (classe héritée). Définissez à partir de quelle table les données sont récupérées comme model = MyModel.

views.py

class MyListView(ListView):
    model = MyModel  #Obtenez automatiquement une liste de MyModels

En faisant cela, vous obtiendrez les données de MyModel. Le résultat, etc. doit être défini dans une variable avec un nom fixe. ʻObject s'il n'y a qu'un seul enregistrement tel qu'une page individuelle. S'il y en a plus d'un, ʻobject_list.

Le modèle ressemblerait à ceci:

Pages individuelles etc.

{{ object }}

S'il y en a plus d'un

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

Cependant, je ne peux pas dire ce que cela signifie en regardant le modèle. Vous souhaiterez peut-être rendre le nom de la variable plus descriptif. Dans ce cas, attribuez le nom de la variable à context_object_name.

views.py

class MyBookList(ListView):
    model = Books
    context_object_name = "my_books"  #Spécifiez le nom de la variable sur cette ligne

De cette façon, dans le modèle

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

Vous pouvez l'appeler comme ça. Maintenant que vous savez à quoi fait référence le nom de la variable, il est facile de voir à quoi la variable fait référence simplement en lisant le modèle.

Spécification du fichier à utiliser comme modèle

les vues sont des contrôleurs. Par conséquent, transmettez les données au modèle approprié. Le modèle peut être spécifié explicitement, mais il a un nom de modèle par défaut. C'est,

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

C'est.

Elles sont,

• AppName
• Le nom de l'application créée par manage.py startapp etc.
• ViewName
• Noms uniques tels que list pour ListView et detail pour DetailView

C'est supposé être. Autrement dit, l'utilisation de «ListView» avec «myapp» cherchera par défaut «myapp / myapp_list.html».

Si vous souhaitez changer cela

views.py

class MyListView(ListView):
    model = MyModel
    template_name = "my_list_view.html"  #Spécifiez le modèle sur cette ligne

Faire.

De côté

Si vous utilisez une vue générique, vous souhaiterez définir la même variable dans chaque vue. Par exemple, "nom du site". Ce n'est pas bon de le définir dans toutes les vues, donc je me demande si je devrais créer une classe commune et en hériter.

base_view.py

from django.views.generic import ListView

from myapp.models import MyModel


#N'héritez pas de Mixin etc., mais héritez d'un objet.
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

Maintenant, si vous souhaitez changer le nom du site, vous n'avez qu'à le changer à un seul endroit ...? Ce serait une solution, mais je pense qu'il vaut mieux utiliser le processeur de contexte avec obéissance.

Épilogue

Je suis fatigué.

J'espère que cela aidera ceux qui utilisent Django.

Pour le moment

• Django 1.9
• python 3.5.1

J'ai confirmé l'opération avec, mais veuillez me dire s'il y a quelque chose qui ne va pas.