Change to using new-style markup for section headings in 15

Author: hjwp

chapter_15_advanced_forms.asciidoc

@@ -1,6 +1,5 @@
 [[chapter_15_advanced_forms]]
-More Advanced Forms 
--------------------
+== More Advanced Forms
 
 .🚧 Warning, Chapter update in progress
 *******************************************************************************
@@ -26,8 +25,7 @@ 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.
 
 
-Another FT for Duplicate Items
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+=== Another FT for Duplicate Items
 
 
 
@@ -67,7 +65,7 @@ enough that it's practical to keep them in different methods:
 
 [subs="specialcharacters,macros"]
 ----
-$ pass:quotes[*python manage.py test functional_tests.test_list_item_validation*] 
+$ pass:quotes[*python manage.py test functional_tests.test_list_item_validation*]
 [...]
 selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
 element: .has-error
@@ -81,15 +79,14 @@ just the failing one, I hear you ask?  Why, yes indeed:
 [subs="specialcharacters,macros"]
 ----
 $ pass:quotes[*python manage.py test functional_tests.\
-test_list_item_validation.ItemValidationTest.test_cannot_add_duplicate_items*] 
+test_list_item_validation.ItemValidationTest.test_cannot_add_duplicate_items*]
 [...]
 selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
 element: .has-error
 ----
 
 
-Preventing Duplicates at the Model Layer
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+==== Preventing Duplicates at the Model Layer
 
 
 ((("model-layer validation", "preventing duplicate items")))Here's
@@ -110,7 +107,7 @@ def test_duplicate_items_are_invalid(self):
 ----
 ====
 
-And, while it occurs to us, we add another test to make sure we don't 
+And, while it occurs to us, we add another test to make sure we don't
 overdo it on our integrity constraints:
 
 
@@ -128,7 +125,7 @@ def test_CAN_save_same_item_to_different_lists(self):
 ----
 ====
 
-I always like to put a little comment for tests which are checking 
+I always like to put a little comment for tests which are checking
 that a particular use case should 'not' raise an error; otherwise,
 it can be hard to see what's being tested:
 
@@ -228,13 +225,12 @@ class Item(models.Model):
 ----
 ====
 
-You might want to take a quick peek at the 
+You might want to take a quick peek at the
 https://docs.djangoproject.com/en/1.11/ref/models/options/[Django docs on model
 `Meta` attributes] at this point.
 
 
-A Little Digression on Queryset Ordering and String Representations
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+==== A Little Digression on Queryset Ordering and String Representations
 
 //TODO: actually, this error will never appear with the new migrations
 // framework. could drop this whole section?
@@ -425,14 +421,13 @@ OK
 // TODO: in theory we should do a migration now.
 
 [[rewrite-model-test]]
-Rewriting the Old Model Test 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+==== Rewriting the Old Model Test
 
 
 That long-winded model test did serendipitously help us find an unexpected
 bug, but now it's time to rewrite it. I wrote it in a very verbose style to
 introduce the Django ORM, but in fact, now that we have the explicit test for
-ordering, we can get the same coverage from a couple of much shorter tests. 
+ordering, we can get the same coverage from a couple of much shorter tests.
 Delete `test_saving_and_retrieving_items` and replace with this:
 
 [role="sourcecode"]
@@ -456,7 +451,7 @@ class ListAndItemModelsTest(TestCase):
     [...]
 ----
 ====
- 
+
 That's more than enough really--a check of the default values of attributes
 on a freshly initialized model object is enough to sanity-check that we've
 probably set some fields up in 'models.py'.  The "item is related to list" test
@@ -494,8 +489,7 @@ OK
 ----
 
 
-Some Integrity Errors Do Show Up on Save
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+==== Some Integrity Errors Do Show Up on Save
 
 
 
@@ -505,7 +499,7 @@ final aside before we move on. Do you remember I mentioned in
 on save?  It all depends on whether the integrity constraint is actually being
 enforced by the database.
 
-Try running `makemigrations` and you'll see that Django wants to add the 
+Try running `makemigrations` and you'll see that Django wants to add the
 `unique_together` constraint to the database itself, rather than just having
 it as an application-layer constraint:
 
@@ -577,8 +571,7 @@ $ pass:[<strong>git commit -am "Implement duplicate item validation at model lay
 ----
 
 
-Experimenting with Duplicate Item Validation at the Views Layer
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+=== Experimenting with Duplicate Item Validation at the Views Layer
 
 
 ((("duplicate items testing", "at the views layer", secondary-sortas="views layer")))Let's
@@ -648,8 +641,7 @@ from unittest import skip
 ====
 
 
-A More Complex Form to Handle Uniqueness Validation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+=== A More Complex Form to Handle Uniqueness Validation
 
 ((("duplicate items testing", "complex form for")))((("uniqueness validation", seealso="duplicate items testing")))The
 form to create a new list only needs to know one thing, the new item text.
@@ -695,7 +687,7 @@ class ExistingListItemFormTest(TestCase):
 ====
 
 Next we iterate through a few TDD cycles  until we get a form with a
-custom constructor, which just ignores its `for_list` argument. 
+custom constructor, which just ignores its `for_list` argument.
 (I won't show them all, but I'm sure you'll do them, right? Remember, the Goat
 sees all.)
 
@@ -742,7 +734,7 @@ AssertionError: True is not false
 ----
 
 The next step requires a little knowledge of Django's internals, but you
-can read up on it in the Django docs on 
+can read up on it in the Django docs on
 https://docs.djangoproject.com/en/1.11/ref/models/instances/#validating-objects[model
 validation] and
 https://docs.djangoproject.com/en/1.11/ref/forms/validation/[form validation].
@@ -788,8 +780,7 @@ $ *git commit -a*
 ----
 
 
-Using the Existing List Item Form in the List View
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+=== Using the Existing List Item Form in the List View
 
 ((("duplicate items testing", "in the list view", secondary-sortas="list view", id="DITlist15")))Now
 let's see if we can put this form to work in our view.
@@ -879,7 +870,7 @@ And that 'almost' fixes everything, except for an unexpected fail:
 TypeError: save() missing 1 required positional argument: 'for_list'
 ----
 
-Our custom save method from the parent `ItemForm` is no longer needed. 
+Our custom save method from the parent `ItemForm` is no longer needed.
 Let's make a quick unit test for that:
 
 //IDEA: add the form class names here so ppl know which test_form_save and save()
@@ -961,14 +952,13 @@ testing views over the last few chapters.((("", startref="DITlist15")))
 
 
 
-Wrapping Up: What We've Learned About Testing Django
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+=== Wrapping Up: What We've Learned About Testing Django
 
 ((("class-based generic views (CBGVs)", "key tests and assertions")))((("Django framework", "class-based generic views")))We're
 now at a point where our app looks a lot more like a "standard"
 Django app, and it implements the three common Django layers: models,
 forms, and views.  We no longer have any "training wheels&#x201d;-style tests,
-and our code looks pretty much like code we'd be happy to see in a 
+and our code looks pretty much like code we'd be happy to see in a
 real app.
 
 We have one unit test file for each of our key source code files.  Here's