Built-in class-based views API

• 基础视图
  • TemplateView
• Generic display views
  • ListView
• • FormView
  • UpdateView
• 通用日期视图
  • YearArchiveView
  • WeekArchiveView
  • TodayArchiveView
• • Simple mixins
    • TemplateResponseMixin
  • • SingleObjectMixin
  • Multiple object mixins
    • MultipleObjectTemplateResponseMixin
  • • FormMixin
    • ProcessFormView
  • Date-based mixins
    • MonthMixin
    • WeekMixin
• Class-based generic views - flattened index
  • • View
    • RedirectView
  • • DetailView
  • • ListView
  • • FormView
    • UpdateView
  • 基于日期的视图
    • YearArchiveView
    • WeekArchiveView
    • TodayArchiveView

Each request served by a class-based view has an independent state; therefore, it is safe to store state variables on the instance (i.e., self.foo = 3 is a thread-safe operation).

A class-based view is deployed into a URL pattern using the classmethod:

Arguments passed to a view are shared between every instance of a view. This means that you shouldn’t use a list, dictionary, or any other mutable object as an argument to a view. If you do and the shared object is modified, the actions of one user visiting your view could have an effect on subsequent users visiting the same view.

Arguments passed into as_view() will be assigned onto the instance that is used to service a request. Using the previous example, this means that every request on MyView is able to use self.size. Arguments must correspond to attributes that already exist on the class (return True on a hasattr check).

Base vs Generic views

Django’s generic views are built off of those base views, and were developed as a shortcut for common usage patterns such as displaying the details of an object. They take certain common idioms and patterns found in view development and abstract them so that you can quickly write common views of data without having to repeat yourself.

Most generic views require the queryset key, which is a QuerySet instance; see 执行查询 for more information about objects.