render.py is a standalone class for rendering context-aware HTML inside of BriteCore. Making template customization more configurable and easier to modify, its primary purpose is to enable developers to create better Jinja deliverable templates.
Data is gathered inside the Jinja template by exposing quite a few
get_ methods to the Jinja template. It caches the results for speed and generally knows how to handle dependencies. For instance:
get_policy_accounting needs a
revision to function, and this class tries to resolve them in the best possible order based on what was provided to the
policy_accounting instance exists, it is cached and subsequent calls to any related methods will use the cached version moving forward
Having access to model instances and
policy_accounting inside of
jinja exposes some risks to data integrity. To attempt to mitigate these risks, we wrapped the
jinja rendering call in a SQLAlchemy session rollback. This means that none of the helper functions used by the
jinja template can use
execsql, or the session will be committed before it can be rolled back.
We designed tests that mock
execsql and then assert that they aren’t called. Tests should be added as new methods are created. Client developers should also write these tests and tread carefully as they use exposed
policy_accounting methods to make sure that the session isn’t committed accidentally.
In addition to the above, there is a new
HTMLTemplate class in BriteCore that corresponds with an
html_templates table in the database, so HTML templates can be accessed more readily.
To go with the new class/table, a new interface has been designed to edit these templates. We took the opportunity to update our in-browser editor to the Ace editor, which is highly performant, extensible, and maintained.
Exposed methods include:
This list was generated using the
get_available_function_names. It will generate a list of all exposed functions at runtime to allow for easier reference while editing a template.