Start converting some enum-like strings to proper enums, plus global reformat

docs/docker.md

@@ -23,15 +23,16 @@ You can replace `#main` with any other branch or tag reference, for example `#1.
 
 Save the file. You will still need to create a copy of `config-example.yml` and name it `config.yml`, though with the
 Docker setup nothing has actually been downloaded yet, so you will have to copy the example from the repository some
-other way, e.g. [from the repo in a web browser](https://git.ianrenton.com/ian/spothole/src/branch/main/config-example.yml).
+other way,
+e.g. [from the repo in a web browser](https://git.ianrenton.com/ian/spothole/src/branch/main/config-example.yml).
 
 With that in place, run `docker compose up` and you should be good to go. To detach, press `d` or run the command with
 the `-d` flag.
 
 ### nginx Reverse Proxy with Docker
 
-In a containerised setup, it's typical to run an nginx reverse proxy in one container, alongside certbot for renewal
-of HTTPS certificates, and then applications like Spothole in a separate container. In this case, there are a couple of
+In a containerised setup, it's typical to run an nginx reverse proxy in one container, alongside certbot for renewal of
+HTTPS certificates, and then applications like Spothole in a separate container. In this case, there are a couple of
 variations of the docker compose file above, and the nginx reverse proxy configuration covered [here](./nginx.md), that
 you will want to make.
 
@@ -60,8 +61,8 @@ networks:
 ```
 
 In your nginx site configuration, you'll want to refer to the Spothole container directly, and drop the block that
-allows nginx to access static files directly, as these will be inaccessible in another container. So you may end up
-with something like:
+allows nginx to access static files directly, as these will be inaccessible in another container. So you may end up with
+something like:
 
 ```nginx
 server {
@@ -146,13 +147,13 @@ server {
 ```
 
 If desired, you could even change the port on which Spothole runs from 8080 to a plain 80, in which case your
-`proxy_pass` statements could drop the `:8080` suffix. Since Spothole is in a container, it can serve HTTP on port 80
-if desired, because it doesn't conflict with the host system.
+`proxy_pass` statements could drop the `:8080` suffix. Since Spothole is in a container, it can serve HTTP on port 80 if
+desired, because it doesn't conflict with the host system.
 
 ### Restoring the static files bypass
 
-If you would still like to bypass Spothole's web server for the static files, and serve them with nginx, you can
-do. The easiest way is to run another nginx container to serve the files, so your Spothole `compose.yaml` becomes:
+If you would still like to bypass Spothole's web server for the static files, and serve them with nginx, you can do. The
+easiest way is to run another nginx container to serve the files, so your Spothole `compose.yaml` becomes:
 
 ```yaml
 services:
@@ -183,8 +184,8 @@ networks:
     external: true
 ```
 
-Then you can re-add the block that handles the `/static` path in your nginx reverse proxy config, but this time
-point it at the new container rather than at a filesystem path:
+Then you can re-add the block that handles the `/static` path in your nginx reverse proxy config, but this time point it
+at the new container rather than at a filesystem path:
 
 ```nginx
     # Load static assets from the spothole-static-nginx container

docs/modifying.md

@@ -48,8 +48,8 @@ To navigate your way around the source code, this list may help.
 ### Extending the server
 
 Spothole is designed to be easily extensible. If you want to write your own spot provider, for example, simply add a
-module to the `providers.spot` package containing your class. (Currently, in order to be loaded correctly, the module (
-file) name should be the same as the class name, but lower case.)
+module to the `providers.spot` package containing your class. (Currently, in order to be loaded correctly, the module
+(file) name should be the same as the class name, but lower case.)
 
 Your class should extend "SpotProvider"; if it operates by polling an HTTP Server on a timer, it can instead extend "
 HTTPSpotProvider" where some of the work is done for you.

docs/nginx.md

@@ -2,8 +2,8 @@
 
 Web servers generally serve their pages from port 80. However, it's best not to serve Spothole's web interface directly
 on port 80, as that requires root privileges on a Linux system. It also and prevents us using HTTPS to serve a secure
-site, since Spothole itself doesn't directly support acting as an HTTPS server. The normal solution to this is to use
-a "reverse proxy" setup, where a general web server handles HTTP and HTTP requests (to port 80 & 443 respectively), then
+site, since Spothole itself doesn't directly support acting as an HTTPS server. The normal solution to this is to use a
+"reverse proxy" setup, where a general web server handles HTTP and HTTP requests (to port 80 & 443 respectively), then
 passes on the request to the back-end application (in this case Spothole). nginx is a common choice for this general web
 server.
 
@@ -89,19 +89,14 @@ server {
 ```
 
 One further change you might want to make to the file above is the `add_header Access-Control-Allow-Origin` statements.
-These are what's used on
-my own Spothole server to make sure that other third-party web-based software can get the data from my instance, and
-applies to any endpoint underneath `/api`. If you want
-*your* Spothole instance to be set up the same way, so that others can write software in JavaScript that can access it,
-leave this intact. But if you want your Spothole instance to only be usable by scripts running on the web server you
-write,
-you can remove these lines. (Note that this doesn't stop other people writing *non-web-based* software that accesses
-your
-Spothole API—the enforcement of cross-origin headers only happens within the user's browser. If you need to lock
-your
-instance down so that no-one else can access it with *any* software, that's an aspect of nginx or firewall config that
-you will need
-to find help with elsewhere.)
+These are what's used on my own Spothole server to make sure that other third-party web-based software can get the data
+from my instance, and applies to any endpoint underneath `/api`. If you want *your* Spothole instance to be set up the
+same way, so that others can write software in JavaScript that can access it, leave this intact. But if you want your
+Spothole instance to only be usable by scripts running on the web server you write, you can remove these lines. (Note
+that this doesn't stop other people writing *non-web-based* software that accesses your Spothole API—the
+enforcement of cross-origin headers only happens within the user's browser. If you need to lock your instance down so
+that no-one else can access it with *any* software, that's an aspect of nginx or firewall config that you will need to
+find help with elsewhere.)
 
 Now, make a symbolic link to enable the site: