Background Image
Table of Contents Table of Contents
Previous Page  233 / 478 Next Page
Information
Show Menu
Previous Page 233 / 478 Next Page
Page Background

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&#39;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