Django’s form widgets are rendered using Django’s template engines\nsystem.
\nThe form rendering process can be customized at several levels:
\nWidgets can specify custom template names.
Forms and widgets can specify custom renderer classes.
A widget’s template can be overridden by a project. (Reusable applications\ntypically shouldn’t override built-in templates because they might conflict\nwith a project’s custom templates.)
The rendering of form templates is controlled by a customizable renderer class.\nA custom renderer can be specified by updating the FORM_RENDERER\nsetting. It defaults to\n'django.forms.renderers.DjangoTemplates'.
By specifying a custom form renderer and overriding\nform_template_name you can adjust the default form\nmarkup across your project from a single place.
You can also provide a custom renderer per-form or per-widget by setting the\nForm.default_renderer attribute or by using the renderer argument\nof Form.render(), or Widget.render().
Matching points apply to formset rendering. See Using a formset in views and templates for\ndiscussion.
\nUse one of the built-in template form renderers or implement your own. Custom renderers\nmust implement a render(template_name, context, request=None) method. It\nshould return a rendered template (as a string) or raise\nTemplateDoesNotExist.
The base class for the built-in form renderers.
\nThe default name of the template to use to render a form.
\nDefaults to "django/forms/div.html" template.
The default name of the template to use to render a formset.
\nDefaults to "django/forms/formsets/div.html" template.
The default name of the template used to render a BoundField.
Defaults to "django/forms/field.html"
The default class used to represent form fields across the project.
\nDefaults to BoundField class.
This can be customized further using Form.bound_field_class\nfor per-form overrides, or Field.bound_field_class for\nper-field overrides.
Subclasses must implement this method with the appropriate template\nfinding logic.
\nRenders the given template, or raises\nTemplateDoesNotExist.
DjangoTemplatesLink to this heading#This renderer uses a standalone\nDjangoTemplates\nengine (unconnected to what you might have configured in the\nTEMPLATES setting). It loads templates first from the built-in form\ntemplates directory in django/forms/templates and then from the\ninstalled apps’ templates directories using the app_directories loader.
If you want to render templates with customizations from your\nTEMPLATES setting, such as context processors for example, use the\nTemplatesSetting renderer.
Jinja2Link to this heading#This renderer is the same as the DjangoTemplates renderer except that\nit uses a Jinja2 backend. Templates\nfor the built-in widgets are located in django/forms/jinja2 and\ninstalled apps can provide templates in a jinja2 directory.
To use this backend, all the forms and widgets in your project and its\nthird-party apps must have Jinja2 templates. Unless you provide your own Jinja2\ntemplates for widgets that don’t have any, you can’t use this renderer. For\nexample, django.contrib.admin doesn’t include Jinja2 templates for its\nwidgets due to their usage of Django template tags.
TemplatesSettingLink to this heading#This renderer gives you complete control of how form and widget templates are\nsourced. It uses get_template() to find templates\nbased on what’s configured in the TEMPLATES setting.
Using this renderer along with the built-in templates requires either:
\n'django.forms' in INSTALLED_APPS and at least one engine\nwith APP_DIRS=True.
Adding the built-in templates directory in DIRS\nof one of your template engines. To generate that path:
import django\n\ndjango.__path__[0] + "/forms/templates" # or '/forms/jinja2'\nUsing this renderer requires you to make sure the form templates your project\nneeds can be located.
\nFormset templates receive a context from BaseFormSet.get_context(). By\ndefault, formsets receive a dictionary with the following values:
formset: The formset instance.
Form templates receive a context from Form.get_context(). By default,\nforms receive a dictionary with the following values:
form: The bound form.
fields: All bound fields, except the hidden fields.
hidden_fields: All hidden bound fields.
errors: All non field related or hidden field related form errors.
Field templates receive a context from BoundField.get_context(). By\ndefault, fields receive a dictionary with the following values:
field: The BoundField.
Widget templates receive a context from Widget.get_context(). By\ndefault, widgets receive a single value in the context, widget. This is a\ndictionary that contains values like:
name
value
attrs
is_hidden
template_name
Some widgets add further information to the context. For instance, all widgets\nthat subclass Input defines widget['type'] and MultiWidget\ndefines widget['subwidgets'] for looping purposes.
To override formset templates, you must use the TemplatesSetting\nrenderer. Then overriding formset templates works the same as overriding any other template in your project.
To override form templates, you must use the TemplatesSetting\nrenderer. Then overriding form templates works the same as overriding any other template in your project.
To override field templates, you must use the TemplatesSetting\nrenderer. Then overriding field templates works the same as overriding any other template in your project.
Each widget has a template_name attribute with a value such as\ninput.html. Built-in widget templates are stored in the\ndjango/forms/widgets path. You can provide a custom template for\ninput.html by defining django/forms/widgets/input.html, for example.\nSee Built-in widgets for the name of each widget’s template.
To override widget templates, you must use the TemplatesSetting\nrenderer. Then overriding widget templates works the same as overriding any other template in your project.