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