Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Porting any wanted API additions in Raise #7
Quick heads up, I've pulled my site's generation code out into its own project, Raise. It uses a number of enhancements from this repo, but provides a wrapper around AsciiDoctor with a few additions.
Many of the API additions I'm supporting will probably end up not making sense in the core AsciiDoctor template system (many of them are unrelated to templates anyway). A few of them might make sense for me to rip out and submit as pull requests here.
A few things I either support now or am planning to support in the future that could be relevant:
And then some miscellaneous stuff that likely is not worth porting: renaming pages (
Great work you did with Raise, Dan!
This was referenced
Apr 6, 2018
Yep, this is exactly what I'm doing - build the document tree, pull out the attributes, throw away and regenerate the tree. It's pretty hacky.
Also agreed on CSS compilation being a separate scope, I only brought it up because I suspect that AsciiDoctor's built in compiler is in the same state as their template engine was: works in Ruby, not in JS. Definitely a separate effort, but if I start to work on something like that I'll probably try to mirror the same strategy you set up for templates.
I agree with you for the most part on separating presentation and content, but it's also really useful for site generation to have attributes bundled closely to the source of a page. I need to keep thinking about how linking works, I suspect there's a cleaner, more generic way to do stuff like this that won't railroad people into only supporting HTML.
I suppose what I'm actually looking for is a way to designate a role for a document. A blog post is likely going through a separate template from a homepage. With
It's quite possible that AsciiDoctor already supports something like that, sometimes I miss a feature and get surprised by it later. Also (likely) outside the scope of the templating engine itself, but I'll keep thinking about it.
That's mostly how I handle things myself. But my workflow is slightly different since for the website I pre-process all documents as embedded HTML. But I attach a custom "category" attribute in the document header which is used by the web server to identify at runtime in which page template the embedded HTML should fit. This is a kind of hybrid static/dynamic architecture.
But indeed, that would be an improvement if we could somehow choose the "right" set of templates while processing the document.
XSLT has the notion of mode. Maybe we could leverage something similar. So, in the document template (or any other one BTW), you could change the current mode based on a document attribute or anything else and then, for processing subsequent elements, only templates corresponding to that mode would be considered, until you eventually change mode again.