catalogsite: first pass #16
Conversation
Containing copious hacks in the "test". Not production-ready. But still I still may want to merge this just to move forward. The exact filesystem layout may be subject to change. This is a rebase of an old prototype (from before warpforge v0.2); the exact filesystem I'd like to use nowaday should more closely mirror the paths of the catalog filesystem projection in JSON, just with different extensions (which is not what we have here). Everything else _also_ subject to change :) There's no styling, etc. Future work includes turning this into a real CLI command; giving it parameters for which catalog(s?) to generate content from; teaching it to render and link up certain pieces of metadata (especially, right now, Replays); and probably a lot more.
warpfork
force-pushed
the
catalogsite
branch
from
e963d3c
to
7c20f31
Compare
It's more or less guaranteed to exist. (Also: exists in CI.)
The idea here being: any time you see something ".html", you can change that to ".json" and get raw data. (If you happened to copy all the raw catalog data into the same directory trees, that is. Which we aren't doing automatically here. But still.)
|
Cool, looks like a great foundation, how would we go about if we'd use styling-files, like for example simple .css files. The html-file would need to know the relative path to it, or we could actually at a generate-step compile the .css file into the `<head>` of the html, which would remove the need to host a .css somewhere locally. What do you think would be a good approach here? |
|
I think just another ... I'll add a stub that does this real quick. |
Just a dummy file, but correctly wired.
|
... done. It's a tad redundant in the html (we could probably use more templating features to make reusable snippets for the header?), but that's more of a polish thing, and keeps it simple for now. |
|
Work will continue in more branches :) Merging the progress so far! |
This PR contains a working checkpoint of a (admittedly still very skeletal) html generator to make a web-navigable view of the data in a catalog.
The overall idea of this is to... well, like I said: make web-navigable thing. The filesystem projection of a catalog into a git repo viewed on github is the next-best-thing we've got so far; I'd like to have something prettier, more fitted to the purpose, and with more crosslinking.
This is still just an outline. It contains copious hacks in the "test". It's not production-ready. It's not even wired up to the CLI yet. Nonetheless, I hoist the PR (and might want to merge it, and keep working iteratively from here, for productivity... I already let it get stale and had to do a big rebase once).
The exact filesystem layout may be subject to change. This is a rebase of an old prototype (from before warpforge v0.2); the exact filesystem I'd like to use nowaday should more closely mirror the paths of the catalog filesystem projection in JSON, just with different extensions (which is not what we have here).Now updated.Everything else also subject to change :) There's no styling, etc.
Future work includes turning this into a real CLI command;
giving it parameters for which catalog(s?) to generate content from;
teaching it to render and link up certain pieces of metadata (especially, right now, Replays);
downstream of rendering Replays, we can crosslink their imports to other parts of the catalog;
and probably a lot more.
(Oh, and in the guts, I'd like to refactor this to use https://github.com/warpfork/go-fsx in the fairly immediate future. Right now, there's an unholy mixture of
fs.FSandos.*because of the lack of stdlib fs interfaces for write operations. The go-fsx repo is intended to address that, but I haven't pulled it in yet. This might end up being addressed as part of #13, though.)