Update Django version documn

This commit is contained in:
Philip Sargent 2023-02-11 23:04:08 +00:00
parent 069609e814
commit 678326aae3
6 changed files with 7 additions and 9 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 134 KiB

View File

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

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

View File

@ -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 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. along during the next 5 years we want to be able to use them effectively.
</div> </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> <h3>Option Zero.1</h2>
<div style="color:blue"> <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, <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 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>. 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 <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> some Django query optimisations if necessary - which are then handed as 'context' to the Django page template (those files in <var>

View File

@ -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= 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/streamlit/streamlit">Streamlit</a>, <a href=
"https://github.com/zauberzeug/nicegui">NiceGUI</a> and <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> <h3>Our biggest problem</h3>
We need: We need:

View File

@ -10,7 +10,7 @@
<h1>Handbook Troggle - Automated Testing</h1> <h1>Handbook Troggle - Automated Testing</h1>
<h2>Troggle Automated Testing</h2> <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: which are run manually by troggle programmers like this:
<pre><code> troggle$ python manage.py test -v 1</code></pre> <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 <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> <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> <h4>Automated testing on the server</h4>
<p>Something is stopping the test suite running on the server. We haven't fixed this yet. <p>Something is stopping the test suite running on the server. We haven't fixed this yet.