|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2023-02-18 14:51:19
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk