Closed WardCunningham closed 4 years ago
This commit adds a first pass at support for meta-pages. Our index.ts is much smaller with this refactor. To explore the bounds a bit, I moved as much as I could to be a meta-page (even for a couple system urls which are not technically pages).
This commit adds a first pass at meta-sites.
There's a base Site
class which provides the core of what is needed to serve a site. The current implementation serves two sites.
One is served when going to localhost:8000
. This one serves all of the meta pages from ./meta-pages
.
The other is served when going to du.rog:8000
. This one serves an updated version of the du
functionality. This updated version uses base32 encoding to get around the slug character limitations. It has the downside of slugs not being human readable. This version can browse multiple levels into a directory structure.
The work in place has exceeded the vision in this issue. Time to close this and think even bigger thoughts.
Consider Meta-Pages that are defined by dynamically loaded modules and invoked when the meta-page json is requested of the server. The complement of available meta-pages will be exposed as a sitemap where the synopsis is gathered from selective loading of module exports.
Consider Meta-Sites that are defined by dynamically loaded modules and invoked for all page json requests to a subdomain reflecting the module's file name. Meta-Sites have the freedom to expose as few or as many pages as they see fit in a sitemap. Convention dictates that they provide a welcome-visitors page.
The protocol by which the server inspects and delegates responsibilities to meta objects will specifically not be defined so that various alternatives can be explored.
The server can launch from a directory with subdirectories meta-pages and/or meta-sites where modules can be found. Alternatively parameters --meta-pages and --meta-sites can specify alternative locations.