Support custom view engines

[hilljh82]

Blueprint uses consolidate.js to integrate many view engines. There are scenarios where a view engine may not be supported by consolidate.js, and there is a need for a custom view engine. See isssue #29 for an example.

To address this problem, we need to support custom view engines in Blueprint. This custom view engines should be defined in app.config.js.

[bdfoster]

If specifying a view engine, should blueprint assume this is the only view engine available (i.e. by not relying on consolidate.js to try and resolve the view)?

[hilljh82]

Blueprint does not assume there is a single view engine. Instead, Blueprint adds support for each view engine based on the extensions it finds when copying the views into app/temp/views. The copying occurs to handle situations where modules define a view since Express only supports one view folder. You can set a default view engine to use, which is used when you do not provide a extension on a view passed to the render() method.

The way this approach would work is Blueprint will use consolidate for all view engine types. The user can override a view engine by defining the engines property.

[bdfoster]

Understood. I saw bits of how consolidate.js is used in Server.js, which brings up a point:

Consolidate.js does have the ability to take parameters, which actually would solve part of #29. One of the parameters it takes is 'partials', which is pushed to the render method of a particular library. It also takes 'helpers', and both are used in several view engines.

Related: https://github.com/tj/consolidate.js/issues/222

The ability to pass configuration options to consolidate.js may help others not have to resort to configuring a particular view engine from scratch, although this functionality should probably be addressed in another ticket.