renderers.txt 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179
  1. ======================
  2. The form rendering API
  3. ======================
  4. .. module:: django.forms.renderers
  5. :synopsis: Built-in form renderers.
  6. Django's form widgets are rendered using Django's :doc:`template engines
  7. system </topics/templates>`.
  8. The form rendering process can be customized at several levels:
  9. * Widgets can specify custom template names.
  10. * Forms and widgets can specify custom renderer classes.
  11. * A widget's template can be overridden by a project. (Reusable applications
  12. typically shouldn't override built-in templates because they might conflict
  13. with a project's custom templates.)
  14. .. _low-level-widget-render-api:
  15. The low-level render API
  16. ========================
  17. The rendering of form templates is controlled by a customizable renderer class.
  18. A custom renderer can be specified by updating the :setting:`FORM_RENDERER`
  19. setting. It defaults to
  20. ``'``:class:`django.forms.renderers.DjangoTemplates`\ ``'``.
  21. You can also provide a custom renderer by setting the
  22. :attr:`.Form.default_renderer` attribute or by using the ``renderer`` argument
  23. of :meth:`.Widget.render`.
  24. Use one of the :ref:`built-in template form renderers
  25. <built-in-template-form-renderers>` or implement your own. Custom renderers
  26. must implement a ``render(template_name, context, request=None)`` method. It
  27. should return a rendered templates (as a string) or raise
  28. :exc:`~django.template.TemplateDoesNotExist`.
  29. .. _built-in-template-form-renderers:
  30. Built-in-template form renderers
  31. ================================
  32. ``DjangoTemplates``
  33. -------------------
  34. .. class:: DjangoTemplates
  35. This renderer uses a standalone
  36. :class:`~django.template.backends.django.DjangoTemplates`
  37. engine (unconnected to what you might have configured in the
  38. :setting:`TEMPLATES` setting). It loads templates first from the built-in form
  39. templates directory in ``django/forms/templates`` and then from the installed
  40. apps' templates directories using the :class:`app_directories
  41. <django.template.loaders.app_directories.Loader>` loader.
  42. If you want to render templates with customizations from your
  43. :setting:`TEMPLATES` setting, such as context processors for example, use the
  44. :class:`TemplatesSetting` renderer.
  45. ``Jinja2``
  46. ----------
  47. .. class:: Jinja2
  48. This renderer is the same as the :class:`DjangoTemplates` renderer except that
  49. it uses a :class:`~django.template.backends.jinja2.Jinja2` backend. Templates
  50. for the built-in widgets are located in ``django/forms/jinja2`` and installed
  51. apps can provide templates in a ``jinja2`` directory.
  52. To use this backend, all the forms and widgets in your project and its
  53. third-party apps must have Jinja2 templates. Unless you provide your own Jinja2
  54. templates for widgets that don't have any, you can't use this renderer. For
  55. example, :mod:`django.contrib.admin` doesn't include Jinja2 templates for its
  56. widgets due to their usage of Django template tags.
  57. ``TemplatesSetting``
  58. --------------------
  59. .. class:: TemplatesSetting
  60. This renderer gives you complete control of how widget templates are sourced.
  61. It uses :func:`~django.template.loader.get_template` to find widget
  62. templates based on what's configured in the :setting:`TEMPLATES` setting.
  63. Using this renderer along with the built-in widget templates requires either:
  64. * ``'django.forms'`` in :setting:`INSTALLED_APPS` and at least one engine
  65. with :setting:`APP_DIRS=True <TEMPLATES-APP_DIRS>`.
  66. * Adding the built-in widgets templates directory in :setting:`DIRS
  67. <TEMPLATES-DIRS>` of one of your template engines. To generate that path::
  68. import django
  69. django.__path__[0] + '/forms/templates' # or '/forms/jinja2'
  70. Using this renderer requires you to make sure the form templates your project
  71. needs can be located.
  72. Context available in formset templates
  73. ======================================
  74. .. versionadded:: 4.0
  75. Formset templates receive a context from :meth:`.BaseFormSet.get_context`. By
  76. default, formsets receive a dictionary with the following values:
  77. * ``formset``: The formset instance.
  78. Context available in form templates
  79. ===================================
  80. .. versionadded:: 4.0
  81. Form templates receive a context from :meth:`.Form.get_context`. By default,
  82. forms receive a dictionary with the following values:
  83. * ``form``: The bound form.
  84. * ``fields``: All bound fields, except the hidden fields.
  85. * ``hidden_fields``: All hidden bound fields.
  86. * ``errors``: All non field related or hidden field related form errors.
  87. Context available in widget templates
  88. =====================================
  89. Widget templates receive a context from :meth:`.Widget.get_context`. By
  90. default, widgets receive a single value in the context, ``widget``. This is a
  91. dictionary that contains values like:
  92. * ``name``
  93. * ``value``
  94. * ``attrs``
  95. * ``is_hidden``
  96. * ``template_name``
  97. Some widgets add further information to the context. For instance, all widgets
  98. that subclass ``Input`` defines ``widget['type']`` and :class:`.MultiWidget`
  99. defines ``widget['subwidgets']`` for looping purposes.
  100. .. _overriding-built-in-formset-templates:
  101. Overriding built-in formset templates
  102. =====================================
  103. .. versionadded:: 4.0
  104. :attr:`.BaseFormSet.template_name`
  105. To override formset templates, you must use the :class:`TemplatesSetting`
  106. renderer. Then overriding widget templates works :doc:`the same as
  107. </howto/overriding-templates>` overriding any other template in your project.
  108. .. _overriding-built-in-form-templates:
  109. Overriding built-in form templates
  110. ==================================
  111. .. versionadded:: 4.0
  112. :attr:`.Form.template_name`
  113. To override form templates, you must use the :class:`TemplatesSetting`
  114. renderer. Then overriding widget templates works :doc:`the same as
  115. </howto/overriding-templates>` overriding any other template in your project.
  116. .. _overriding-built-in-widget-templates:
  117. Overriding built-in widget templates
  118. ====================================
  119. Each widget has a ``template_name`` attribute with a value such as
  120. ``input.html``. Built-in widget templates are stored in the
  121. ``django/forms/widgets`` path. You can provide a custom template for
  122. ``input.html`` by defining ``django/forms/widgets/input.html``, for example.
  123. See :ref:`built-in widgets` for the name of each widget's template.
  124. To override widget templates, you must use the :class:`TemplatesSetting`
  125. renderer. Then overriding widget templates works :doc:`the same as
  126. </howto/overriding-templates>` overriding any other template in your project.