PageRenderTime 434ms CodeModel.GetById 181ms app.highlight 2ms RepoModel.GetById 250ms app.codeStats 0ms

/docs/topics/generic-views-migration.txt

https://code.google.com/p/mango-py/
Plain Text | 159 lines | 125 code | 34 blank | 0 comment | 0 complexity | 4582263bd32bd5174bc51787605e03a1 MD5 | raw file
  1======================================
  2Migrating function-based generic views
  3======================================
  4
  5All the :doc:`function-based generic views</ref/generic-views>`
  6that existed in Django 1.2 have analogs as :doc:`class-based generic
  7views</ref/class-based-views>` in Django 1.3. The feature set
  8exposed in those function-based views can be replicated in a
  9class-based way.
 10
 11How to migrate
 12==============
 13
 14Replace generic views with generic classes
 15------------------------------------------
 16
 17Existing usage of function-based generic views should be replaced with
 18their class-based analogs:
 19
 20    ====================================================  ====================================================
 21    Old function-based generic view                       New class-based generic view
 22    ====================================================  ====================================================
 23    ``django.views.generic.simple.direct_to_template``    :class:`django.views.generic.base.TemplateView`
 24    ``django.views.generic.simple.redirect_to``           :class:`django.views.generic.base.RedirectView`
 25    ``django.views.generic.list_detail.object_list``      :class:`django.views.generic.list.ListView`
 26    ``django.views.generic.list_detail.object_detail``    :class:`django.views.generic.detail.DetailView`
 27    ``django.views.generic.create_update.create_object``  :class:`django.views.generic.edit.CreateView`
 28    ``django.views.generic.create_update.update_object``  :class:`django.views.generic.edit.UpdateView`
 29    ``django.views.generic.create_update.delete_object``  :class:`django.views.generic.edit.DeleteView`
 30    ``django.views.generic.date_based.archive_index``     :class:`django.views.generic.dates.ArchiveIndexView`
 31    ``django.views.generic.date_based.archive_year``      :class:`django.views.generic.dates.YearArchiveView`
 32    ``django.views.generic.date_based.archive_month``     :class:`django.views.generic.dates.MonthArchiveView`
 33    ``django.views.generic.date_based.archive_week``      :class:`django.views.generic.dates.WeekArchiveView`
 34    ``django.views.generic.date_based.archive_day``       :class:`django.views.generic.dates.DayArchiveView`
 35    ``django.views.generic.date_based.archive_today``     :class:`django.views.generic.dates.TodayArchiveView`
 36    ``django.views.generic.date_based.object_detail``     :class:`django.views.generic.dates.DateDetailView`
 37    ====================================================  ====================================================
 38
 39To do this, replace the reference to the generic view function with
 40a ``as_view()`` instantiation of the class-based view. For example,
 41the old-style ``direct_to_template`` pattern::
 42
 43    ('^about/$', direct_to_template, {'template': 'about.html'})
 44
 45can be replaced with an instance of
 46:class:`~django.views.generic.base.TemplateView`::
 47
 48    ('^about/$', TemplateView.as_view(template_name='about.html'))
 49
 50``template`` argument to ``direct_to_template`` views
 51-----------------------------------------------------
 52
 53The ``template`` argument to the ``direct_to_template`` view has been renamed
 54``template_name``. This has been done to maintain consistency with other views.
 55
 56``object_id`` argument to detail views
 57--------------------------------------
 58
 59The object_id argument to the ``object_detail`` view has been renamed
 60``pk`` on the :class:`~django.views.generic.detail.DetailView`.
 61
 62``template_object_name``
 63------------------------
 64
 65``template_object_name`` has been renamed ``context_object_name``,
 66reflecting the fact that the context data can be used for purposes
 67other than template rendering (e.g., to populate JSON output).
 68
 69The ``_list`` suffix on list views
 70----------------------------------
 71
 72In a function-based :class:`ListView`, the ``template_object_name``
 73was appended with the suffix ``'_list'`` to yield the final context
 74variable name. In a class-based ``ListView``, the
 75``context_object_name`` is used verbatim. The ``'_list'`` suffix
 76is only applied when generating a default context object name.
 77
 78The context data for ``object_list`` views
 79------------------------------------------
 80
 81The context provided by :class:`~django.views.generic.list.MultipleObjectMixin`
 82is quite different from that provided by ``object_list``, with most pagination
 83related variables replaced by a single ``page_obj`` object. The following are no
 84longer provided:
 85
 86* ``first_on_page``
 87* ``has_next``
 88* ``has_previous``
 89* ``hits``
 90* ``last_on_page``
 91* ``next``
 92* ``page_range``
 93* ``page``
 94* ``pages``
 95* ``previous``
 96* ``results_per_page``
 97
 98``extra_context``
 99-----------------
100
101Function-based generic views provided an ``extra_context`` argument
102as way to insert extra items into the context at time of rendering.
103
104Class-based views don't provide an ``extra_context`` argument.
105Instead, you subclass the view, overriding :meth:`get_context_data()`.
106For example::
107
108    class MyListView(ListView):
109        def get_context_data(self, **kwargs):
110            context = super(MyListView, self).get_context_data(**kwargs)
111            context.update({
112                'foo': 42,
113                'bar': 37
114            })
115            return context
116
117``post_save_redirect`` argument to create and update views
118----------------------------------------------------------
119
120The ``post_save_redirect`` argument to the create and update views
121has been renamed ``success_url`` on the
122:class:`~django.views.generic.edit.ModelFormMixin`.
123
124``mimetype``
125------------
126
127Some function-based generic views provided a ``mimetype`` argument
128as way to control the mimetype of the response.
129
130Class-based views don't provide a ``mimetype`` argument. Instead, you
131subclass the view, overriding
132:meth:`TemplateResponseMixin.render_to_response()` and pass in arguments for
133the TemplateResponse constructor. For example::
134
135    class MyListView(ListView):
136        def render_to_response(self, context, **kwargs):
137            return super(MyListView, self).render_to_response(context,
138                            content_type='application/json', **kwargs)
139
140``context_processors``
141----------------------
142
143Some function-based generic views provided a ``context_processors``
144argument that could be used to force the use of specialized context
145processors when rendering template content.
146
147Class-based views don't provide a ``context_processors`` argument.
148Instead, you subclass the view, overriding
149:meth:`TemplateResponseMixin.render_to_response()`, and passing in
150a context instance that has been instantiated with the processors
151you want to use. For example::
152
153    class MyListView(ListView):
154        def render_to_response(self, context, **kwargs):
155            return super(MyListView, self).render_to_response(
156                    RequestContext(self.request,
157                                   context,
158                                   processors=[custom_processor]),
159                    **kwargs)