在上一篇Django处理http请求流程剖析中，笔者详细地说明了Django框架是如何根据WSGI协议处理一个Http请求的。其中，处理开发者自行定义的View的代码如下：
# django.core.handlers.base.py
# 路由解析
resolver_match = resolver.resolve(request.path_info)
callback, callback_args, callback_kwargs = resolver_match
request.resolver_match = resolver_match
# 执行view函数
if response is None:
wrapped_callback = self.make_view_atomic(callback)
try:
response = wrapped_callback(request, *callback_args, **callback_kwargs)
except Exception as e:
response = self.process_exception_by_middleware(e, request)如果开发者使用的是函数视图（FBV），这段代码非常好理解，wrapped_back就是该函数视图，直接调用即可。
但是如果是类视图呢，Django是如何将类视图转化为一个函数呢？
CBV.as_view()
在Django的路由中为url指定view的时候，如果为类视图（所有类视图都需要继承于基类View），则需要使用as_view方法将类视图转化为一个函数，接下来笔者就分析一下as_view方法的源码。
class View(object):
"""
Intentionally simple parent class for all views. Only implements
dispatch-by-method and simple sanity checking.
"""
http_method_names = ['get', 'post', 'put', 'patch', 'delete', 'head', 'options', 'trace']
def __init__(self, **kwargs):
"""
Constructor. Called in the URLconf; can contain helpful extra
keyword arguments, and other things.
"""
# Go through keyword arguments, and either save their values to our
# instance, or raise an error.
for key, value in six.iteritems(kwargs):
setattr(self, key, value)
# as_view方法经过类方法装饰器，是一个类方法
@classonlymethod
def as_view(cls, **initkwargs):
"""
Main entry point for a request-response process.
"""
for key in initkwargs:
if key in cls.http_method_names:
raise TypeError("You tried to pass in the %s method name as a "
"keyword argument to %s(). Don't do that."
% (key, cls.__name__))
if not hasattr(cls, key):
raise TypeError("%s() received an invalid keyword %r. as_view "
"only accepts arguments that are already "
"attributes of the class." % (cls.__name__, key))
def view(request, *args, **kwargs):
self = cls(**initkwargs)
if hasattr(self, 'get') and not hasattr(self, 'head'):
self.head = self.get
self.request = request
self.args = args
self.kwargs = kwargs
return self.dispatch(request, *args, **kwargs)
view.view_class = cls
view.view_initkwargs = initkwargs
# take name and docstring from class
update_wrapper(view, cls, updated=())
# and possible attributes set by decorators
# like csrf_exempt from dispatch
update_wrapper(view, cls.dispatch, assigned=())
return view
def dispatch(self, request, *args, **kwargs):
# Try to dispatch to the right method; if a method doesn't exist,
# defer to the error handler. Also defer to the error handler if the
# request method isn't on the approved list.
if request.method.lower() in self.http_method_names:
handler = getattr(self, request.method.lower(), self.http_method_not_allowed)
else:
handler = self.http_method_not_allowed
return handler(request, *args, **kwargs)
def http_method_not_allowed(self, request, *args, **kwargs):
logger.warning(
'Method Not Allowed (%s): %s', request.method, request.path,
extra={'status_code': 405, 'request': request}
)
return http.HttpResponseNotAllowed(self._allowed_methods())其实as_view方法在方法中定义了一个view函数，这个函数接受的参数跟FBV接受的参数一样，但是这个函数并不负责根据http的method分配到具体的CBV的method上，而是将这项工作交给了dispatch方法去完成。最后as_view方法返回了这个view函数。
在dispatch方法中，寻找了开发者自行定义的诸如get，post等方法对应的业务逻辑并返回执行结果，如果开发者没有定义该方法，则返回405表示该方法不允许。
Mixin
在FBV中，如果希望为视图的访问加上限制的话可以直接使用装饰器，但在CBV中就不能直接使用装饰器了。
比如说django auth提供的默认的login_required装饰器和permission_required装饰器，在CBV中则为LoginRequiredMixin以及PermissionRequiredMixin。
这两个Mixin都继承于AccessMixin（导致了它们引起的异常跳转指向同一个url），下面看一下它们的源码分析。
class LoginRequiredMixin(AccessMixin):
"""
CBV mixin which verifies that the current user is authenticated.
"""
def dispatch(self, request, *args, **kwargs):
if not request.user.is_authenticated:
# 该方法继承于AccessMixin
return self.handle_no_permission()
return super(LoginRequiredMixin, self).dispatch(request, *args, **kwargs)
class PermissionRequiredMixin(AccessMixin):
"""
CBV mixin which verifies that the current user has all specified
permissions.
"""
permission_required = None
def get_permission_required(self):
"""
Override this method to override the permission_required attribute.
Must return an iterable.
"""
if self.permission_required is None:
raise ImproperlyConfigured(
'{0} is missing the permission_required attribute. Define {0}.permission_required, or override '
'{0}.get_permission_required().'.format(self.__class__.__name__)
)
if isinstance(self.permission_required, six.string_types):
perms = (self.permission_required, )
else:
perms = self.permission_required
return perms
def has_permission(self):
"""
Override this method to customize the way permissions are checked.
"""
perms = self.get_permission_required()
return self.request.user.has_perms(perms)
def dispatch(self, request, *args, **kwargs):
if not self.has_permission():
# 该方法继承于AccessMixin
return self.handle_no_permission()
return super(PermissionRequiredMixin, self).dispatch(request, *args, **kwargs)各位同学可以看到，这两个Mixin都实现了dispatch方法，并且在执行完以后调用的是按照MRO数组中的下一个类的dispatch方法。（MRO是Python多重继承时采用的方法，不了解的同学可以先参考这篇文章：你真的理解Python中MRO算法吗？）
举个简单的例子，假设笔者自定义了一个CBV：
class MyView(LoginRequiredMixin, PermissionRequiredMixin, View)那么，dispatch按照依次调用的顺序则是，LoginRequiredMixin，PermissionRequiredMixn，AccessMixin（没有disptach方法），View。因此，基类View一定要放在多重继承的最后面，因为它的dispatch方法调用就是代表业务逻辑的handler了。
当LoginRequiredMixin或者PermissionRequiredMixin调用继承自AccessMixin的handle_no_permission方法时，如果raise_exception被设置为True，会抛出一个PermissionDenied的异常，否则跳转到login_url。
class AccessMixin(object):
"""
Abstract CBV mixin that gives access mixins the same customizable
functionality.
"""
login_url = None
permission_denied_message = ''
raise_exception = False
redirect_field_name = REDIRECT_FIELD_NAME
def get_login_url(self):
"""
Override this method to override the login_url attribute.
"""
login_url = self.login_url or settings.LOGIN_URL
if not login_url:
raise ImproperlyConfigured(
'{0} is missing the login_url attribute. Define {0}.login_url, settings.LOGIN_URL, or override '
'{0}.get_login_url().'.format(self.__class__.__name__)
)
return force_text(login_url)
def get_permission_denied_message(self):
"""
Override this method to override the permission_denied_message attribute.
"""
return self.permission_denied_message
def get_redirect_field_name(self):
"""
Override this method to override the redirect_field_name attribute.
"""
return self.redirect_field_name
def handle_no_permission(self):
if self.raise_exception:
raise PermissionDenied(self.get_permission_denied_message())
return redirect_to_login(self.request.get_full_path(), self.get_login_url(), self.get_redirect_field_name())这一个异常首先被执行view函数的代码捕捉到，也就是本文中的第一个代码段，然后调用self.process_exception_by_middleware。
def process_exception_by_middleware(self, exception, request):
"""
Pass the exception to the exception middleware. If no middleware
return a response for this exception, raise it.
"""
for middleware_method in self._exception_middleware:
response = middleware_method(request, exception)
if response:
return response
raise由于没有定义任何关于异常的钩子，所以程序直接执行到最后一行raise一个异常，那么这一个异常又是被谁捕捉到呢？
还记得笔者再上一篇博客中(Django处理http请求流程剖析)提及的convert_exception_to_response装饰了self._get_legacy_response这一件事情么，这一个异常就是被convert函数捕捉到了。
def convert_exception_to_response(get_response):
"""
Wrap the given get_response callable in exception-to-response conversion.
All exceptions will be converted. All known 4xx exceptions (Http404,
PermissionDenied, MultiPartParserError, SuspiciousOperation) will be
converted to the appropriate response, and all other exceptions will be
converted to 500 responses.
This decorator is automatically applied to all middleware to ensure that
no middleware leaks an exception and that the next middleware in the stack
can rely on getting a response instead of an exception.
"""
@wraps(get_response, assigned=available_attrs(get_response))
def inner(request):
try:
response = get_response(request)
except Exception as exc:
response = response_for_exception(request, exc)
return response
return inner
def response_for_exception(request, exc):
if isinstance(exc, Http404):
if settings.DEBUG:
response = debug.technical_404_response(request, exc)
else:
response = get_exception_response(request, get_resolver(get_urlconf()), 404, exc)
elif isinstance(exc, PermissionDenied):
logger.warning(
'Forbidden (Permission denied): %s', request.path,
extra={'status_code': 403, 'request': request},
)
response = get_exception_response(request, get_resolver(get_urlconf()), 403, exc)
elif isinstance(exc, MultiPartParserError):
logger.warning(
'Bad request (Unable to parse request body): %s', request.path,
extra={'status_code': 400, 'request': request},
)
response = get_exception_response(request, get_resolver(get_urlconf()), 400, exc)
elif isinstance(exc, SuspiciousOperation):
# The request logger receives events for any problematic request
# The security logger receives events for all SuspiciousOperations
security_logger = logging.getLogger('django.security.%s' % exc.__class__.__name__)
security_logger.error(
force_text(exc),
extra={'status_code': 400, 'request': request},
)
if settings.DEBUG:
response = debug.technical_500_response(request, *sys.exc_info(), status_code=400)
else:
response = get_exception_response(request, get_resolver(get_urlconf()), 400, exc)
elif isinstance(exc, SystemExit):
# Allow sys.exit() to actually exit. See tickets #1023 and #4701
raise
else:
signals.got_request_exception.send(sender=None, request=request)
response = handle_uncaught_exception(request, get_resolver(get_urlconf()), sys.exc_info())
return response比如PermissionDenied异常对应的状态码就是403，如果在urls中定义了对应状态码的view函数，则调用该函数。
比如：
# urls.py
handler403 = 'path/to/handler_view'最后一种情况是，如果希望LoginRequiredMixin和PermissionRequiredMixin跳转到不同的login_url该怎么办？可以考虑在继承的时候先使用LoginRequiredMixin，然后在具体的http方法上加上method_decorator。