Closed gre9ory closed 3 months ago
Instead of implementation heavy adding of new prefixes etc. to _HT*
paths, this is now possible by simply using _HT*
references inside _HT!
and _HT?
templating code.
So for example instead of using this expression:
NotifierUrl: _HT!{{ default "" (index . "$").Values.hull.config.general.data.endpoints.vidieditor.uri.notifier | trimSuffix "/" }}
you can alternatively now use:
NotifierUrl: _HT!{{ default "" _HT*hull.config.general.data.endpoints.vidieditor.uri.notifier | trimSuffix "/" }}
or even shorter for single templating operations with _HT!*
:
NotifierUrl: _HT!* default "" _HT*hull.config.general.data.endpoints.vidieditor.uri.notifier | trimSuffix "/"
Technically, the detected _HT*
references are expanded to a Go templateting reference before tpl
evaluation. For example. the above used reference
_HT*hull.config.general.data.endpoints.vidieditor.uri.notifier
becomes
(index (index (index (index (index (index (index (index (index . "$").Values "hull") "config") "general") "data") "endpoints") "vidieditor") "uri") "notifier")
before template evaluation.
In summary, this solution preserves all degrees of freedom for working with templating expressions while only adding a minimal typing overhead to any solution based on extending the _HT*
capabilities.
Available starting with Releases:
State
At the moment it is possbile to prefix get transformations
_HT*
with serialization instructions to get string representations of dictionaries and arrays. Allowed prefixes are:toJson
toRawJson
toPrettyJson
toYaml
toString
Feature Idea
Extend prefix usage to include more standard operations on single values (without additional arguments). Possibilites:
lower
,upper
,title
,untitle
, ... for stringsint
,float64
, ... for numbersFull list of possible prefixes/functions is here
Future:
Maybe extend to functions with additional arguments but that may stand in contradiction to the idea that
_HT*
should be simple and easy to use?