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

bad urls fixed using online forms

Browse Source
This commit is contained in:
Philip Sargent
2021-04-05 00:27:24 +01:00
parent 51f0450df5
commit bf13a4b743
9 changed files with 52 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
handbook/troggle/trog2030.html
View File

@@ -59,7 +59,14 @@ Documentation is the key to keeping troggle in a state where someone can pick it
<p>
New functionality: e.g. making the whole thing GIS-centric is a possibility.
A GIS db could make a lot of sense. Not in scope for this discussion.
<p>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 effort to. Bits of troggle use very old jQuery ("edit this page", and the svx file editor) , and Flask looks interesting, but maybe in 2025 we could see a good way to move all the user interface to the client and just have an API on the server.
<p>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
effort to. Bits of troggle use very old jQuery ("edit this page", and the svx file editor) , and Flask looks interesting
(but <a href="https://adamj.eu/tech/2019/04/03/django-versus-flask-with-single-file-applications/">maybe is only simpler when
starting a new project and doesn't scale to complexity</a> the way Django does, but maybe in 2025 we
could see a good way to move all the user interface (rewritten to be GIS-centric) to the client
(re-written in <a href="https://www.educba.com/typescript-vs-dart/">Typescript
or Dart</a>) and just have an API on the server. [We already have a proof of principle JSON export API working at
<a href="http://expo.survex.com/api/expeditions_json">expo.survex.com/api/expeditions_json</a>.]
<h3>API</h3>
<p>We will also need an API now-ish, whatever we do, so that keen kids can write their own special-purpose front-ends using new cool toys. Which will keep them out of our hair. We can do this easily with Django templates that generate JSON, which is <a href="https://www.cuyc.org.uk/committee/events_json_short/">what CUYC do</a>
@@ -69,8 +76,7 @@ A GIS db could make a lot of sense. Not in scope for this discussion.
<p>
So a useful goal, I think, is to make 'troggle2' accessible to a generic python programmer with no specialist skills in any databases or frameworks. Put against that is the argument that that might double the volume of code to be maintained, which would be worse. Nevertheless, an aim to keep in mind.
But even 'just Python' is not that easy. Python is a much bigger language now than it used to be, with some esoteric corners. (Some of which could be very useful, such as the self-testing unit test
capability: <a href="https://docs.python.org/3.8/library/doctest.html">docs.python.org/3.8/library/doctest</a> )
But even 'just Python' is not that easy. Python is a much bigger language now than it used to be, with some esoteric corners.