django 类视图解析 -FormView

django 类视图可以帮我们轻松处理特定功能的逻辑,django 基本类视图分为四类:

本文解析编辑类视图的 FormView。后续会继续对其他类视图进行解析。

实现的功能

FormView 是 Django 为表单处理提供的类视图,该类视图解决以下三种路径的表单请求:

  1. 初始GET(空或者预填充表单)
  2. 具有无效数据的POST(通常重新显示带有错误的表单)
  3. 具有有效数据的POST(处理数据并通常重定向)

其中,页面的GET请求将实现初始GET;用户提交请求后,根据用户提交的数据是否通过验证,分别实现具有有效数据的POST和无效数据的POST。

视图如何实现功能的?

FormView通过下图所示逻辑解决上述三中路径的请求。

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请求。

推荐阅读更多精彩内容