Add ability for Selleck to use a custom Handlebars object

[gotwarlost]

This is take 2 of my original pull request that allowed for handlebars helpers to be tacked on to the Handlebars object.

#9

There were multiple problems with that approach, mostly because the Handlebars object is global and cannot be overridden per-component, the semantics of loading a custom config that could itself require dependencies was hairy and so on.

This PR inverts the model and allows the user to pass in --handlebars <path> option. path is then require-ed in selleck and used to update the Handlebars object in place, early before any rendering is done.

Thus, as long as the module provides an object that is compatible to Handlebars, it will work seamlessly and the user now has the option to associate all sorts of helpers applied at a "system" level.

The advantages of this approach are:

• Selleck no longer has to deal with custom config etc. but uses a replacement handlebars instead.
• The user can go crazy with handlebars helpers in terms of have a custom module with all sorts of dependencies for the helpers without having to make those dependencies known to selleck. In a sample that I'm currently using I use handlebars helpers for JSON rendering, markdown to HTML transformation etc. My custom module encapsulates all this logic (using node-markdown dependencies etc.) without touching selleck in any way.

There is now an implicit coupling between the markup in the docs and the helpers needed to render them but this is treated as user problem and not a selleck problem.

If you guys like this approach, I will move forward and add tests and such otherwise I'll just keep building my docs out of my fork :)

[stjohnjohnson]

Any update on this? I'd love to use it.

[stjohnjohnson]

Nudge

[caridy]

Hmm, this sounds like a weird solution. We could simply start using NPM to install a handlebar dependency, which is flexible enough, and it does allow you to do AOP on require('handlebars') in case you want to do crazy stuff.