Django Rendering Fields Manually

In lesson Displaying Forms in Django we have learned various ways to display forms in Django. Although the methods discussed allow us to quickly create a form, it also gives us least control over how they are rendered as HTML. If you want to have pixel perfect control over your forms read on.

Open feedback.html template from the blog app. It should look something like this:


Delete everything and then add the following code:


Notice that the value of <input> tag’s name attribute is same as that of field names defined in the Feedback model.

Point your browser to Enter some data in the name and email field (it doesn’t matter whether the data is valid or not, just fill it) and leave the next two fields empty (i.e subject and comment). 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 well as errors associated with them). As a result, we are unable to show the bound state of the form to the user.

If we had been using f.as_p or f.as_table instead of hardcoding individual form field, we would get the errors as follows:

In addition to errors, the form is also not pre-populating data (valid or invalid) we entered in the
name and email 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 feedback.html and modify the file as follows:


Visit and hit submit button. You should see “This field is required.” error message just above the name field.

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 feedback.html and modify it as follows:


Using Shortcuts

Django also 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:

This above code is same as:

Note that, It doesn’t matter which shortcut you use the errors will always be rendered as an unordered list.

Open feedback.html 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 it’s value attribute to {{ }}.

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

Open feedback.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 thanks to

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

Open feedback.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.

At this point, our feedback form is displaying validation errors as well as pre-populating 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 too to generate the complete <label> tag using {{ form.field_name.label_tag}} variable.

So, {{ }}

is equivalent to:

Open feedback.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 }}. Recall that, we have defined help_text attribute for the name field while creating Feedback model:


Once again open feedback.html and add {{ }} just below {{ }} as follows:


Visit and you should see help_text beside name input field.

Looping over Form Fields

Django has another trick under its sleeves which allows you shorten the 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 cadmin app.

Note: To checkout this version of the repository type git checkout 23a.

3 thoughts on “Django Rendering Fields Manually

  1. In every example no one displays their for the application in question so you can just see what they’ve done and how it relates back to their tags in an HTML file. This forces an attempt at visualizing their in your head which usually just leads to more confusion.

Leave a Comment

%d bloggers like this: