expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2024-11-22 07:11:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Front-end speculations

Browse Source
This commit is contained in:
Philip Sargent 2023-02-08 23:36:35 +00:00
parent cba1997180
commit 069609e814
6 changed files with 38 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
handbook/survey/newwallet.html
View File

@ -276,6 +276,9 @@ e.g. for 2018#16 it would be:
</pre>
in the same way as you do scanned notes or scanned survey sketches. (We used to use a different naming scheme for non-physical wallets, but that turned out to be both confusing and not necessary.)
<h4>Sub-folders and other problems</h4>
<p>Troggle scan upload does not allow you to create subfolders for scans or topo files. Either put all your files into one folder, and upload them from there, or find a nerd with a <var>basic laptop</var> who can interact directly with the version control system. Or email them to a nerd as below.
<p>If you are not in the potato hut and your screen is too small to use the upload form then email all the .topo files
to a friendly nerd (not necessarily on expo) who will upload them in the right place.

BIN
handbook/t/pyodide-logo.webp Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.2 KiB

4
handbook/troggle/pyodide-logo.webp:Zone.Identifier Normal file
View File

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

8
handbook/troggle/serverconfig.html
View File

@ -78,7 +78,13 @@ See the live report on which urls resolve to which actual folders at <a href="/p
</ul>
<b> * These are essential</b> to make troggle work at all.
<p>You will also need everythingto run Django, as documented in <a href="/handbook/troggle/troglaptop.html">troggle laptop</a> including all the python modules listed there and installed using pip.
<hr />
<p><b>Now, if you don't know</b> your <em>wsgi</em> from your <em>asgi</em>, read <a href=
"https://james.walters.click/what-django-deployment-is-really-about.html">this article
</a> first on how to generically configure a Django server in the simplest possible
way.
<hr />
<p>The server configuration scripts are in the file <var>troggle/debian/serversetup</var> and are also
documented with notes in <var>troggle/README.txt</var>. It is intended that the full documentation will
be copied here in due course.

2
handbook/troggle/trogindex.html
View File

@ -22,7 +22,7 @@
<a href="trogdesign.html">Troggle - What it does Badly</a> - Design Decisions for the Future<br>
<ul>
<li><a href="trogregistr.html">Troggle Login and user registration</a> - proposal to remove registration (DONE)<br>
<li><a href="lbredesign.html">Troggle Logbook Format Redesign</a> - options for revising the logbook HTML format<br>
<li><a href="lbredesign.html">Troggle Logbook Format Redesign</a> - revising the logbook HTML (DONE)<br>
<li><a href="menudesign.html">Troggle Menu Design</a> - options for replacing the menuing system<br><br>
<li><a href="namesredesign.html">Troggle people's names' redesign</a>
<li><a href="trogsimpler.html">Troggle - a kinder simpler troggle?</a> - Radost's proposals (critiqued)<br>

32
handbook/troggle/trogspeculate.html
View File

@ -7,6 +7,7 @@
</head>
<body>
<style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
<style>figure {font-weight: bold; font-size: small; font-family: sans-serif;font-variant-caps: small-caps;}</style>
<h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>Troggle Architecture Speculations</h1>
@ -49,6 +50,12 @@ 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>
<div class="onright">
<figure >
<a href="https://pyodide.org/en/stable/"><img width=150 src="../t/pyodide-logo.webp"></a>
<br><figcaption></figcaption>
</figure>
</div>
<a href="https://github.com/brython-dev/brython">github.com/brython-dev/brython</a> &nbsp; &nbsp;
<a href="https://www.brython.info/">www.brython.info</a>,<br>
<a href="https://pyodide.org/en/stable/">Pyodide</a> - full browser using webassembly (2021) and <br>
@ -61,11 +68,20 @@ Which is fun, but not useful. And not just because it may be immature. None of
this addresses <strong>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</strong>.
<h4>Front-ends update</h4>
<p>Three years later (re above) and there is still no sign of stability in front-end
frameworks. There are now some Python frameworks, so maybe one of these will give us
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].
<h3>Our biggest problem</h3>
We need:
<ul>
<li>something that can be maintained by fewer, less-expert people
<li>who can only devote short snippets of time
<li>something that can be maintained by <figure>fewer, less-expert people</figure>
<li>who can only devote <figure>short snippets of time</figure>
<li>without requiring weeks of long-duration deep immersion
</ul>
@ -78,10 +94,7 @@ model that everything must understand</strong> - 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]
an update that would be nice. It's on my <a href="../computing/todo.html">to-do list..</a>]
<p>
<h3>troggle now</h3>
Troggle is very nearly fully working (not with as many functions as
@ -128,13 +141,14 @@ the NHS digital service</a> and Firefox.
<h3 =id="mud">* Later Note on object dependencies</h3>
<!-- Philip Sargent 29 July 2020 -->
<a href="http://picocontainer.com/inversion-of-control-history.html#timelines">
<img class="onright" src ="../computing/ioc-timeline.png" width="200px"></a>
<p>Currently every troggle code operation uses the django ORM <var>search</var> and <var>filter</var> operations on the central database to find any object it needs. If we don't have a central database then we have to use direct object references and we need to think about the design of <a href="https://medium.com/@geoffreykoh/implementing-the-factory-pattern-via-dynamic-registry-and-python-decorators-479fc1537bbe">a central registry object</a> to hold these. There is a well-studied design pattern that describes this design "<a href="http://www.laputan.org/mud/">Big Ball of Mud</a>" which and the contributing actions "Piecemeal growth" and "Sweeping it under the rug".
<p>We are always using one object, e.g. a wallet, just to get at another object, e.g. a scan of some original notes, in order to check the data we are checking, e.g. a survex file. Maintaining two-way dependencies amoung all the objects is what "foreign keys" do in a database, but the problem doesn't go away when we don't have a database: it gets slightly harder. <p>One thing that is easier with troggle is that we don't have many object lifecycle issues. Everything is created once and lasts forever. There are only a few ephemeral objects during the initial data import from files.
<h4>Wiring-up components</h4>
<p>Troggle today doesn't need anything complex, a single <a href="https://hub.packtpub.com/python-design-patterns-depth-singleton-pattern/">registry
singleton</a> would probably be fine (though hard to test), but if it evolves towards being a set of interacting services then a more sophisticated architecture would be needed.
singleton</a> would probably be fine for single-user (though hard to test), but we would need to find a reliable long-term library for the multi-user system we need. And even then, if troggle evolves towards being a set of interacting services then a more sophisticated architecture would be needed.
<a href="http://picocontainer.com/inversion-of-control-history.html#timelines">
<img class="onright" src ="../computing/ioc-timeline.png" width="200px"></a>
<p>The Java community found "dependency resolution" very helpful for wiring-up loosely objects/components in the late 1990s with the "<a href="http://picocontainer.com/inversion-of-control.html">Inversion of Control</a>" technique which can be implemented in several ways, most commonly using "<a href="https://martinfowler.com/articles/injection.html">Dependency Injection</a>". But for troggle we must be careful that doing this the "right" way may make the code even more inaccessible to novice caver-programmers than django is. Which is the whole point of moving away from django. Fortunately python programmers have produced some recent guidance: <a href="https://blog.benpri.me/blog/2020/05/13/python-dependency-injection-made-simple/">Python Dependency Injection Made Simple</a> and <a href="https://python-dependency-injector.ets-labs.org/introduction/di_in_python.html">Dependency injection and inversion of control in Python</a>. We should probably use the simpler "<a href="http://picocontainer.com/constructor-injection.html">Constructor Injection</a>" variation as we need to make all our code <a href="http://picocontainer.com/mock-objects.html">more easily testable</a>. Flask uses that.
<hr />