Django Rendering Form Fields Manually

In the previous lesson, we have seen several methods to display forms. No doubt that these methods allow us to quickly create forms but they also give the least control over how they are rendered. If you want to have a pixel-perfect control over your forms read on.

Currently, our add_lang.html template looks like this:


Before we render each fields manually, replace the <form> tag with the following code:

Point your browser to Enter some data in the name and lang_code field (it doesn’t matter whether the data is valid or not, just fill it) and leave the next two fields empty (i.e Slug and Mime). Finally hit the submit button. You will be displayed an empty form again.

Wait a minute! What’s going on? All our form fields are required but Why it’s now showing any errors?

The problem is that we are hardcoding our HTML, we are not using form methods like as_p() or as_table() to display the form fields. As a result, we are unable to show the bound state of the form to the user.

If we were using methods like as_p() or as_table() instead of hardcoding individual form field, we would get the validation errors as follows:

In addition to validation errors, the form is not pre-populating data (valid or invalid) we entered in the name and lang_code field while submitting the form in the last request.

In the following section, we will learn how to rectify all these problems.

Displaying field-specific errors

To display errors associated with a particular field use form.field_name.errors variable. For example, this is how we can display errors associated with the name field.

Open add_lang.html and modify the file as follows:


Visit and hit submit button without entering data in any field. You should see This field is required. error message just above the name field as follows:

Displaying non-field errors

Recall that we can override Form’s clean() method to add validation which requires access to more than one fields. The errors raised by clean() method are not specific to any field, in fact, the errors belong to the whole form. In Django terminology we call such errors Non-field errors. To access non-field errors inside the template we use form.non_field_errors variable. For example, we can use the following code to display non-field errors in our feedback form.

Open add_lang.html and modify it as follows:


Visit Add language page, enter same data in slug and mime field and then hit submit. You will see a non-field error at the top of the form like this:

Using Shortcuts

Django provides shortcuts to display field errors as well as non-field errors. We can also display the errors related to the name field as follows:

The above code is equivalent to:

Similarly, we can display non-field errors using the following shortcut:

The above code is equivalent to:

Open add_lang.html template and modify the file to use these shortcuts as follows:


Visit and hit submit button without entering anything, this time you should see This field is required. error message above every field.

Populating Field Values

The biggest usability problem in our form is that in the bound state, it doesn’t display any data that user has submitted in the previous request. For example, enter django in the name field and hit submit. You should see a form like this:

Notice that the name field has no data in it. Django provides bound field value in the variable form.field_name.value. So to display the data in the name field set the value attribute of corresponding <input> element to {{ }}.

But there is one small problem. If the form is in unbound state the {{ }} will print None. Therefore, you must always use the {% if %} tag to check the existence of a value in variable first before displaying anything. For example:

Open add-lang.html and modify the form as follows:


Visit again, enter "django" in the name field and hit Submit.

As expected our bound form is pre-populating data in the name field.

Django also provides {{ form.field_name }} shortcut to output the whole form field in bound as well as in unbound state. In other words, the {{ }} is same as:

Open add_lang.html and modify the file to use this new shortcut as follows:


An important thing to note about this shortcut is that it generates id values of the form id_fieldname, so if the name of the field is name, then the value of id attribute would be id_name.

Our feedback form is now working as expected. It can display validation errors as well as pre-populate data from the previous request.

Displaying Labels

Django provides the following two variables to generate label ids and label name respectively.

  1. form.field_name.id_for_label.
  2. form.field_name.label.

Here is how we can use them inside the <label> tag.

This would output:

Just like other fields, Django provides a shortcut to generate the complete <label> tag using {{ form.field_name.label_tag}} variable.

So, {{ }}

is equivalent to:

Open add_lang.html and modify the file to use form.field_name.label_tag variable as follows:


Printing help_text

We can also print the value of help_text attribute, if it is defined for a field in the model or form class. To print help_text we use {{ form.field_name.help_text }} variable.

Recall that, we have defined help_text attribute for the mime field in Language model as follows:


Once again open add_lang.html and add {{ form.mime.help_text }} just below {{ form.mime }} as follows:


Visit and you should see help_text beside the mime field as follows.

Looping over Form Fields

Django has another trick under its sleeves which allows you shorten your code further. Instead of manually typing individual fields, we can simply loop over form fields using the following code.

As usual, this method doesn’t output <form> tag and submit button (<input type="submit">), you have to add them manually in your code.

So as you can see, there is a trade-off between the amount of code you type and the control you get. The less code affords us the least control. We will be using some of the variables we learned here while creating forms for the djangobin app.

Leave a Comment