Here again is a recurring theme of this book: at its worst, Web development is boring and monotonous. So far, we’ve covered how Django tries to take away some of that monotony at the model and template layers, but Web developers also experience this boredom at the view level.
Django’s generic views were developed to ease that pain.
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 write too much code. We can recognize certain common tasks, like displaying a list of objects, and write code that displays a list of any object.
Then the model in question can be passed as an extra argument to the URLconf. Django ships with generic display views to do the following:
- Display list and detail pages for a single object. If we were creating an application to manage conferences, then a TalkListView and a RegisteredUserListView would be examples of list views. A single talk page is an example of what we call a “detail” view.
- Present date-based objects in year/month/day archive pages, associated detail, and “latest” pages.
- Allow users to create, update, and delete objects – with or without authorization.
- Taken together, these views provide easy interfaces to perform the most common tasks developers encounter when displaying database data in views. Finally, display views are only one part of Django’s comprehensive class-based view system.
