Blog post artifacts.
We need a way to generate blog posts in a semantic directory structure based upon a "database" of blog post source files. (See how Jekyll handles blog posts for example.)
The original thinking was to store block posts in the form YYYY-MM-DD-slug.* in the src/blog/foo/bar directory, which would automatically create a BlogMummifier somehow, which would generate target/site/foo/bar/YYYY/MM-DD with the directory entries, along with some landing page that would pull in teasers from the blog pages. But after some thinking, it may be better to disconnect these two capabilities.
Instead we will give a normal directory mummifier the capability to recognize source files in the form @YYYY-MM-DD-slug.* (note the @ at the beginning) as representing a "post" artifact, a type of page artifact. Rather than placing the posts in some separate src/blog/foo/bar directory, they could be placed in the main src/site/ tree at any level (in a directory using a DirectoryMummifier, that is). The target file would automatically be determined as ./YYYY/MM/DD/slug.html.
This would allow extreme flexibility. The @ filename prefix would be analogous to the . and _ prefixes we already recognize, and shouldn't cause many conflicts with existing files.
The actual "blog widget" would be a separate piece of functionality (built with another ticket) which could be embedded in any page or template, and would at mummification time iterate the child artifacts of type PostArtifact and generate HTML for them.
In the future it will be important to know the exact instant of publication, as multiple things may be published during the day. We may want to allow a separate publishedAt property (see ), which may be set manually or perhaps even allow additional timestamp-related information in the filename (although that might be a little unwieldy).
Some interesting issues arise with this design. First is the question of whether the YYYY/MM/DD/ directory structure would be considered "navigable", as they are not veiled. But as they are generated and do not appear in the source, perhaps they are implicitly veiled. Or perhaps not.
The other issue is whether the generated artifacts would be considered direct children of the directory. We haven't had a case where direct children have different levels. It would be interesting, but there may not be anything inherently preventing it.
We might see how far we get with the following approach:
Considering the PostArtifact instances as direct children of the target directory, even though they generate various sublevels. (This will probably require adding some extra directory creation code.)
Considering the generated child directory structure to be implicitly veiled. This means that one would need some sort of blog component to know that the subdirectories even existed, but maybe this is desired.
The other aspect to consider is that this approach would probably not generate phantom index files at each level—because in fact there would not be actual DirectoryArtifact children for the levels in the tree! It remains to be seen if this would be a problem.