Tradeoffs between handlebars partials and `get` helper stink

[mkantor]

Currently the get helper and handlebars partial syntax ({{> blah}}) serve similar purposes (including content from other files), but they don't fully overlap:

• Both can embed content from other templates.
• The get helper can also embed content from executables or static files, but partials can't.
• Handlebars partials can pass parameters and/or a block to included templates, but get can't.
• get is passed a route, but partial syntax uses filesystem paths ({{get "/foo/bar"}} vs {{> foo/bar.html.hbs}}).
• Handlebars partials have the concept of an "inline partial", and there's no analogue for get.

This is confusing and annoying. It would be great to eliminate these tradeoffs so that you don't need to think about when to use each one, either by combining them or making one a superset of the other.

[mkantor]

I'm betting the easiest approach here will be to enhance get to make it able to do a superset of what partials can do.

Last time I checked the handlebars-rust library didn't provide an easy to way to extend built in functionality like >. Even if I could do that it'd make templates less portable.

[mkantor]

Steps to enhance the get helper so its behavior is a superset of what partials can do:

• Accept a block, set @partial-block for the included file if it's a template
• Accept hash parameters (merged with Operator's default context) (Enhance get helper to support hash parameters. #83)
• Accept a custom context object (Enhance get helper to accept a custom context object. #87)
• Handle "routes" that are raw filesystem paths (relative to the content directory root)
• If possible, handle "routes" that are names of inline partials