Simple Validation<\/h3>\n
Our search example is still reasonably simple, particularly in terms of its data validation; we\u2019re merely checking to make sure the search query isn\u2019t empty. Many HTML forms include a level of validation that\u2019s more complex than making sure the value is non-empty. We\u2019ve all seen the error messages on web sites:=<\/p>\n
- \n
- \u201cPlease enter a valid e-mail address. \u2018foo\u2019 is not an e-mail address.\u201d<\/li>\n
- \u201cPlease enter a valid five-digit U.S. ZIP code. \u2018123\u2019 is not a ZIP code.\u201d<\/li>\n
- \u201cPlease enter a valid date in the format YYYY-MM-DD.\u201d<\/li>\n
- \u201cPlease enter a password that is at least 8 characters long and contains at least one number.\u201d<\/li>\n<\/ul>\n
Let\u2019s tweak our search() view so that it validates that the search term is less than or equal to 20 characters long. (For sake of example, let\u2019s say anything longer than that might make the query too slow.) How might we do that? The simplest possible thing would be to embed the logic directly in the view, like this:<\/p>\n
def search(request):
\nerror = False
\nif ‘q’ in request.GET:
\nq = request.GET[‘q’]\nif not q:
\nerror = True
\nelif len(q) > 20:
\nerror = True
\nelse:
\nbooks = Book.objects.filter(title__icontains=q)
\nreturn render(request, ‘search_results.html’, {‘books’: books, ‘query’: q})
\nreturn render(request, ‘search_form.html’, {‘error’: error})<\/p>\nNow, if you try submitting a search query greater than 20 characters long, it won\u2019t let you search; you\u2019ll get an error message. But that error message in search_form.html currently says “Please submit a search term.”\u2013 so we\u2019ll have to change it to be accurate for both cases:<\/p>\n
<html>
\n<head>
\n<title>Search<\/title>
\n<\/head>
\n<body>
\n{% if error %}
\n<p style=”color: red;”>
\nPlease submit a search term 20 characters or shorter.
\n<\/p>
\n{% endif %}<\/p>\n<form action=”\/search\/” method=”get”>
\n<input type=”text” name=”q”>
\n<input type=”submit” value=”Search”>
\n<\/form>
\n<\/body>
\n<\/html><\/p>\nThere\u2019s something ugly about this. Our one-size-fits-all error message is potentially confusing. Why should the error message for an empty form submission mention anything about a 20-character limit? Error messages should be specific, unambiguous and not confusing. The problem is in the fact that we\u2019re using a simple boolean value for error, whereas we should be using a list of error message strings. Here\u2019s how we might fix that:<\/p>\n
def search(request):
\nerrors = []\nif ‘q’ in request.GET:
\nq = request.GET[‘q’]\nif not q:
\nerrors.append(‘Enter a search term.’)
\nelif len(q) > 20:
\nerrors.append(‘Please enter at most 20 characters.’)
\nelse:
\nbooks = Book.objects.filter(title__icontains=q)
\nreturn render(request, ‘search_results.html’, {‘books’: books, ‘query’: q})
\nreturn render(request, ‘search_form.html’, {‘errors’: errors})<\/p>\nThen, we need make a small tweak to the search_form.html template to reflect that it\u2019s now passed an errors list instead of an error boolean value:<\/p>\n
<html>
\n<head>
\n<title>Search<\/title>
\n<\/head>
\n<body>
\n{% if errors %}
\n<ul>
\n{% for error in errors %}
\n<li>{{ error }}<\/li>
\n{% endfor %}
\n<\/ul>
\n{% endif %}
\n<form action=”\/search\/” method=”get”>
\n<input type=”text” name=”q”>
\n<input type=”submit” value=”Search”>
\n<\/form>
\n<\/body>
\n<\/html><\/p>\nMaking a Contact Form<\/h3>\n
Although we iterated over the book search form example several times and improved it nicely, it\u2019s still fundamentally simple: just a single field, ‘q’. As forms get more complex, we have to repeat the above steps over and over again for each form field we use. This introduces a lot of cruft and a lot of opportunities for human error. Lucky for us, the Django\u2019s developers thought of this and built into Django a higher-level library that handles form- and validation-related tasks.<\/p>\n
Your First Form Class – Django comes with a form library, called django.forms, that handles many of the issues we\u2019ve been exploring this chapter \u2013 from HTML form display to validation. Let\u2019s dive in and rework our contact form application using the Django forms framework. The primary way to use the forms framework is to define a Form class for each HTML <form> you\u2019re dealing with.<\/p>\n
In our case, we only have one <form>, so we\u2019ll have one Form class. Django community convention is to keep Form classes in a separate file called forms.py. Create this file in the same directory as your mysite\\views.py, and enter the following:<\/p>\n
# mysite_project\\mysite\\mysite\\forms.py<\/p>\n
from django import forms<\/p>\n
class ContactForm(forms.Form):
\nsubject = forms.CharField()
\nemail = forms.EmailField(required=False)
\nmessage = forms.CharField()<\/p>\nThis is pretty intuitive, and it\u2019s similar to Django\u2019s model syntax. Each field in the form is represented by a type of Field class \u2013 CharField and EmailField are the only types of fields used here \u2013 as attributes of a Form class. Each field is required by default, so to make email optional, we specify required=False.<\/p>\n
Let\u2019s hop into the Python interactive interpreter and see what this class can do. The first thing it can do is display itself as HTML:<\/p>\n
(env_mysite) C:\\Users\\…\\mysite> python manage.py shell<\/p>\n
>>> from mysite.forms import ContactForm
\n>>> f = ContactForm()
\n>>> print(f)
\n<tr><th><label for=”id_subject”>Subject:<\/label><\/th><td><input type=”text” name=”subject” required id=”id_subject” \/><\/td><\/tr>
\n<tr><th><label for=”id_email”>Email:<\/label><\/th><td><input type=”email” name=”email” id=”id_email” \/><\/td><\/tr>
\n<tr><th><label for=”id_message”>Message:<\/label><\/th><td><input type=”text” name=”message” required id=”id_message” \/><\/td><\/tr><\/p>\nDjango adds a label to each field, along with <label> tags for accessibility. The idea is to make the default behavior as optimal as possible. This default output is in the format of an HTML <table>, but there are a few other built-in outputs:<\/p>\n
>>> print(f.as_ul())
\n<li><label for=”id_subject”>Subject:<\/label> <input type=”text” name=”subject” required id=”id_subject” \/><\/li>
\n<li><label for=”id_email”>Email:<\/label> <input type=”email” name=”email” id=”id_email” \/><\/li>
\n<li><label for=”id_message”>Message:<\/label> <input type=”text” name=”message” required id=”id_message” \/><\/li><\/p>\n>>> print(f.as_p())
\n<p><label for=”id_subject”>Subject:<\/label> <input type=”text” name=”subject” required id=”id_subject” \/><\/p>
\n<p><label for=”id_email”>Email:<\/label> <input type=”email” name=”email” id=”id_email” \/><\/p>
\n<p><label for=”id_message”>Message:<\/label> <input type=”text” name=”message” required id=”id_message” \/><\/p><\/p>\nNote that the opening and closing <table>, <ul> and <form> tags aren\u2019t included in the output, so that you can add any additional rows and customization if necessary. These methods are just shortcuts for the common case of displaying the entire form. You can also display the HTML for a particular field:<\/p>\n
>>> print(f[‘subject’])
\n<input type=”text” name=”subject” required id=”id_subject” \/>
\n>>> print f[‘message’]\n<input type=”text” name=”message” required id=”id_message” \/><\/p>\nThe second thing Form objects can do is validate data. To validate data, create a new Form object and pass it a dictionary of data that maps field names to data:<\/p>\n
>>> f = ContactForm({‘subject’: ‘Hello’, ’email’: ‘nige@example.com’, ‘message’: ‘Nice site!’})<\/p>\n
Once you\u2019ve associated data with a Form instance, you\u2019ve created a \u201cbound\u201d form:<\/p>\n
>>> f.is_bound
\nTrue<\/p>\nCall the is_valid() method on any bound Form to find out whether its data is valid. We\u2019ve passed a valid value for each field, so the Form in its entirety is valid:<\/p>\n
>>> f.is_valid()
\nTrue<\/p>\nIf we don\u2019t pass the email field, it\u2019s still valid, because we\u2019ve specified required=False for that field:<\/p>\n
>>> f = ContactForm({‘subject’: ‘Hello’, ‘message’: ‘Nice site!’})
\n>>> f.is_valid()
\nTrue<\/p>\nBut, if we leave off either subject or message, the Form is no longer valid:<\/p>\n
>>> f = ContactForm({‘subject’: ‘Hello’})
\n>>> f.is_valid()
\nFalse
\n>>> f = ContactForm({‘subject’: ‘Hello’, ‘message’: ”})
\n>>> f.is_valid()
\nFalse<\/p>\nYou can drill down to get field-specific error messages:<\/p>\n
>>> f = ContactForm({‘subject’: ‘Hello’, ‘message’: ”})
\n>>> f[‘message’].errors
\n[‘This field is required.’]\n>>> f[‘subject’].errors
\n[ ]\n>>> f[’email’].errors
\n[ ]\nEach bound Form instance has an errors attribute that gives you a dictionary mapping field names to error-message lists:<\/p>\n
>>> f = ContactForm({‘subject’: ‘Hello’, ‘message’: ”})
\n>>> f.errors
\n{‘message’`: [‘This field is required.’]}<\/p>\nFinally, for Form instances whose data has been found to be valid, a cleaned_data attribute is available. This is a dictionary of the submitted data, \u201ccleaned up\u201d. Django\u2019s forms framework not only validates data; it cleans it up by converting values to the appropriate Python types:<\/p>\n
>>> f = ContactForm({‘subject’: ‘Hello’, ’email’: ‘nige@example.com’, ‘message’: ‘Nice site!’})
\n>>> f.is_valid()
\nTrue
\n>>> f.cleaned_data
\n{‘subject’: ‘Hello’, ’email’: ‘nige@example.com’, ‘message’: ‘Nice site!’}<\/p>\nOur contact form only deals with strings, which are \u201ccleaned\u201d into string objects \u2013 but if we were to use an IntegerField or DateField, the forms framework would ensure that cleaned_data used proper Python integers or datetime.date objects for the given fields.<\/p>\n
Tying Forms to Views<\/h3>\n
Our contact form is not much good to us unless we have some way of displaying it to the user. To do this, we need to first update our mysite\\views.py:<\/p>\n
# mysite_project\\mysite\\mysite\\views.py<\/p>\n
from django.http import Http404, HttpResponse, HttpResponseRedirect
\nfrom django.shortcuts import render
\nimport datetime
\nfrom mysite.forms import ContactForm
\nfrom django.core.mail import send_mail, get_connection<\/p>\n# …<\/p>\n
def contact(request):
\nif request.method == ‘POST’:
\nform = ContactForm(request.POST)
\nif form.is_valid():
\ncd = form.cleaned_data
\ncon = get_connection(‘django.core.mail.backends.console.EmailBackend’)
\nsend_mail(
\ncd[‘subject’],
\ncd[‘message’],
\ncd.get(’email’, ‘noreply@example.com’),
\n[‘siteowner@example.com’],
\nconnection=con
\n)
\nreturn HttpResponseRedirect(‘\/contact\/thanks\/’)
\nelse:
\nform = ContactForm()<\/p>\nreturn render(request, ‘contact_form.html’, {‘form’: form})<\/p>\n
We\u2019ve added the contact function to our view to handle the form submission. In this new function, we:<\/p>\n
- \n
- Check to see if the request have been submitted with the POST method, otherwise we just display the blank form.<\/li>\n
- We then check if the form contains valid data by calling the form\u2019s is_valid() method.<\/li>\n
- If the form contains valid data, an email is sent and the user is redirected to a new view (\/contact\/thanks\/).<\/li>\n
- If the form doesn\u2019t contain valid data, the if block jumps out to the final render() and the form is rendered back to the browser.<\/li>\n<\/ul>\n
Note that we don\u2019t do any error handling in the view \u2013 this is all handled by the form class. If the form doesn\u2019t validate, Django will automatically create a list of errors and append them to the response.<\/p>\n
A contact form is not much use without some way of sending the contact form information to the site owner. A very common way of doing this is to send an email. Django has the ability to send emails built in to the core. The email functions can be found in the django.core.mail module, which I have imported at the top of our modified views.py.<\/p>\n
We are using the send_mail() function to send the email to a dummy email address.<\/p>\n
To be able to display our contact form, we have to create our contact form (save this to mysite\\templates):<\/p>\n
# mysite_project\\mysite\\templates\\contact_form.html<\/p>\n
<html>
\n<head>
\n<title>Contact us<\/title>
\n<\/head>
\n<body>
\n<h1>Contact us<\/h1><\/p>\n{% if form.errors %}
\n<p style=”color: red;”>
\nPlease correct the error{{ form.errors|pluralize }} below.
\n<\/p>
\n{% endif %}<\/p>\n<form action=”” method=”post” novalidate>
\n<table>
\n{{ form.as_table }}
\n<\/table>
\n{% csrf_token %}
\n<input type=”submit” value=”Submit”>
\n<\/form>
\n<\/body>
\n<\/html><\/p>\nSince we\u2019re creating a POST form (which can have the effect of modifying data), we need to worry about Cross Site Request Forgeries. Thankfully, you don\u2019t have to worry too hard, because Django comes with a very easy-to-use system for protecting against it.<\/p>\n
In short, all POST forms that are targeted at internal URLs should use the {% csrf_token %} template tag.<\/p>\n
Keen-eyed readers will also notice the novalidate attribute in the <form> tag. When using HTML5 in some of the latest browsers (notably Chrome), form fields will be automatically validated by the browser. As we want Django to handle form validation, the novalidate attribute tells the browser not to validate the form.<\/p>\n
Finally, we need to change our urls.py to display our contact form at \/contact\/:<\/p>\n
# …
\nfrom mysite.views import hello, current_datetime, hours_ahead, contact<\/p>\nurlpatterns = [
\n# …
\nurl(r’^contact\/$’, contact),
\nurl(r’^’, include(‘books.urls’)),
\n]\nTry running this locally. Load the form, submit it with none of the fields filled out figure below, submit it with an invalid e-mail address (Figure 6-6), then finally submit it with valid data.<\/p>\n
![\"\"](\"https:\/\/www.vskills.in\/lms\/wp-content\/uploads\/2016\/07\/31.jpg\")
<\/p>\n<\/p>\n
![\"\"](\"https:\/\/www.vskills.in\/lms\/wp-content\/uploads\/2016\/07\/32.jpg\")
<\/p>\nNote that you will get a \u201cPage not found (404)\u201d error when you submit the completed form. This is because I have not created the view or URLconf for the redirect to \/contact\/thanks\/. I will leave this to you as a learning exercise.
\nChanging How Fields Are Rendered
\nProbably the first thing you\u2019ll notice when you render this form locally is that the message field is displayed as an <input type=”text”>, and it ought to be a <textarea>. We can fix that by setting the field\u2019s widget:<\/p>\nfrom django import forms<\/p>\n
class ContactForm(forms.Form):
\nsubject = forms.CharField()
\nemail = forms.EmailField(required=False)
\nmessage = forms.CharField(widget=forms.Textarea)<\/p>\nThe forms framework separates out the presentation logic for each field into a set of widgets. Each field type has a default widget, but you can easily override the default, or provide a custom widget of your own. Think of the Field classes as representing validation logic, while widgets represent presentation logic.
\nSetting a Maximum Length
\nOne of the most common validation needs is to check that a field is of a certain size. For good measure, we should improve our ContactForm to limit the subject to 100 characters. To do that, just supply a max_length to the CharField, like this:<\/p>\nfrom django import forms<\/p>\n
class ContactForm(forms.Form):
\nsubject = forms.CharField(max_length=100)
\nemail = forms.EmailField(required=False)
\nmessage = forms.CharField(widget=forms.Textarea)<\/p>\nAn optional min_length argument is also available.
\nSetting Initial Values
\nAs an improvement to this form, let\u2019s add an initial value for the subject field: \u201cI love your site!\u201d (A little power of suggestion can\u2019t hurt.) To do this, we can use the initial argument when we create a Form instance:<\/p>\ndef contact(request):<\/p>\n
# …<\/p>\n
else:
\nform = ContactForm(
\ninitial={‘subject’: ‘I love your site!’}
\n)<\/p>\nreturn render(request, ‘contact_form.html’, {‘form’:form})<\/p>\n
Now, the subject field will be displayed pre-populated with that kind statement. Note that there is a difference between passing initial data and passing data that binds the form. The biggest difference is that if you\u2019re just passing initial data, then the form will be unbound, which means it won\u2019t have any error messages.<\/p>\n\n\n