add notes on improving clarity of intent, and the order of validation and writing to db

Author: Xronophobe

chapter_13_database_layer_validation.asciidoc

@@ -198,11 +198,17 @@ Let's hack it in to see it work:
 [source,python]
 ----
     with self.assertRaises(ValidationError):
-        item.save()
         item.full_clean()
+        item.save()
 ----
 ====
 //19
+// CSANAD: full_clean() should be executed before save() is called. It doesn't
+//         make a difference here since the test DB is destroyed anyway, but
+// we are actually saving an invalid item and only then calling full_clean().
+// Which results in raising the correct error. But I think we should always
+// show the correct order even when it doesn't matter: validation first and
+// only then attempting save().
 
 That gets the unit test to pass:
 
@@ -593,6 +599,19 @@ The current situation is that we have one view and URL for displaying a list,
 and one view and URL for processing additions to that list.  We're going to
 combine them into one. So, in 'list.html', our form will have a different
 target:
+// CSANAD: Since we are working in a not completely working state, I would
+// already mention or move the NOTE here from the end of the subsection:
+//   "Refactor: Transferring the new_item Functionality into view_list".
+// And then just re-reference it from where it is right now.
+//
+// I think adding a few words on how this is not just a simple refactor but it's
+// going to get us to our working state would help the reader recognise these
+// situations later, independently.
+// Something like pointing out how the FT is partially passing for:
+//  - adding one empty list item results in an error message
+//  - adding one valid list item is also passing
+//  - the error occurs when we try adding an empty list item again
+// from which we conclude why we are refactoring the views first
 
 [role="sourcecode"]
 .src/lists/templates/list.html (ch11l030)
@@ -634,7 +653,10 @@ NOTE: In this section we're performing a refactor at the application level.
     and things are back to working as before.
     Have another look at the diagram from the end of <<chapter_04_philosophy_and_refactoring>>
     if you need to get your bearings.
-
+// CSANAD: my comment from above to say a few words on why we are refactoring
+//         despite the failing FT again feels justified since we are even
+// mentioning the diagram too. It might feel confusing without telling the
+// reader earlier what we are doing here.
 
 
 ==== Refactor: Transferring the new_item Functionality into view_list