Widgets¶
A widget is Django’s representation of an HTML input element. The widget handles the rendering of the HTML, and the extraction of data from a GET/POST dictionary that corresponds to the widget.
The HTML generated by the built-in widgets uses HTML5 syntax, targeting
<!DOCTYPE html>
. For example, it uses boolean attributes such as checked
rather than the XHTML style of checked='checked'
.
Tip
Widgets should not be confused with the form fields. Form fields deal with the logic of input validation and are used directly in templates. Widgets deal with rendering of HTML form input elements on the web page and extraction of raw submitted data. However, widgets do need to be assigned to form fields.
Specifying widgets¶
Whenever you specify a field on a form, Django will use a default widget that is appropriate to the type of data that is to be displayed. To find which widget is used on which field, see the documentation about Built-in Field classes.
However, if you want to use a different widget for a field, you can
use the widget
argument on the field definition. For example:
from django import forms
class CommentForm(forms.Form):
name = forms.CharField()
url = forms.URLField()
comment = forms.CharField(widget=forms.Textarea)
This would specify a form with a comment that uses a larger Textarea
widget, rather than the default TextInput
widget.
Setting arguments for widgets¶
Many widgets have optional extra arguments; they can be set when defining the
widget on the field. In the following example, the
years
attribute is set for a
SelectDateWidget
:
from django import forms
BIRTH_YEAR_CHOICES = ['1980', '1981', '1982']
FAVORITE_COLORS_CHOICES = [
('blue', 'Blue'),
('green', 'Green'),
('black', 'Black'),
]
class SimpleForm(forms.Form):
birth_year = forms.DateField(widget=forms.SelectDateWidget(years=BIRTH_YEAR_CHOICES))
favorite_colors = forms.MultipleChoiceField(
required=False,
widget=forms.CheckboxSelectMultiple,
choices=FAVORITE_COLORS_CHOICES,
)
See the Built-in widgets for more information about which widgets are available and which arguments they accept.
Widgets inheriting from the Select
widget¶
Widgets inheriting from the Select
widget deal with choices. They
present the user with a list of options to choose from. The different widgets
present this choice differently; the Select
widget itself uses a
<select>
HTML list representation, while RadioSelect
uses radio
buttons.
Select
widgets are used by default on ChoiceField
fields. The
choices displayed on the widget are inherited from the ChoiceField
and
changing ChoiceField.choices
will update Select.choices
. For
example:
>>> from django import forms
>>> CHOICES = [('1', 'First'), ('2', 'Second')]
>>> choice_field = forms.ChoiceField(widget=forms.RadioSelect, choices=CHOICES)
>>> choice_field.choices
[('1', 'First'), ('2', 'Second')]
>>> choice_field.widget.choices
[('1', 'First'), ('2', 'Second')]
>>> choice_field.widget.choices = []
>>> choice_field.choices = [('1', 'First and only')]
>>> choice_field.widget.choices
[('1', 'First and only')]
Widgets which offer a choices
attribute can however be used
with fields which are not based on choice – such as a CharField
–
but it is recommended to use a ChoiceField
-based field when the
choices are inherent to the model and not just the representational widget.
Customizing widget instances¶
When Django renders a widget as HTML, it only renders very minimal markup -
Django doesn’t add class names, or any other widget-specific attributes. This
means, for example, that all TextInput
widgets will appear the same
on your web pages.
There are two ways to customize widgets: per widget instance and per widget class.
Styling widget instances¶
If you want to make one widget instance look different from another, you will need to specify additional attributes at the time when the widget object is instantiated and assigned to a form field (and perhaps add some rules to your CSS files).
For example, take the following form:
from django import forms
class CommentForm(forms.Form):
name = forms.CharField()
url = forms.URLField()
comment = forms.CharField()
This form will include three default TextInput
widgets, with default
rendering – no CSS class, no extra attributes. This means that the input boxes
provided for each widget will be rendered exactly the same:
>>> f = CommentForm(auto_id=False)
>>> f.as_table()
<tr><th>Name:</th><td><input type="text" name="name" required></td></tr>
<tr><th>Url:</th><td><input type="url" name="url" required></td></tr>
<tr><th>Comment:</th><td><input type="text" name="comment" required></td></tr>
On a real web page, you probably don’t want every widget to look the same. You
might want a larger input element for the comment, and you might want the
‘name’ widget to have some special CSS class. It is also possible to specify
the ‘type’ attribute to take advantage of the new HTML5 input types. To do
this, you use the Widget.attrs
argument when creating the widget:
class CommentForm(forms.Form):
name = forms.CharField(widget=forms.TextInput(attrs={'class': 'special'}))
url = forms.URLField()
comment = forms.CharField(widget=forms.TextInput(attrs={'size': '40'}))
You can also modify a widget in the form definition:
class CommentForm(forms.Form):
name = forms.CharField()
url = forms.URLField()
comment = forms.CharField()
name.widget.attrs.update({'class': 'special'})
comment.widget.attrs.update(size='40')
Or if the field isn’t declared directly on the form (such as model form fields),
you can use the Form.fields
attribute:
class CommentForm(forms.ModelForm):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.fields['name'].widget.attrs.update({'class': 'special'})
self.fields['comment'].widget.attrs.update(size='40')
Django will then include the extra attributes in the rendered output:
>>> f = CommentForm(auto_id=False)
>>> f.as_table()
<tr><th>Name:</th><td><input type="text" name="name" class="special" required></td></tr>
<tr><th>Url:</th><td><input type="url" name="url" required></td></tr>
<tr><th>Comment:</th><td><input type="text" name="comment" size="40" required></td></tr>
You can also set the HTML id
using attrs
. See
BoundField.id_for_label
for an example.
Styling widget classes¶
With widgets, it is possible to add assets (css
and javascript
)
and more deeply customize their appearance and behavior.
In a nutshell, you will need to subclass the widget and either define a “Media” inner class or create a “media” property.
These methods involve somewhat advanced Python programming and are described in detail in the Form Assets topic guide.
Base widget classes¶
Base widget classes Widget
and MultiWidget
are subclassed by
all the built-in widgets and may serve as a
foundation for custom widgets.
Widget
¶
-
class
Widget
(attrs=None)¶ This abstract class cannot be rendered, but provides the basic attribute
attrs
. You may also implement or override therender()
method on custom widgets.-
attrs
¶ A dictionary containing HTML attributes to be set on the rendered widget.
>>> from django import forms >>> name = forms.TextInput(attrs={'size': 10, 'title': 'Your name'}) >>> name.render('name', 'A name') '<input title="Your name" type="text" name="name" value="A name" size="10">'
If you assign a value of
True
orFalse
to an attribute, it will be rendered as an HTML5 boolean attribute:>>> name = forms.TextInput(attrs={'required': True}) >>> name.render('name', 'A name') '<input name="name" type="text" value="A name" required>' >>> >>> name = forms.TextInput(attrs={'required': False}) >>> name.render('name', 'A name') '<input name="name" type="text" value="A name">'
-
supports_microseconds
¶ An attribute that defaults to
True
. If set toFalse
, the microseconds part ofdatetime
andtime
values will be set to0
.
-
format_value
(value)¶ Cleans and returns a value for use in the widget template.
value
isn’t guaranteed to be valid input, therefore subclass implementations should program defensively.
-
get_context
(name, value, attrs)¶ Returns a dictionary of values to use when rendering the widget template. By default, the dictionary contains a single key,
'widget'
, which is a dictionary representation of the widget containing the following keys:'name'
: The name of the field from thename
argument.'is_hidden'
: A boolean indicating whether or not this widget is hidden.'required'
: A boolean indicating whether or not the field for this widget is required.'value'
: The value as returned byformat_value()
.'attrs'
: HTML attributes to be set on the rendered widget. The combination of theattrs
attribute and theattrs
argument.'template_name'
: The value ofself.template_name
.
Widget
subclasses can provide custom context values by overriding this method.
-
id_for_label
(id_)¶ Returns the HTML ID attribute of this widget for use by a
<label>
, given the ID of the field. ReturnsNone
if an ID isn’t available.This hook is necessary because some widgets have multiple HTML elements and, thus, multiple IDs. In that case, this method should return an ID value that corresponds to the first ID in the widget’s tags.
-
render
(name, value, attrs=None, renderer=None)¶ Renders a widget to HTML using the given renderer. If
renderer
isNone
, the renderer from theFORM_RENDERER
setting is used.
-
value_from_datadict
(data, files, name)¶ Given a dictionary of data and this widget’s name, returns the value of this widget.
files
may contain data coming fromrequest.FILES
. ReturnsNone
if a value wasn’t provided. Note also thatvalue_from_datadict
may be called more than once during handling of form data, so if you customize it and add expensive processing, you should implement some caching mechanism yourself.
-
value_omitted_from_data
(data, files, name)¶ Given
data
andfiles
dictionaries and this widget’s name, returns whether or not there’s data or files for the widget.The method’s result affects whether or not a field in a model form falls back to its default.
Special cases are
CheckboxInput
,CheckboxSelectMultiple
, andSelectMultiple
, which always returnFalse
because an unchecked checkbox and unselected<select multiple>
don’t appear in the data of an HTML form submission, so it’s unknown whether or not the user submitted a value.
-
use_required_attribute
(initial)¶ Given a form field’s
initial
value, returns whether or not the widget can be rendered with therequired
HTML attribute. Forms use this method along withField.required
andForm.use_required_attribute
to determine whether or not to display therequired
attribute for each field.By default, returns
False
for hidden widgets andTrue
otherwise. Special cases areFileInput
andClearableFileInput
, which returnFalse
wheninitial
is set, andCheckboxSelectMultiple
, which always returnsFalse
because browser validation would require all checkboxes to be checked instead of at least one.Override this method in custom widgets that aren’t compatible with browser validation. For example, a WSYSIWG text editor widget backed by a hidden
textarea
element may want to always returnFalse
to avoid browser validation on the hidden field.
-
MultiWidget
¶
-
class
MultiWidget
(widgets, attrs=None)¶ A widget that is composed of multiple widgets.
MultiWidget
works hand in hand with theMultiValueField
.MultiWidget
has one required argument:-
widgets
¶ An iterable containing the widgets needed. For example:
>>> from django.forms import MultiWidget, TextInput >>> widget = MultiWidget(widgets=[TextInput, TextInput]) >>> widget.render('name', ['john', 'paul']) '<input type="text" name="name_0" value="john"><input type="text" name="name_1" value="paul">'
You may provide a dictionary in order to specify custom suffixes for the
name
attribute on each subwidget. In this case, for each(key, widget)
pair, the key will be appended to thename
of the widget in order to generate the attribute value. You may provide the empty string (''
) for a single key, in order to suppress the suffix for one widget. For example:>>> widget = MultiWidget(widgets={'': TextInput, 'last': TextInput}) >>> widget.render('name', ['john', 'paul']) '<input type="text" name="name" value="john"><input type="text" name="name_last" value="paul">'
And one required method:
-
decompress
(value)¶ This method takes a single “compressed” value from the field and returns a list of “decompressed” values. The input value can be assumed valid, but not necessarily non-empty.
This method must be implemented by the subclass, and since the value may be empty, the implementation must be defensive.
The rationale behind “decompression” is that it is necessary to “split” the combined value of the form field into the values for each widget.
An example of this is how
SplitDateTimeWidget
turns adatetime
value into a list with date and time split into two separate values:from django.forms import MultiWidget class SplitDateTimeWidget(MultiWidget): # ... def decompress(self, value): if value: return [value.date(), value.time()] return [None, None]
Tip
Note that
MultiValueField
has a complementary methodcompress()
with the opposite responsibility - to combine cleaned values of all member fields into one.
It provides some custom context:
-
get_context
(name, value, attrs)¶ In addition to the
'widget'
key described inWidget.get_context()
,MultiWidget
adds awidget['subwidgets']
key.These can be looped over in the widget template:
{% for subwidget in widget.subwidgets %} {% include subwidget.template_name with widget=subwidget %} {% endfor %}
Here’s an example widget which subclasses
MultiWidget
to display a date with the day, month, and year in different select boxes. This widget is intended to be used with aDateField
rather than aMultiValueField
, thus we have implementedvalue_from_datadict()
:from datetime import date from django import forms class DateSelectorWidget(forms.MultiWidget): def __init__(self, attrs=None): days = [(day, day) for day in range(1, 32)] months = [(month, month) for month in range(1, 13)] years = [(year, year) for year in [2018, 2019, 2020]] widgets = [ forms.Select(attrs=attrs, choices=days), forms.Select(attrs=attrs, choices=months), forms.Select(attrs=attrs, choices=years), ] super().__init__(widgets, attrs) def decompress(self, value): if isinstance(value, date): return [value.day, value.month, value.year] elif isinstance(value, str): year, month, day = value.split('-') return [day, month, year] return [None, None, None] def value_from_datadict(self, data, files, name): day, month, year = super().value_from_datadict(data, files, name) # DateField expects a single string that it can parse into a date. return '{}-{}-{}'.format(year, month, day)
The constructor creates several
Select
widgets in a list. Thesuper()
method uses this list to set up the widget.The required method
decompress()
breaks up adatetime.date
value into the day, month, and year values corresponding to each widget. If an invalid date was selected, such as the non-existent 30th February, theDateField
passes this method a string instead, so that needs parsing. The finalreturn
handles whenvalue
isNone
, meaning we don’t have any defaults for our subwidgets.The default implementation of
value_from_datadict()
returns a list of values corresponding to eachWidget
. This is appropriate when using aMultiWidget
with aMultiValueField
. But since we want to use this widget with aDateField
, which takes a single value, we have overridden this method. The implementation here combines the data from the subwidgets into a string in the format thatDateField
expects.-
Built-in widgets¶
Django provides a representation of all the basic HTML widgets, plus some
commonly used groups of widgets in the django.forms.widgets
module,
including the input of text, various checkboxes
and selectors, uploading files,
and handling of multi-valued input.
Widgets handling input of text¶
These widgets make use of the HTML elements input
and textarea
.
TextInput
¶
-
class
TextInput
¶ input_type
:'text'
template_name
:'django/forms/widgets/text.html'
- Renders as:
<input type="text" ...>
NumberInput
¶
-
class
NumberInput
¶ input_type
:'number'
template_name
:'django/forms/widgets/number.html'
- Renders as:
<input type="number" ...>
Beware that not all browsers support entering localized numbers in
number
input types. Django itself avoids using them for fields having theirlocalize
property set toTrue
.
EmailInput
¶
-
class
EmailInput
¶ input_type
:'email'
template_name
:'django/forms/widgets/email.html'
- Renders as:
<input type="email" ...>
URLInput
¶
-
class
URLInput
¶ input_type
:'url'
template_name
:'django/forms/widgets/url.html'
- Renders as:
<input type="url" ...>
PasswordInput
¶
-
class
PasswordInput
¶ input_type
:'password'
template_name
:'django/forms/widgets/password.html'
- Renders as:
<input type="password" ...>
Takes one optional argument:
-
render_value
¶ Determines whether the widget will have a value filled in when the form is re-displayed after a validation error (default is
False
).
DateInput
¶
-
class
DateInput
¶ input_type
:'text'
template_name
:'django/forms/widgets/date.html'
- Renders as:
<input type="text" ...>
Takes same arguments as
TextInput
, with one more optional argument:-
format
¶ The format in which this field’s initial value will be displayed.
If no
format
argument is provided, the default format is the first format found inDATE_INPUT_FORMATS
and respects Format localization.
DateTimeInput
¶
-
class
DateTimeInput
¶ input_type
:'text'
template_name
:'django/forms/widgets/datetime.html'
- Renders as:
<input type="text" ...>
Takes same arguments as
TextInput
, with one more optional argument:-
format
¶ The format in which this field’s initial value will be displayed.
If no
format
argument is provided, the default format is the first format found inDATETIME_INPUT_FORMATS
and respects Format localization.By default, the microseconds part of the time value is always set to
0
. If microseconds are required, use a subclass with thesupports_microseconds
attribute set toTrue
.
TimeInput
¶
-
class
TimeInput
¶ input_type
:'text'
template_name
:'django/forms/widgets/time.html'
- Renders as:
<input type="text" ...>
Takes same arguments as
TextInput
, with one more optional argument:-
format
¶ The format in which this field’s initial value will be displayed.
If no
format
argument is provided, the default format is the first format found inTIME_INPUT_FORMATS
and respects Format localization.For the treatment of microseconds, see
DateTimeInput
.
Selector and checkbox widgets¶
These widgets make use of the HTML elements <select>
,
<input type="checkbox">
, and <input type="radio">
.
Widgets that render multiple choices have an option_template_name
attribute
that specifies the template used to render each choice. For example, for the
Select
widget, select_option.html
renders the <option>
for a
<select>
.
CheckboxInput
¶
Select
¶
-
class
Select
¶ template_name
:'django/forms/widgets/select.html'
option_template_name
:'django/forms/widgets/select_option.html'
- Renders as:
<select><option ...>...</select>
NullBooleanSelect
¶
-
class
NullBooleanSelect
¶ template_name
:'django/forms/widgets/select.html'
option_template_name
:'django/forms/widgets/select_option.html'
Select widget with options ‘Unknown’, ‘Yes’ and ‘No’
SelectMultiple
¶
RadioSelect
¶
-
class
RadioSelect
¶ template_name
:'django/forms/widgets/radio.html'
option_template_name
:'django/forms/widgets/radio_option.html'
Similar to
Select
, but rendered as a list of radio buttons within<div>
tags:<div> <div><input type="radio" name="..."></div> ... </div>
Changed in Django 4.0:So they are announced more concisely by screen readers, radio buttons were changed to render in
<div>
tags.For more granular control over the generated markup, you can loop over the radio buttons in the template. Assuming a form
myform
with a fieldbeatles
that uses aRadioSelect
as its widget:<fieldset> <legend>{{ myform.beatles.label }}</legend> {% for radio in myform.beatles %} <div class="myradio"> {{ radio }} </div> {% endfor %} </fieldset>
This would generate the following HTML:
<fieldset> <legend>Radio buttons</legend> <div class="myradio"> <label for="id_beatles_0"><input id="id_beatles_0" name="beatles" type="radio" value="john" required> John</label> </div> <div class="myradio"> <label for="id_beatles_1"><input id="id_beatles_1" name="beatles" type="radio" value="paul" required> Paul</label> </div> <div class="myradio"> <label for="id_beatles_2"><input id="id_beatles_2" name="beatles" type="radio" value="george" required> George</label> </div> <div class="myradio"> <label for="id_beatles_3"><input id="id_beatles_3" name="beatles" type="radio" value="ringo" required> Ringo</label> </div> </fieldset>
That included the
<label>
tags. To get more granular, you can use each radio button’stag
,choice_label
andid_for_label
attributes. For example, this template…<fieldset> <legend>{{ myform.beatles.label }}</legend> {% for radio in myform.beatles %} <label for="{{ radio.id_for_label }}"> {{ radio.choice_label }} <span class="radio">{{ radio.tag }}</span> </label> {% endfor %} </fieldset>
…will result in the following HTML:
<fieldset> <legend>Radio buttons</legend> <label for="id_beatles_0"> John <span class="radio"><input id="id_beatles_0" name="beatles" type="radio" value="john" required></span> </label> <label for="id_beatles_1"> Paul <span class="radio"><input id="id_beatles_1" name="beatles" type="radio" value="paul" required></span> </label> <label for="id_beatles_2"> George <span class="radio"><input id="id_beatles_2" name="beatles" type="radio" value="george" required></span> </label> <label for="id_beatles_3"> Ringo <span class="radio"><input id="id_beatles_3" name="beatles" type="radio" value="ringo" required></span> </label> </fieldset>
If you decide not to loop over the radio buttons – e.g., if your template includes
{{ myform.beatles }}
– they’ll be output in a<div>
with<div>
tags, as above.The outer
<div>
container receives theid
attribute of the widget, if defined, orBoundField.auto_id
otherwise.When looping over the radio buttons, the
label
andinput
tags includefor
andid
attributes, respectively. Each radio button has anid_for_label
attribute to output the element’s ID.
CheckboxSelectMultiple
¶
-
class
CheckboxSelectMultiple
¶ template_name
:'django/forms/widgets/checkbox_select.html'
option_template_name
:'django/forms/widgets/checkbox_option.html'
Similar to
SelectMultiple
, but rendered as a list of checkboxes:<div> <div><input type="checkbox" name="..." ></div> ... </div>
The outer
<div>
container receives theid
attribute of the widget, if defined, orBoundField.auto_id
otherwise.Changed in Django 4.0:So they are announced more concisely by screen readers, checkboxes were changed to render in
<div>
tags.
Like RadioSelect
, you can loop over the individual checkboxes for the
widget’s choices. Unlike RadioSelect
, the checkboxes won’t include the
required
HTML attribute if the field is required because browser validation
would require all checkboxes to be checked instead of at least one.
When looping over the checkboxes, the label
and input
tags include
for
and id
attributes, respectively. Each checkbox has an
id_for_label
attribute to output the element’s ID.
File upload widgets¶
Composite widgets¶
SplitDateTimeWidget
¶
-
class
SplitDateTimeWidget
¶ template_name
:'django/forms/widgets/splitdatetime.html'
Wrapper (using
MultiWidget
) around two widgets:DateInput
for the date, andTimeInput
for the time. Must be used withSplitDateTimeField
rather thanDateTimeField
.SplitDateTimeWidget
has several optional arguments:-
date_format
¶ Similar to
DateInput.format
-
time_format
¶ Similar to
TimeInput.format
-
date_attrs
¶
-
time_attrs
¶ Similar to
Widget.attrs
. A dictionary containing HTML attributes to be set on the renderedDateInput
andTimeInput
widgets, respectively. If these attributes aren’t set,Widget.attrs
is used instead.
SelectDateWidget
¶
-
class
SelectDateWidget
¶ template_name
:'django/forms/widgets/select_date.html'
Wrapper around three
Select
widgets: one each for month, day, and year.Takes several optional arguments:
-
years
¶ An optional list/tuple of years to use in the “year” select box. The default is a list containing the current year and the next 9 years.
-
months
¶ An optional dict of months to use in the “months” select box.
The keys of the dict correspond to the month number (1-indexed) and the values are the displayed months:
MONTHS = { 1:_('jan'), 2:_('feb'), 3:_('mar'), 4:_('apr'), 5:_('may'), 6:_('jun'), 7:_('jul'), 8:_('aug'), 9:_('sep'), 10:_('oct'), 11:_('nov'), 12:_('dec') }
-
empty_label
¶ If the
DateField
is not required,SelectDateWidget
will have an empty choice at the top of the list (which is---
by default). You can change the text of this label with theempty_label
attribute.empty_label
can be astring
,list
, ortuple
. When a string is used, all select boxes will each have an empty choice with this label. Ifempty_label
is alist
ortuple
of 3 string elements, the select boxes will have their own custom label. The labels should be in this order('year_label', 'month_label', 'day_label')
.# A custom empty label with string field1 = forms.DateField(widget=SelectDateWidget(empty_label="Nothing")) # A custom empty label with tuple field1 = forms.DateField( widget=SelectDateWidget( empty_label=("Choose Year", "Choose Month", "Choose Day"), ), )