django 类视图可以帮我们轻松处理特定功能的逻辑，django 基本类视图分为四类：
-
基础类视图：
-
展示类视图：
-
编辑类视图：
FormViewCreateViewUpdateViewDeleteView
-
日期类视图：
本文解析编辑类视图的 FormView。后续会继续对其他类视图进行解析。
实现的功能
FormView 是 Django 为表单处理提供的类视图，该类视图解决以下三种路径的表单请求：
- 初始GET（空或者预填充表单）
- 具有无效数据的POST（通常重新显示带有错误的表单）
- 具有有效数据的POST（处理数据并通常重定向）
其中，页面的GET请求将实现初始GET；用户提交请求后，根据用户提交的数据是否通过验证，分别实现具有有效数据的POST和无效数据的POST。
视图如何实现功能的？
FormView通过下图所示逻辑解决上述三中路径的请求。
图中：
1 通过dispatch()方法实现；
2 通过get_form() 方法实现；
3 通过form.is_valid() 方法实现；
4 通过form_valid() 方法实现；
6 通过get_form()方法实现，
7 通过render_to_response()方法实现。
它们的组合可以实现FormView的功能：
- 初始GET：通过图中1-5-6-7路径实现；
- 具有无效数据的POST：通过图中1-2-3-5-7路径实现；
- 具有有效数据的POST：通过图中1-2-3-4路径实现。
从图中我们可以看到，2、6都是通过get_form() 方法实现form的实例化，它们的区别在于：
- 2中的form实例化对应的是POST请求，它将生成含有初始数据、POST方法中获取到的数据的表单实例（如果初始数据与POST方法中数据的关键词相同，表单绑定的是POST中的数据）；
- 6中的form实例化对应的是GET请求，它将生成具备初始数据的表单实例；
实现上述流程，FormView需要设置以下两个属性（方法）：
- form_class : 表单类，用于 get_form() 方法，这里使用 ApplicationForm ；该属性也可以通过重写 get_form_class() 方法进行定义；
- success_url：表单验证成功后跳转到的url，用于 form_valid() 方法。该属性也可以通过重写 get_success_url() 方法进行定义。
如果需要设置表单的初始值，可以设置一下属性：
- initial：字典，key为表单字段名，用于get_form()方法，该属性也可以通过重写get_initial() 方法进行定义。
代码是如何实现上述功能的
GET请求
get() 方法来处理 GET请求，FormView内置的get() 方法为：
def get(self, request, *args, **kwargs):
"""
Handles GET requests and instantiates a blank version of the form.
"""
return self.render_to_response(self.get_context_data())
该方法与实现了图1中5-6-7路径，其中，5-6通过self.get_context_data()实现，7通过self.render_to_response()实现。
get_contecxt_data() 方法具体内容为：
def get_context_data(self, **kwargs):
"""
Insert the form into the context dict.
"""
if 'form' not in kwargs:
kwargs['form'] = self.get_form()
return super(FormMixin, self).get_context_data(**kwargs)
如果 get_context_data() 的参数中没有 form ，这里将使用 form_class 设置的表单类创建 form实例作为关键词参数 ‘form’ 的值，django 内部会将所有的关键词参数 传入响应的 context 中，因此，我们可以在 HTML 中通过 {{ form }}来访问表单实例。
POST请求
post() 方法来处理 POST请求，FormView内置的post() 方法为：
def post(self, request, *args, **kwargs):
"""
Handles POST requests, instantiating a form instance with the passed
POST variables and then checked for validity.
"""
form = self.get_form()
if form.is_valid():
return self.form_valid(form)
else:
return self.form_invalid(form)
该方法实现了图中1-2-3-5-7路径和1-2-3-4路径。其中：
2 通过form = self.get_form()实现；
3 通过form.is_valid()实现；
5-7 通过 self.form_invalid(form) 实现；
4 通过self.form_valid(form)实现。
self.form_invalid(form)
处理没有通过验证的表单。它的代码是：
def form_invalid(self, form):
"""
If the form is invalid, re-render the context data with the
data-filled form and errors.
"""
return self.render_to_response(self.get_context_data(form=form))
它与 GET请求中 get() 方法实现的功能类似，唯一的区别在于：它将未通过验证的表单实例 传入self.get_context_data() 方法中，这样 context中的form为验证未通过的表单实例，而不是 get() 中的空的表单实例。
self.form_valid(form)
处理通过验证的表单，它的代码是：
def form_valid(self, form):
"""
If the form is valid, redirect to the supplied URL.
"""
return HttpResponseRedirect(self.get_success_url())
它只实现了一项功能：跳转到成功页面。
这里采用的是HttpResponseRedirect类进行处理，HttpResponseRedirect 实现 HTTP 302。简单来说，它将向定义的跳转成功页面 发起 GET请求。
HTTP 302
RFC1945，也就是HTTP1.0在介绍302时说，如果客户端发出POST请求后，收到服务端的302状态码，那么不能自动的向新的URI发送重复请求，必须跟用户确认是否该重发，因为第二次POST时，环境可能已经发生变化（嗯，POST方法不是幂等的），POST操作会不符合用户预期。但是，很多浏览器（user agent我描述为浏览器以方便介绍）在这种情况下都会把POST请求变为GET请求。
RFC2616，也就是HTTP1.1在介绍302时说，如果客户端发出非GET、HEAD请求后，收到服务端的302状态码，那么就不能自动的向新URI发送重复请求，除非得到用户的确认。但是，很多浏览器都把302当作303处理了（注意，303是HTTP1.1才加进来的，其实从HTTP1.0进化到HTTP1.1，浏览器什么都没动），它们获取到HTTP响应报文头部的Location字段信息，并发起一个GET请求。
