Merge branch 'main' into review-chapter-11

Author: hjwp

.github/workflows/tests.yml

@@ -33,6 +33,6 @@ jobs:
     steps:
       - uses: actions/checkout@v4
       - id: foo
-        uses: hjwp/github-actions@v5
+        uses: hjwp/github-actions@v6
         with:
           test_chapter: ${{ matrix.test_chapter }}

.gitmodules

@@ -38,7 +38,7 @@
 	path = source/chapter_15_advanced_forms/superlists
 	url = [email protected]:hjwp/book-example.git
 [submodule "source/chapter_14/superlists"]
-	path = source/chapter_javascript/superlists
+	path = source/chapter_16_javascript/superlists
 	url = [email protected]:hjwp/book-example.git
 [submodule "source/chapter_15/superlists"]
 	path = source/chapter_deploying_validation/superlists

Makefile

@@ -47,7 +47,7 @@ build: $(HTML_PAGES) $(TMPDIR)
 
 
 .venv/bin:
-	which uv && uv venv .venv || python -m venv .venv
+	which uv && uv venv .venv || python3 -m venv .venv
 	which uv && uv pip install -e . || .venv/bin/pip install -e .
 
 .PHONY: install
@@ -128,9 +128,9 @@ test_chapter_14_simple_form: chapter_14_simple_form.html $(TMPDIR) .venv/bin
 .PHONY: test_chapter_15_advanced_forms
 test_chapter_15_advanced_forms: chapter_15_advanced_forms.html $(TMPDIR) .venv/bin
 	.venv/bin/pytest -s --tb=short ./tests/test_chapter_15_advanced_forms.py
-.PHONY: test_chapter_javascript
-test_chapter_javascript: chapter_javascript.html $(TMPDIR) .venv/bin
-	.venv/bin/pytest -s --tb=short ./tests/test_chapter_javascript.py
+.PHONY: test_chapter_16_javascript
+test_chapter_16_javascript: chapter_16_javascript.html $(TMPDIR) .venv/bin
+	.venv/bin/pytest -s --tb=short ./tests/test_chapter_16_javascript.py
 .PHONY: test_chapter_deploying_validation
 test_chapter_deploying_validation: chapter_deploying_validation.html $(TMPDIR) .venv/bin
 	.venv/bin/pytest -s --tb=short ./tests/test_chapter_deploying_validation.py

acknowledgments.asciidoc

@@ -111,6 +111,7 @@ Patrick Cantwell,
 Devin Schumacher,
 Nick Nielsen,
 Teemu Viikeri,
+Andrew Zipperer,
 and to anyone I've missed off this list,
 my sincere apologies, and thank you thank you once again.
 

appendix_github_links.asciidoc

@@ -34,7 +34,7 @@ Full List of Links for Each Chapter
 <<chapter_13_database_layer_validation>>:: https://github.com/hjwp/book-example/tree/chapter_13_database_layer_validation
 <<chapter_14_simple_form>>:: https://github.com/hjwp/book-example/tree/chapter_14_simple_form
 <<chapter_15_advanced_forms>>:: https://github.com/hjwp/book-example/tree/chapter_15_advanced_forms
-<<chapter_javascript>>:: https://github.com/hjwp/book-example/tree/chapter_javascript
+<<chapter_16_javascript>>:: https://github.com/hjwp/book-example/tree/chapter_16_javascript
 <<chapter_deploying_validation>>:: https://github.com/hjwp/book-example/tree/chapter_deploying_validation
 <<chapter_spiking_custom_auth>>:: https://github.com/hjwp/book-example/tree/chapter_spiking_custom_auth
 <<chapter_mocking>>:: https://github.com/hjwp/book-example/tree/chapter_mocking

appendix_rest_api.asciidoc

@@ -866,7 +866,7 @@ QUnit.test("should call updateItems after successful post", function (assert) {
 <1> First important thing to notice:  We only set up our server response
     'after' we do the initialize.  We want this to be the response to the
     POST request that happens on form submit, not the response to the
-    initial GET request. (Remember our lesson from <<chapter_javascript>>?
+    initial GET request. (Remember our lesson from <<chapter_16_javascript>>?
     One of the most challenging things about JS testing is controlling the
     order of execution.)
 

atlas.json

@@ -27,7 +27,7 @@
     "chapter_13_database_layer_validation.asciidoc",
     "chapter_14_simple_form.asciidoc",
     "chapter_15_advanced_forms.asciidoc",
-    "chapter_javascript.asciidoc",
+    "chapter_16_javascript.asciidoc",
     "chapter_deploying_validation.asciidoc",
     "part3.asciidoc",
     "chapter_spiking_custom_auth.asciidoc",

book.asciidoc

@@ -37,7 +37,7 @@ include::chapter_12_organising_test_files.asciidoc[]
 include::chapter_13_database_layer_validation.asciidoc[]
 include::chapter_14_simple_form.asciidoc[]
 include::chapter_15_advanced_forms.asciidoc[]
-include::chapter_javascript.asciidoc[]
+include::chapter_16_javascript.asciidoc[]
 include::chapter_deploying_validation.asciidoc[]
 
 include::part3.forbook.asciidoc[]

chapter_04_philosophy_and_refactoring.asciidoc

@@ -716,7 +716,7 @@ NOTE: This is another distinction between FTs and unit tests;
     we use them as the primary tool for testing our UI,
     and the HTML that implements it.
 
-So, wanted an `<h1>`:
+So, we wanted an `<h1>`:
 
 [role="sourcecode"]
 .lists/templates/home.html (ch04l008)
@@ -916,7 +916,7 @@ but it should be enough to reassure ourselves that things are working.
 To get that functional test to green,
 we then enter into the lower-level unit tests cycle,
 where we put together all the moving parts required,
-add tests for all the edge cases.
+and add tests for all the edge cases.
 Any time we get to green & refactored at the unit tests level,
 we can pop back up to the FT level to guide us towards the
 next thing we need to work.

chapter_05_post_and_database.asciidoc

@@ -355,7 +355,7 @@ def home_page(request):
 OK that gets our unit tests passing, but it's not really what we want.footnote:[
 But we _did_ learn about `request.method` and `request.POST` right?
 I know it might seem that I'm overdoing it,
-but doing things in tiny little really does have a lot of advantages,
+but doing things in tiny little steps really does have a lot of advantages,
 and one of them is that you can really think about (or in this case, learn)
 one thing at a time.]
 
@@ -633,7 +633,7 @@ on applying DRY too quickly.
 
 
 Now we get to the `self.fail('Finish the test!')`.
-If get rid of that and finish writing our FT,
+If we get rid of that and finish writing our FT,
 to add the check for adding a second item to the table
 (copy and paste is our friend),
 we begin to see that our first cut solution really isn't going to, um, cut it:
@@ -964,7 +964,7 @@ django.db.utils.OperationalError: no such table: lists_item
 ----
 
 In Django, the ORM's job is to model and read and write from database tables,
-but there's a second system that's in charge,of actually _creating_
+but there's a second system that's in charge of actually _creating_
 the tables in the database called "migrations".
 Its job is to let you to add, remove, and modify tables and columns,
 based on changes you make to your _models.py_ files.