Posted by Toolforger on Jan 04, 2020; 8:17pm
URL: https://discuss.asciidoctor.org/Injecting-a-directory-listing-tp7445p7471.html

Just a data point as feedback:

I got it to work.
Basically, I'm walking the file tree, pick up the :title: attribute of each .adoc, generate a website ToC from the titles, and push the Asciidoctor output & the ToC through a Mustache template.
If anybody is interested, I'll post it, it's just 95 lines of Ruby code (and it does have a few warts but I don't care too much).

I have a feeling that Asciidoctor it trying to be too many things at once. Which makes for a higher learning curve, makes it a challenge to find out what parts of Asciidoctor one even wants, and makes it harder to properly template everything because it is so easy to put the flexibility in the wrong module (that's a common software architecture issue actually). The end result is that it works perfectly well for those use cases that were pre-conceived, but new people trying to apply it to a new use case tend to get stuck.
I think this could be addressed by splitting Asciidoctor up:
- Parser (input to DOM)
- DOM processors (generate per-page ToC, collect data from multiple files, etc.)
- Backends (HTML4/5, PDF, Docbook, whatever)
- Server (for interactive work/test purposes, would benefit if each stage keeps track of all inputs that went into it, so the server can trigger a reload for exactly those pages that are affected by a change)
FWIW. I'm well aware that such a change would be (a) a ton of work, (b) potentially break stuff, and (c) likely not on top of anybody's agenda (certainly not mine, I am a Ruby noob plus I have my own projects; besides, I can't expect anybody to make my agenda theirs - this is just a suggestion, no hard feelings if the makers of Asciidoctor do not want to do thsi).