Hi John,

?

Thanks for the explanation. While I know HTML, CSS, and JS intimately, C is above my pay grade! That does put a small spanner in the works as I was hoping to be able to do this without too much work for you, by simply editing the templates. Spitballing some potential approaches:

?

1. Modify the existing template strings in the C source code. This seems like it would be very awkward - having the HTML and C code mixed together seems like a recipe for a lot of headaches.
2. Go back to having the HTML in separate files. The C code would load the template from disk, all the data could simply be printed into an object in a script tag, then assembled into the page using Handlebars (on the client). This would avoid having to do the string replacement in C, which I imagine is quite fragile. You can see a basic example of how this would work . Handlebars also has a concept called "Partials", so things like the main menu can be written once, then reused on multiple pages. You would also get proper syntax highlighting and formatting in your editor, rather than just bunched up strings.
3. Leave everything as is, and build a new REST API. Provide endpoints such as /api/main-config and /api/node-list which return a JSON object containing the data, which can then be used by any kind of custom front end. This would be very versatile, especially for things like the node list and link status, as it could also be used in scripting, not just in a web front end. I would probably build a separate program using NodeJS that provides a custom front end, but others could do something similar using PHP, Python, or any other language. I'm sure other people would appreciate being able to get at this data for use in monitoring scripts, Discord bots, or other innovative things like that.
4. Use to create a hybrid approach. This would involve creating new endpoints that return small chunks of HTML, rather than whole pages (e.g. /api/main-config would return just the form). This means the chunks could remain in the C code (although it would be easier to manage them in dedicated files) and use most of your existing logic.
5. "Gaffer tape" scraper. Add a single JS file that essentially scraped the data out of the existing compiled HTML (as it's delivered to the client), and then rebuilt the page using this data. This would mean no extra work on your part at all, but would be a bit more fragile if you did change anything, and isn't a very efficient way of doing things.

I think my personal preference of order would be 3, 2, 4, 5, 1. As I mentioned, a REST API would be very versatile for all sorts of uses, not just the web front end. Each approach has it's pros and cons, and would involve varying amounts of work for you, so I would be interested to hear your thoughts.