Form processing generally has 3 paths:
\nInitial GET (blank or prepopulated form)
POST with invalid data (typically redisplay form with errors)
POST with valid data (process the data and typically redirect)
Implementing this yourself often results in a lot of repeated boilerplate code\n(see Using a form in a view). To help avoid\nthis, Django provides a collection of generic class-based views for form\nprocessing.
\nGiven a contact form:
\nforms.pyfrom django import forms\n\n\nclass ContactForm(forms.Form):\n name = forms.CharField()\n message = forms.CharField(widget=forms.Textarea)\n\n def send_email(self):\n # send email using the self.cleaned_data dictionary\n pass\nThe view can be constructed using a FormView:
views.pyfrom myapp.forms import ContactForm\nfrom django.views.generic.edit import FormView\n\n\nclass ContactFormView(FormView):\n template_name = "contact.html"\n form_class = ContactForm\n success_url = "/thanks/"\n\n def form_valid(self, form):\n # This method is called when valid form data has been POSTed.\n # It should return an HttpResponse.\n form.send_email()\n return super().form_valid(form)\nNotatki:
\nFormView inherits\nTemplateResponseMixin so\ntemplate_name\ncan be used here.
The default implementation for\nform_valid() simply\nredirects to the success_url.
Generic views really shine when working with models. These generic\nviews will automatically create a ModelForm, so long as\nthey can work out which model class to use:
If the model attribute is\ngiven, that model class will be used.
If get_object()\nreturns an object, the class of that object will be used.
If a queryset is\ngiven, the model for that queryset will be used.
Model form views provide a\nform_valid() implementation\nthat saves the model automatically. You can override this if you have any\nspecial requirements; see below for examples.
You don’t even need to provide a success_url for\nCreateView or\nUpdateView - they will use\nget_absolute_url() on the model object if available.
If you want to use a custom ModelForm (for instance to\nadd extra validation), set\nform_class on your view.
First we need to add get_absolute_url() to our\nAuthor class:
models.pyfrom django.db import models\nfrom django.urls import reverse\n\n\nclass Author(models.Model):\n name = models.CharField(max_length=200)\n\n def get_absolute_url(self):\n return reverse("author-detail", kwargs={"pk": self.pk})\nThen we can use CreateView and friends to do the actual\nwork. Notice how we’re just configuring the generic class-based views\nhere; we don’t have to write any logic ourselves:
views.pyfrom django.urls import reverse_lazy\nfrom django.views.generic.edit import CreateView, DeleteView, UpdateView\nfrom myapp.models import Author\n\n\nclass AuthorCreateView(CreateView):\n model = Author\n fields = ["name"]\n\n\nclass AuthorUpdateView(UpdateView):\n model = Author\n fields = ["name"]\n\n\nclass AuthorDeleteView(DeleteView):\n model = Author\n success_url = reverse_lazy("author-list")\nThe fields attribute works the same way as the fields attribute on the\ninner Meta class on ModelForm. Unless you define the\nform class in another way, the attribute is required and the view will raise\nan ImproperlyConfigured exception if it’s not.
If you specify both the fields\nand form_class attributes, an\nImproperlyConfigured exception will be raised.
Finally, we hook these new views into the URLconf:
\nurls.pyfrom django.urls import path\nfrom myapp.views import AuthorCreateView, AuthorDeleteView, AuthorUpdateView\n\nurlpatterns = [\n # ...\n path("author/add/", AuthorCreateView.as_view(), name="author-add"),\n path("author/<int:pk>/", AuthorUpdateView.as_view(), name="author-update"),\n path("author/<int:pk>/delete/", AuthorDeleteView.as_view(), name="author-delete"),\n]\nrequest.userLink to this heading#To track the user that created an object using a CreateView,\nyou can use a custom ModelForm to do this. First, add\nthe foreign key relation to the model:
models.pyfrom django.contrib.auth.models import User\nfrom django.db import models\n\n\nclass Author(models.Model):\n name = models.CharField(max_length=200)\n created_by = models.ForeignKey(User, on_delete=models.CASCADE)\n\n # ...\nIn the view, ensure that you don’t include created_by in the list of fields\nto edit, and override\nform_valid() to add the user:
views.pyfrom django.contrib.auth.mixins import LoginRequiredMixin\nfrom django.views.generic.edit import CreateView\nfrom myapp.models import Author\n\n\nclass AuthorCreateView(LoginRequiredMixin, CreateView):\n model = Author\n fields = ["name"]\n\n def form_valid(self, form):\n form.instance.created_by = self.request.user\n return super().form_valid(form)\nLoginRequiredMixin prevents users who\naren’t logged in from accessing the form. If you omit that, you’ll need to\nhandle unauthorized users in form_valid().
Here is an example showing how you might go about implementing a form that\nworks with an API-based workflow as well as «normal» form POSTs:
\nfrom django.http import JsonResponse\nfrom django.views.generic.edit import CreateView\nfrom myapp.models import Author\n\n\nclass JsonableResponseMixin:\n """\n Mixin to add JSON support to a form.\n Must be used with an object-based FormView (e.g. CreateView)\n """\n\n def form_invalid(self, form):\n response = super().form_invalid(form)\n if self.request.accepts("text/html"):\n return response\n else:\n return JsonResponse(form.errors, status=400)\n\n def form_valid(self, form):\n # We make sure to call the parent's form_valid() method because\n # it might do some processing (in the case of CreateView, it will\n # call form.save() for example).\n response = super().form_valid(form)\n if self.request.accepts("text/html"):\n return response\n else:\n data = {\n "pk": self.object.pk,\n }\n return JsonResponse(data)\n\n\nclass AuthorCreateView(JsonableResponseMixin, CreateView):\n model = Author\n fields = ["name"]\n