Another common idiom of any data-driven web application is the detail view. Django provides a generic detail view that we can use to display our context data.
The detail view will render a detail view of an object, normally a database object containing the data and keyword arguments passed to the request object.
By default, the DetailView is a model instance generated from the
self.queryset method. However, the view will also support displaying any object by simply overriding the
Method Resolution Order (MRO)
content_type = None as defined in TemplateResponseMixin
context_object_name = None as defined in SingleObjectMixin
http_method_names = [u'get', u'post, u'put, u'patch', u'delete', u'head', u'options, u'trace'] as defined in View
model = None as defined in SingleObjectMixin
pk_url_kwarg = pk as defined in SingleObjectMixin
query_pk_and_slug = False as defined in SingleObjectMixin
queryset = None as defiend in __SingleObjectMixin
slug_field = 'slug' as defined in SingleObjectMixin
slug_url_kwarg = 'slig' as defined in SingleObjectMixin
template_engine = None as defined in TemplateResponseMixin
template_name = None as defined in TemplateResponseMixin
template_name_field = None as defined in SingleObjectTemplateResponseMixin
template_name_suffix = '_detail' as defined in SingleObjectTemplateResponseMixin
Django's default generic views are a simple and effective way to organize and group your view code. It is quite easy to separate and manage your customer business rules away from the abstraction of the generic view. Let Django handle all of the interactions with the database and concentrate on managing the state of the model instance. This allows you to focus on the features of the application and not get hung up on programming the database CRUD operations. This saves hundreds of hours of programming time.
Give Django's Generic Views a try....