Inja: A Template Engine for Modern C++(github.com)
github.com
Inja: A Template Engine for Modern C++
https://github.com/pantor/inja
31 comments
Who said it's about trusting you?
It's very common for templates to be written by people who are not full developers. The HTML might be written by a designer, email-templates may be written by marketing etc.
By limiting the power of the template language to only data display and simple conditionals and loops, you can those people to write templates far easier and you can let them upload new versions whenever they want with much less worries and you don't have to go through your full code review process just to update an email template.
It's very common for templates to be written by people who are not full developers. The HTML might be written by a designer, email-templates may be written by marketing etc.
By limiting the power of the template language to only data display and simple conditionals and loops, you can those people to write templates far easier and you can let them upload new versions whenever they want with much less worries and you don't have to go through your full code review process just to update an email template.
Well, you can’t trust anyone! :)
Template languages are still languages, and it’s easy for even seasoned developers to make errors that have to be corrected between ‘upload’ and whatever deployment looks like in this scenario. Forget to double-up the closing curly-brackets? Blammo.
I wonder how common it is in practice. Are there existing frameworks or (non-no/low code) CMSes that support that workflow? I.e. letting non-admins modify templates, ‘compiling’ them if necessary, running them over some sample input, and allowing iteration - before potentially breaking things in production?
Limiting the language to avoid having to do a full security audit - that’s a good point.
Template languages are still languages, and it’s easy for even seasoned developers to make errors that have to be corrected between ‘upload’ and whatever deployment looks like in this scenario. Forget to double-up the closing curly-brackets? Blammo.
I wonder how common it is in practice. Are there existing frameworks or (non-no/low code) CMSes that support that workflow? I.e. letting non-admins modify templates, ‘compiling’ them if necessary, running them over some sample input, and allowing iteration - before potentially breaking things in production?
Limiting the language to avoid having to do a full security audit - that’s a good point.
There are many uses for templates, not all of them need you to use advanced language constructs in the template language. Personally, I'd rather have templates be relatively dumb, and use something like {{mustache}} (https://mustache.github.io/).
True, but then why not limit oneself to exactly that subset of the language that one considers non-advanced and relatively dumb, rather than let someone else make that call?
In this specific case supporting the full host language would mean implementing a whole C++ compiler which might be a bit overkill.
I would imagine a preprocessor (not the C++ one) would be used before re-implementing C++. :)
Not having to use one could be a use case, though IMO I don’t know if that’s compelling enough…
Not having to use one could be a use case, though IMO I don’t know if that’s compelling enough…
Syntax for loops and conditionals introducing scopes to your document may work fine for plain text documents, but in my experience it turns structured documents like HTML in unreadable mess very fast. I don't know why it's a de facto standard for template engines to make it this way.
I came up with the idea of attaching conditions and loop specifications directly to XML tags, and in my opinion it significantly improves readability. I couldn't find any alternative with similar syntax, so I've implemented it myself. It's also in C++, although it works as a transpiler, and templates are needed to be compiled. It can be found here: https://github.com/kamchatka-volcano/hypertextcpp
I'm agreeing with everything you said, but still I don't know why it's a defacto standard for template "engines" targetting HTML or other markup to invent ad-hoc syntax rules involving Unix shell-like $s and/or curly-braces and/or dotted paths ;)
When SGML, since the begin of times, has entities/entity references (plus CDATA/RCDATA marked sections) for exactly that purpose. Plus, can actually encode/quote expanded text in a context-dependent way (eg attributes vs elements) and prevent or allow expansion of replacement text into <script> directed by allowed content models, and prevent other injections using HTML-aware templating.
When SGML, since the begin of times, has entities/entity references (plus CDATA/RCDATA marked sections) for exactly that purpose. Plus, can actually encode/quote expanded text in a context-dependent way (eg attributes vs elements) and prevent or allow expansion of replacement text into <script> directed by allowed content models, and prevent other injections using HTML-aware templating.
it's a defacto standard for template "engines" targetting HTML or other markup to invent ad-hoc syntax rule
Totally.
My hypothesis: people enjoy writing templating engines, which is why there are so many. And people especially enjoy inventing their own programming languages.
Templating engines are the perfect place for a web developer to dip their toes as gently as desired into language creation, in a format that’s kind of fun and is also immediately relevant and useful.
Totally.
My hypothesis: people enjoy writing templating engines, which is why there are so many. And people especially enjoy inventing their own programming languages.
Templating engines are the perfect place for a web developer to dip their toes as gently as desired into language creation, in a format that’s kind of fun and is also immediately relevant and useful.
For me this feels like a candidate to build on top of fmt instead of a standalone thing, with a custom formatter wrapping JSON data. I think that direction of extension might still be open, while keeping the current interface for convenience and compatibility.
If you’re in the Qt ecosystem shout out to grantlee which has been around forever.
https://github.com/steveire/grantlee
https://github.com/steveire/grantlee
Anyone using C++ for "standard" web backend dev ? I don't expect there be things as convenient as Django or Rails but maybe there are a few nuggets such as this nice Jinja-like library.
Actually there are, for example https://www.webtoolkit.eu/wt
I use C++ for large web backends because I dislike Typescript. I use Javascript for small web backends. Actually to me, JS feels so close to C++.
I use cppcms most of times but in some cases I use Seastar for high perf.
I use cppcms most of times but in some cases I use Seastar for high perf.
Then there is of course other uses for templates besides web development.
I don’t understand what this adds to C++20’s standard `format`, which you can run in older versions of c++ via the fmtlib library.
Is there a use case I don’t understand?
Is there a use case I don’t understand?
If you go back and re-read the subsection Statements (and perhaps other sections of the README as well), I'm pretty sure you'll find a use case you might have not yet understood.
There is also Boostache:
https://github.com/cierelabs/boostache
https://github.com/cierelabs/boostache
I would have hoped for a typesafe (compile-time checked) template engine for something dubbed "Modern C++".
This thing must fly. Are there any benchmarks?
Is this Unicode?
This is a little confusing because C++ already has an unrelated built-in template concept (including the keyword "template").
In C++ terms this is a library that generates HTML, not a template engine.
In C++ terms this is a library that generates HTML, not a template engine.
I am fine with it “templating engine” has a pretty well defined meaning as a group of words.
If it was called “modern templating for c++” I would agree.
If it was called “modern templating for c++” I would agree.
I will admit I followed the link because I was expecting some kind of lovecraftian template horror, only to discover it was templates in the string sense.
I'm not sure whether I should be disappointed or relieved :D
I'm not sure whether I should be disappointed or relieved :D
To be a bit more precise it's a library that renders strings from a template.
The result may or may not be valid HTML.
The result may or may not be valid HTML.
My thoughts precisely. Maybe it could be renamed to string parser and replacer(?) for C++. SPaRC.
“Template” is a term of art for this sort of thing, but if you’re looking for an alternative, there’s already “macro processor” for things like this. It’s what GNU’s M4 is called, for example. https://en.m.wikipedia.org/wiki/M4_(computer_language)
But - whoops - now you’ve got collision with C++ “macros” - which already has collision with Lisp “macros” and text editor / word processor macros - and “processor” which looks a lot like the C++ “preprocessor” and …
But - whoops - now you’ve got collision with C++ “macros” - which already has collision with Lisp “macros” and text editor / word processor macros - and “processor” which looks a lot like the C++ “preprocessor” and …
Or: what do I gain from intentionally limiting myself to a bespoke language that lacks many of the constructs of the language I’m writing the rest of my project in?
If I can’t be trusted to responsibly and successfully use that full language in templates, how can I be trusted to use it in all the rest of the code base?