diff --git a/handbook/computing/basiclaptop.html b/handbook/computing/basiclaptop.html index ec93053c1..c709ca4b5 100644 --- a/handbook/computing/basiclaptop.html +++ b/handbook/computing/basiclaptop.html @@ -34,7 +34,10 @@
We are actively working on increasing the number of expo activities that can be done with just a browser and no installed software.
If you have not actively used troggle since 2018, you are probably not aware of all the things you can now do with just a browser. Many of these capabilities are not new, but they weren't documented and had been forgotten over the past 10+ years. Now these capabilities are documented, though writing better documentation is an unending job. +
If you have not actively used troggle since 2018, you are probably not aware of all the things you can now do with just a +browser. Many of these capabilities are not new, but they weren't documented and had been forgotten over the past 10+ years. Now these capabilities are documented, though writing better documentation is an unending job, and we have a data maintenance manual.
A real architectural option would be to move to Redis as an in-memory database instead of using MariaDB. We don't need a fully-fledged database and these new frameworks are less closely tied to having a SQL database and object-request broker (ORM) than Django is. This ties in neatly which Option 2 above: -reduce our use of the database functions within Django to vanishing point. +reduce our use of the database functions within Django to vanishing point. [Oops. That would be a mistake. It is the SQL database that handles +all the multi-user non-interference, not Django. So unless we want to roll our own real-time software synchronisation.. Better not go there.]
ASGI, which Dango supports from v3.2 too, has the interesting effect that we no longer need a webserver like Apache or nginx to buffer requests. We can use very lightweight uvicorn instead.
There is not yet a front-end (javascript) framework on the client, i.e. a phone app or webpage, which is stable enough for us to commit +
There is not yet a front-end (javascript or WebAssembly) framework on the client, i.e. a phone app or webpage, which is stable enough for us to commit effort to (we managed to remove all the jQuery by using recent HTML5 capabilities). Flask looks interesting (but maybe is only simpler when starting a new project and doesn't scale to complexity the way Django does, but maybe in 2025 we diff --git a/handbook/troggle/trogdjango.html b/handbook/troggle/trogdjango.html index 546379ad2..b0a15e422 100644 --- a/handbook/troggle/trogdjango.html +++ b/handbook/troggle/trogdjango.html @@ -35,16 +35,22 @@ note that the suffix on a name ''_set actually denotes a function cal
This may seem overly pedantic and heavyweight, but this is exactly what we need when we are supporting software over decades. When we use software in troggle which is not so well organised, we really feel the pain.
We do not just use our own code and django. We also use django plugins (known as "apps") too. These can do such things as image re-sizing, user authentication with captchas, PayPal processing or mailing list integration. Unfortunately django plugins are volunteer efforts and do not have the same defined update management process as django itself, so release schedules are rather random. They cause merry hell when upgrading troggle to use a new version of django. -
Every extra plugin increases the "vulnerability surface" of troggle with respect to django upgrade problems so we now only install a new plugin if it is really, really necessary and we have removed as many as we could. For example, when django-staticfiles broke during one upgrade we discovered that we could use our own troggle.expopages as a workaround, so we are not planning on reinstalling staticfiles if we don't have to. +
Every extra plugin increases the "vulnerability surface" of troggle with respect to django upgrade problems so we now only install a new +plugin if it is really, really necessary and we have removed as many as we could. For example, when django-staticfiles broke during one upgrade +we discovered that we weren't really using it and could work around it, so we are not planning on reinstalling staticfiles.
Well we might not use django indefinitely, but unlike many frameworks the necessary functions are separately replaceable. So this gives us an evolution path. We can incrementally reduce the amount of django we use, replacing it with our own simpler python that does only what we need. -
The separate functions within the framework form a "stack". These functions exist in all web application frameworks but in Django they are loosely coupled. -
The stack is: +
Well we might not use django indefinitely, but unlike many frameworks the necessary functions are separately +replaceable. So this gives us an evolution path. We can incrementally reduce the amount of django we use, replacing it with our own simpler +python that does only what we need. +
The separate functions within the framework form a "stack". These functions exist in all web application frameworks but in Django they are loosely coupled. +
The stack is:
This page will describe the usual things that go wrong: the parsers that break when faced with user-generated data and how to fix them. Common error messages.
It concentrates on showing how to find and fix import errors so that the troggle-generated webpages are complete and not full of gaps. +
Intended audience: Ideally someone who is not a python programmer will be able to use this page to help them fix import errors by re-editing the input files: survex, tunnel, or logbook. +
Here we will explain the useful diagnostic detailed data pages for finding mis-matched files:
statistics - survey legs and distances for each expo
@@ -24,7 +26,7 @@ fix import errors by re-editing the input files: survex, tunnel, or logbook.
logbook entry - who, where and what
survey_scans - all wallets of scanned surveys and corresponding survex files
per-wallet links - links to scan files and survex files from one wallet
-dwgdata - all the tunnel & therion drawings and the wallets and scanned images they derive from
+dwgfiles - all the tunnel & therion drawings and the wallets and scanned images they derive from
/admin/core/dataissue/ - where the data import errors and warnings are recorded
diff --git a/handbook/troggle/trogindex.html b/handbook/troggle/trogindex.html
index 9b0e58b95..f38a958b0 100644
--- a/handbook/troggle/trogindex.html
+++ b/handbook/troggle/trogindex.html
@@ -13,6 +13,7 @@
Troggle - Introduction - what it is
Troggle - the Users - Who needs to know What and When
+Troggle - Surveys & Caves - Trips, surveys, explorers, sketches, data...
Troggle - Fixing things - users' manuals for data import
Troggle - Maintenance - list of maintenance tasks
Troggle - Architecture - diagrams, files, structure
diff --git a/handbook/troggle/trogkill.html b/handbook/troggle/trogkill.html
index 7e359171a..a11d9913e 100644
--- a/handbook/troggle/trogkill.html
+++ b/handbook/troggle/trogkill.html
@@ -58,6 +58,7 @@ nearly half of it is directly relevant to us: