I had the idea early on to adapt jinja2, so that we can use its syntax, and the main thing we'd have to do is change how include and block (and probably some more logic) work.
A first (simple) step would be to change the tag syntax to conform to jinja2 (we can add backwards-compatibility, so that we don't need to rewrite all the templates right away – deprecation warnings can be bubbled up similar to failed_tags). Then, whether or not we switch the backend over, the frontend will remain the same.
Some Jinja2 benefits:
- For-loops and if-statements for controlling output (e.g. if no quality issue, don't print failures...)
Some possible hiccups:
- Sub-templates build the context by querying the database. As I understand, Jinja2 passes in a context to the main template. We might be able to carry over our approach, but I don't know yet.
The current system (post-refactor) is pretty good, code-wise. We should only progress this issue if we need new features that might be quicker and easier to implement via Jinja2.
I had the idea early on to adapt jinja2, so that we can use its syntax, and the main thing we'd have to do is change how
includeandblock(and probably some more logic) work.A first (simple) step would be to change the tag syntax to conform to jinja2 (we can add backwards-compatibility, so that we don't need to rewrite all the templates right away – deprecation warnings can be bubbled up similar to
failed_tags). Then, whether or not we switch the backend over, the frontend will remain the same.Some Jinja2 benefits:
Some possible hiccups:
The current system (post-refactor) is pretty good, code-wise. We should only progress this issue if we need new features that might be quicker and easier to implement via Jinja2.