Support template inheritance from content files

[mayo]

I don't expect this to be accepted, but would like it to instigate a discussion on supporting something similar to this. I think more automation (ie. not having users specify block patterns manually) and testing with different templating libraries (tested only with jade and swig) would be required before this is ready for public consumption. Perhaps consolidate.js -like wrapper for templating libraries that support blocks would help as well.

The base of the idea is that for template languages that support blocks (atpl, dust, ect, Hogan, just, nunjucks, swig and potentially liquor), there is no way to override template blocks from content files without creating dummy content-file specific templates (template file per content file).

The changes cause content files to extend a template (given the proper setup in front-matter) and thus allow overriding of blocks specified in the template. Optionally, the content can also be wrapped in a block itself, giving a bit more flexibility to templating.

Because there is no universal way of specifying blocks, the current implementation expects the user to specify block definition of their templating language of choice (extendsPattern, blockPattern).

If none of the new options are used when setting up the plugin in metalsmith, the plugin works as normal without any side effects. New functionality will be triggered only when useExtends is specified in plugin setup and a content file has an extends keyword in front-matter.

Any flames, blames, ideas or comments are welcome.

[ianstormtaylor]

Hey @mayo thanks for this, I might be getting this wrong, but I think #26 might support this in a more elegant way?

[mayo]

@ianstormtaylor I've forked metalsmith-templates a while ago and did a bit of a rewrite (it's still WIP so not listed on metalsmith.io) to make it work as I like, so no worries :)

To be honest, I never understood the need for inPlace to exist or for splitting the functionality up to two separate plugins. IMHO inPlace should always be true. What is the use case for specifically blocking front matter from being accessed in the templates? Once that functionality is always on, it's simple, easily understood and logical.

And second, all respectable (this is purely personal opinion, I was never a big fan of handlebars) plugin engines (jade, swig, etc) already support template inheritance, so I don't see the need for coming up with yet another implementation of inheritance in templates. Let the template engine handle it, the work's already been done.

That's my $0.00002 on the topic. Either way, I have my fork, and there is -layouts and -inplace, so everyone can choose what works best for them.