![Show Menu](styles/mobile-menu.png)
![Page Background](./../common/page-substrates/page0233.png)
In the invalid case, we pass the form down to the template, instead of our
hardcoded error string.
That view is now looking much nicer! And all our tests pass, except one:
self.assertContains(response, escape(EMPTY_LIST_ERROR))
[...]
AssertionError: False is not true : Couldn't find 'You can't have an empty
list item' in response
Using the Form to Display Errors in the Template
We’re failing because we’re not yet using the form to display errors in the template:
lists/templates/base.html (ch11l026).
<form
method=
"POST"
action=
"{% block form_action %}{% endblock %}"
>
{{ form.text }}
{% csrf_token %}
{% if form.errors %}
<div
class=
"form-group has-error"
>
<div
class=
"help-block"
>
{{ form.text.errors }}
</div>
</div>
{% endif %}
</form>
form.errors
contains a list of all the errors for the form.
form.text.errors
is a list of just the errors for the
text
field.
What does that do to our tests?
FAIL: test_validation_errors_end_up_on_lists_page
(lists.tests.test_views.ListViewTest)
[...]
AssertionError: False is not true : Couldn't find 'You can't have an empty
list item' in response
An unexpected failure—it’s actually in the tests for our final view,
view_list
. Because
we’ve changed the way errors are displayed in
all
templates, we’re no longer showing
the error that we manually pass into the template.
That means we’re going to need to rework
view_list
as well, before we can get back to
a working state.
Using the Form in the Other View
This view handles both GET and POST requests. Let’s start with checking the form is
used in GET requests. We can have a new test for that:
Using the Form in the Other View
|
205