2.0 Planning

As a celebration of Handlebars.Net’s millionth installation, it seems like a good time for:

Handlebars.Net Version 2.0 🎉

This thread will be to discuss what goes into 2.0. Really appreciate everyone’s involvement, even if it’s just bringing your experience and input to the table.

Call for Input

So far, here’s the changes being considered (in no particular order): As consensus develops in this thread, approved items will get a [x] to indicate they’re officially part of the 2.0 roadmap. Please review, comment, and add your own:

• Make all the function names match handlebars.js (for example, changing RegisterTemplate to RegisterPartial)
• Be able to return a value from a helper (and generally restructure the helper delegates to be more js-esque) (see #264)
• Support more advanced helper construction (see #151)
• Add a Compile<ExpectedModelType>() overload for performance optimization
• Support for decorators (see #137)
• Support the as |alias| syntax for enumerators (see #301)
• Refactor the compiler so it can provide line numbers of errors and syntax hints (see #156, #314)
• Remove the built-in filesystem based templating extension, but ensure we have a good extensibility model so it can still be added as an external plugin
• Support noEscape (see #276)

Special thanks

to @mcintyre321, @Magentaize, @dejx, @amaclean, @vzwick, @axelheer, @sandorfr, @leniency, @pmccloghrylaing, @mikeprince3, @StefH, @huysentruitw, @abraham-fox, @ondrejtomcik, @mohd-akram, @EBMike, @JvanderStad, @katavasha, @Andrew-Hanlon, @nblumhardt, @crra, @esskar, and the many others who’ve helped make this library useful to people all over the world in the last 5 years!

[oformaniuk]

Release 2.0.0 is out.

[rjendoubi]

Retaining unsolved expressions for later evaluation would be really useful. I hope you consider implementing this as an option.

I’d like to second this and present another use-case.

We have an interface which allows our users to create bespoke Reports, each of which can contain an arbitrary number of queries to our database, and output the results of those queries to a number of templates of different formats: CSV, Excel, and an HTML format facilitated by Handlebars.NET.

Because we don’t know how many searches our users will include, we can’t presume to hold all the results in memory and insert into the output template in one shot. What we’d prefer to do, which we do for the other output formats, is run the search, insert the needed values into the template (which is stored on disk), and then throw away the results and move on to the next one.

I appreciate the challenge has already been issued on the SO question to send a PR 🙂 If it’s agreed this would be a desirable feature (that on the face of it wouldn’t necessarily kill performance), can it be added to the roadmap?