Harry tweaks in 15

Author: hjwp

chapter_15_advanced_forms.asciidoc

@@ -1,20 +1,27 @@
 [[chapter_15_advanced_forms]]
 == More Advanced Forms
 
-// TODO Harry write a paragraph about the server side validation
-
 
 Now let's look at some more advanced forms usage.  We've helped our users
 to avoid blank list items, so now let's help them avoid duplicate items.
 
-This chapter goes into more intricate details of Django's form validation, and
-you have my official permission to skip it if you already know all about
-customising Django forms, or if you're reading this book for the TDD rather
-than for the Django.
+Our validation constraint so far has been about preventing blank items,
+and as you may remember, it turned out we can enforce that very easily in the frontend.
+Avoiding duplicate items is less straightforward to do in the frontend,
+(although not impossible of course),
+so this chapter will lean more heavily on server-side validation,
+and bubbling errors from the backend back up to the UI.
+
+This chapter goes into more intricate details of Django's forms framework,
+so you have my official permission to skip it
+if you already know all about customising Django forms and how to display errors in the UI,
+or if you're reading this book for the TDD rather than for the Django.
 
-If you're still learning Django, there's good stuff in here.  If you
-want to skip ahead, that's OK too. Make sure you take a quick look at the aside
-on developer stupidity, and the recap on testing views at the end.
+If you're still learning Django, there's good stuff in here!
+If you want to skip ahead, that's OK too.
+Make sure you take a quick look at the
+<<testing-for-stupidity,aside on developer stupidity>>,
+and the <<what-to-test-in-views,recap on testing views>> at the end.
 
 
 === Another FT for Duplicate Items
@@ -25,7 +32,9 @@ on developer stupidity, and the recap on testing views at the end.
 ((("functional tests (FTs)", "for duplicate items", secondary-sortas="duplicate items", id="FTduplicate15")))
 ((("duplicate items testing", "functional test for", id="DITfunctional15")))
 ((("user interactions", "preventing duplicate items", id="UIduplicate15")))
-We add a second test method to `ItemValidationTest`:
+We add a second test method to `ItemValidationTest`,
+and tell a little story about what we want to see happen
+when a user tries to enter the same item twice into their to-do list:
 
 [role="sourcecode"]
 .src/functional_tests/test_list_item_validation.py (ch15l001)
@@ -53,11 +62,13 @@ def test_cannot_add_duplicate_items(self):
 ----
 ====
 
-Why have two test methods rather than extending one, or having a new file
-and class?  It's a judgement call.  These two feel closely related; they're
-both about validation on the same input field, so it feels right to
-keep them in the same file.  On the other hand, they're logically separate
-enough that it's practical to keep them in different methods:
+Why have two test methods rather than extending one,
+or having a new file and class?
+It's a judgement call. These two feel closely related;
+they're both about validation on the same input field,
+so it feels right to keep them in the same file.
+On the other hand, they're logically separate enough
+that it's practical to keep them in different methods:
 
 
 [subs="specialcharacters,macros"]
@@ -907,6 +918,7 @@ a recap of the biggest (and highest-level) one, 'test_views' (the listing
 shows just the key tests and assertions, and your order may vary):
 // CSANAD: Why are we only showing ListViewTest? HomePageTest, NewListTest
 
+[[what-to-test-in-views]]
 .What to Test in Views
 ******************************************************************************