I've used the mail forwarding page as an example, mainly because it is one of the most complex pages in terms of layout. As this is just a prototype, I haven't spent much time on styling the page, but I have:

?

• Used a grid system for layout instead of tables.
• Tweaked the grid settings so that components take up varying amounts of space depending on the screen size.
• Added proper labels to form inputs (important for screen readers).
• Used proper input types (e.g. number instead of text, where appropriate).
• Removed a lot of superfluous tags such as <font> (styling is all handled in CSS).
• Made the main menu collapsible on screens < desktop.

?

Again, this is just a demo, so it doesn't actually function, and there is no JS functionality either at the moment (aside from the main menu).

?

Extract the .zip, open forwarding.html and resize your browser window from very narrow (like a mobile) up to full screen to see the content reflow.

I use ISFILTER m/. Work on map but not in Stations List.

Em qui., 3 de out. de 2024, 19:02, Mark Taylor via <mtaylor=[email protected]> escreveu:

Yes....

?

?ISFilter=m/0 ? ? ? ?; Filter Command if needed
; ISFilter=m/50 u/APBPQ* ? ?; Used in BPQAPRS mapping application as a default to add BPQ nodes wordwide.
; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; Adding this now when there are so many BPQ nodes increases network traffic
? ? ? ? ? ? ? ? ? ? ? ? ? ? ; unnecessarily!

?

There is a full list of filters available on

?

?

Yes....

?

?ISFilter=m/0 ? ? ? ?; Filter Command if needed
; ISFilter=m/50 u/APBPQ* ? ?; Used in BPQAPRS mapping application as a default to add BPQ nodes wordwide.
; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; Adding this now when there are so many BPQ nodes increases network traffic
? ? ? ? ? ? ? ? ? ? ? ? ? ? ; unnecessarily!

?

There is a full list of filters available on

?

?

my apologies.

?

i had a feeling, i couldn't express myself in a way that wouldn't stir the pot.

?

in reply, i see the same thing.

?

i do not see shortcomings where others do.

?

i do not see 'better' in the different where others do.

screen readers, one example, would break whenever something 'better' was introduced.

?

i am old, i understand that.

my masters is from the era of cobol and fortran 77.

?

my hobby was turbo pascal, writing doors for bbs systems.

?

i have no relevance in the actual writing of today's programs but as a user, i wanted to express my desire to keep a 'look and feel' that works for me.

?

again, my apologies, i'm QRT

:)

kb0wlf

_._,_._,_

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.