Почему этот подход был принят в этом классе?

Question

В базовом классе внутри общих представлений django создает метод 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', '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 kwargs.iteritems():
            setattr(self, key, value)

    @classonlymethod
    def as_view(cls, **initkwargs):
        """
        Main entry point for a request-response process.
        """
        # sanitize keyword arguments
        for key in initkwargs:
            if key in cls.http_method_names:
                raise TypeError(u"You tried to pass in the %s method name as a "
                                u"keyword argument to %s(). Don't do that."
                                % (key, cls.__name__))
            if not hasattr(cls, key):
                raise TypeError(u"%s() received an invalid keyword %r" % (
                    cls.__name__, key))

        def view(request, *args, **kwargs):
            self = cls(**initkwargs)
            return self.dispatch(request, *args, **kwargs)

        # 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
        self.request = request
        self.args = args
        self.kwargs = kwargs
        return handler(request, *args, **kwargs)

    def http_method_not_allowed(self, request, *args, **kwargs):
        allowed_methods = [m for m in self.http_method_names if hasattr(self, m)]
        logger.warning('Method Not Allowed (%s): %s' % (request.method, request.path),
            extra={
                'status_code': 405,
                'request': self.request
            }
        )
        return http.HttpResponseNotAllowed(allowed_methods)

Answer 1

В базовых представлениях на основе классов любой запрос должен иметь собственный экземпляр класса MyView.

Вот наш urls.py:

from foo.views import AboutView
....
(r'^about/', AboutView.as_view()),

urls.py импортируется один раз для потока django. Это означает, что вызов as_view не создает экземпляр AboutView.

Когда запрос обрабатывается urlconf, вызывается метод view(), и только после этого создается экземпляр AboutView, который передает и заполняет его всеми соответствующими данными, необходимыми для этого конкретного запроса.

Использование:

(r'^about/', AboutView().dispatch), #WRONG!!!!

приведет к тому, что все запросы будут использовать один и тот же экземпляр представления, включая возможные свойства, которые не должны использоваться разными запросами.