Julien Blanc wrote:
The API is rather simple. It uses string_view when possible, modern stuff, etc. But I was surprised to see the logic. If I were to implement a templating engine (which is something I've never done, so I may be completely wrong on this), I would first compile the template into an internal memory representation, and then apply that compiled template to different data, reusing the parsing work done (something similar to SQL prepared statements). This approach is somehow also suggested by mustache(5) man page, which tells that partials “are rendered at runtime (as opposed to compile time)”. So, there could be a compile phase. But that's not the case with boost.mustache: everything is rendered at runtime. This is not an issue per-se: it works fine, even when the template is read by blocks (ie, the template is not fully available during the rendering - I guess supporting this use case may have lead to these design decisions).
That is exactly the reason. Since the template is rendered on the fly, without a requirement for it being fully available, it's not possible to construct a parse tree first.
- the json::string whitespace_ . I fail to see why there is a specific handling for leading spaces, and why the parser does not start into state_passthrough. I was wondering also why just counting the spaces was insufficient, but it seems to be related to handling both ' ' and '\t'.
Mustache has the concept of a "standalone tag", a tag that doesn't produce any output and is preceded and followed by whitespace and a newline, and it requires the whitespace surrounding the standalone tag to not be output. Since (long ago) I wrote my own template engine that didn't have this rule I understand why it's useful and how it makes the output prettier, but it's a pain to implement correctly. I have tests that check the official "specification" test cases directly, and all these whitespace_ shenanigans are necessary to make them pass.