expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2026-02-26 06:05:20 +00:00
Code Issues Packages Projects Releases Wiki Activity

grey banner and lots of to-do fixes, to do items all updated from scribbled notes on printout

Browse Source
This commit is contained in:
Philip Sargent
2020-04-22 19:37:10 +01:00
parent dcd2711ddb
commit 25f9430fac
31 changed files with 1828 additions and 421 deletions
Download Patch File Download Diff File Expand all files Collapse all files

94
handbook/troggle/trogdesignx.html Normal file
View File

@@ -0,0 +1,94 @@
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Handbook Troggle Architecture Speculations</title>
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
</head>
<body><style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
<h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>Troggle Architecture Speculations</h1>
<pre>
From: Philip Sargent (Gmail) [mailto:philip.sargent@gmail.com]
Sent: 19 April 2020 01:28
To: expo-tech@lists.wookware.org
Subject: vague thoughts about future troggle architecture
</pre>
<p>
At our last virtual pub Sam confirmed that using today's tools to
re-partition troggle with all the user interface in the user's browser would
be utterly horrible using current tools (javascript frameworks: react,
angular etc.).
<p>
These frameworks get out of date in couple of years or so. So they don't
give us the decade-long stability we need to match available maintenance
effort.
<p>
A web API to expose the troggle database (read-only) would allow some keen
person to write a special-purpose app on a phone, e.g. an entrance-locator
app, talking directly to the database. But replacing the whole user
interface does not seem feasible yet.
<p>
It did occur to me that we are missing a trick: 99+% of the database doesn't
change except for survey data updates which, apart from during expo, happen
only every week or so. And the database is only 10 MB so is entirely
feasible to copy absolutely everything into the browser except for scanned
images and photos.
<p>
So we could partition troggle so that all the user display bits run in the
browser (or a progressive web app) using a python interpreter running in
javascript. [yeah, expofiles would need some subset labelled as needing to
be forcibly downloaded, but the rest coming only on demand.] Some django
enthusiast must have done this already surely ? Ah yes, Brython.<br>
<a href="https://github.com/brython-dev/brython">github.com/brython-dev/brython</a><br>
<a href="https://www.brython.info/">www.brython.info</a>
<p>
Which is fun, but not useful. And not just because it is immature. None of
this addresses our biggest problem: devising something that can be
maintained by fewer, less-expert people who can only devote short snippets
of time and not long-duration immersion.
<p>
I know Wookey has been thinking of a loose federation of independent scripts
working on the same data, but the more I look at troggle and the tasks it
does the less I feel that would work. At the core there is a common data
model that everything must understand - and the only unambiguous way of
presenting that data model is working code, e.g. see
<a href="http://expo.survex.com/handbook/troggle/trogarch.html">Troggle architecture</a> and click on the image
to see a bigger copy. [It is out of date - if someone can quickly generate
an update that would be nice. It's on my <a href="../computing/todo.html">to-do list..</a>] Much of what
wallets.py does (originally by Martin Green) is in troggle already - but
better. [There is a many:many relationship between svx files and wallet
directories in reality, not 1:1]
<p>
Troggle is very nearly fully working (not with as many functions as
originally envisaged admittedly) but very nearly. There are several
import/parsers which are aborting without producing error messages, so most
of the survey blocks don't get loaded where they actually get displayed, and
the surveyscan images only appear as filename strings which are not checked
for referential integrity, so we are missing a consistency check there, and
the QM data display needs writing; but other than that it's in pretty good
shape. [Ah, yes, we should really add "drawings" as a core concept as well
as "surveyscans". That will be a bit of work.]
<p>
The one thing external scripts would be really useful for is syntax checking
and reference checking prior to import. I have found some weird and
wonderful filename paths inside the tunnel and therion drawings, and in
survex *ref paths.
<p>
<h3>Addendum</h3>
<p>There is a templating engine <a href="https://mozilla.github.io/nunjucks/">Nunjucks</a>
which is a port to JavaScript of the Django templating system we use
(via <a href="https://palletsprojects.com/p/jinja/">Jinja</a> - these are the same people who do Flask). This would be an obvious thing to use if we needed to go in that direction.
<p>Several organisations have moved their user-interface layer to the browser using
Nunjucks including <a href="https://service-manual.nhs.uk/design-system/prototyping">
the NHS digital service</a> and Firefox.
<hr />
Go on to: <a href="trogarch.html">Troggle architecture</a><br />
Return to: <a href="trogintro.html">Troggle intro</a><br />
<hr />
</body>
</html>