Update Django version documn

handbook/troggle/pyodide-logo.webp:Zone.Identifier

@@ -1,4 +0,0 @@
-[ZoneTransfer]
-ZoneId=3
-ReferrerUrl=https://pyodide.org/en/stable/
-HostUrl=https://pyodide.org/en/stable/_static/pyodide-logo.png

handbook/troggle/trog2030.html

@@ -76,12 +76,13 @@ Documentation and a working list of on-going programming projects is the key to
 useful week's work, e.g. extracting the parsed logbooks to use shelve() storage throughout instead of SQL. The next time someone like Radost comes 
 along during the next 5 years we want to be able to use them effectively.
 </div>
+<p>[Decrufting and refactoring has been continuous since 2020. The ExpeditionDay class was refactored away and many unused properties of classes have been removed. DB query optimisation is only just beginning in 2023 though.]
 
 <h3>Option Zero.1</h2>
 <div style="color:blue">
 <p>We should probably review and revise all the over-complex templates, originally written in 2006, which do serious amounts of database querying, 
-and linked object sub-querying, within the template code. This is a nightmare to maintain and debug, e.g. see 
-the note at the bottom of <a href="/personexpedition/Wookey/1999">Wookey 1999 trips</a>.
+and linked object sub-querying, within the template code. This is a nightmare to maintain and debug. <!--e.g. see 
+the note at the bottom of <a href="/personexpedition/Wookey/1999">Wookey 1999 trips</a> - this fixed itself after de-crufting elsewhere -->
 
 <p>A possible goal would be to create all the data that will be displayed in a page as dictionaries - generated by obviously simple python, with 
 some Django query optimisations if necessary - which are then handed as 'context' to the Django page template (those files in <var>

handbook/troggle/trogspeculate.html

@@ -75,7 +75,8 @@ frameworks. There are now some Python frameworks, so maybe one of these will giv
 the stability we want that Javascript is failing to provide, such as <a href=
 "https://github.com/streamlit/streamlit">Streamlit</a>, <a href=
 "https://github.com/zauberzeug/nicegui">NiceGUI</a> and <a href=
-"https://github.com/pynecone-io/pynecone" rel="noopener noreferrer">Pynecone</a>. Though things running on <a href="https://en.wikipedia.org/wiki/WebAssembly">wasm</a> are perhaps going to be more future-proof. [2023].
+"https://github.com/pynecone-io/pynecone" rel="noopener noreferrer">Pynecone</a>. Though things running on <a href="https://en.wikipedia.org/wiki/WebAssembly">wasm</a> are perhaps going to be more future-proof. [2023]. 
+<p>It looks possible that the <a href="https://htmx.org/">&lt;HTMX&gt;</a> approach may settle down to replace HTML5 and also subsume a lot of what is now provided inside Javascript frameworks. We will wait until then.
 
 <h3>Our biggest problem</h3>
 We need:

handbook/troggle/trogtests.html

@@ -10,7 +10,7 @@
 <h1>Handbook Troggle - Automated Testing</h1>
 
 <h2>Troggle Automated Testing</h2>
-<p>We have a suite of more than 70 <a href="https://en.wikipedia.org/wiki/Smoke_testing_(software)">smoke tests</a> 
+<p>We have a suite of more than 85 <a href="https://en.wikipedia.org/wiki/Smoke_testing_(software)">smoke tests</a> 
 which are run manually by troggle programmers like this:
 <pre><code> troggle$ python manage.py test -v 1</code></pre>
 
@@ -49,7 +49,7 @@ No tests are run with the real expo database.
 
 <p>As yet we have no test database set up, so the in-memory database starts entirely empty. However we have 'fixtures' in 
 <var>troggle/core/fixtures/ </var>
-which are JSON files containing dummy data which is read in before a few of the tests. 
+which are JSON files containing dummy data which is read in before a few of the tests. (Though current wisdom is that <a href="https://lukeplant.me.uk/blog/posts/test-factory-functions-in-django/">factory methods in the test suite</a> are a superior way of managing tests for very long-term projects like ours.)
 
 <h4>Automated testing on the server</h4>
 <p>Something is stopping the test suite running on the server. We haven't fixed this yet.