Closed heaths closed 1 year ago
@heaths Allowing the template
package to be extendable sounds like a good idea to me. I am thinking something like:
func (t *Template) RegisterFunc(name string, f func(fields ...interface{}) (string, error)) error
Where the RegisterFunc
would add the new function to t.templateFuncs
which is not stored on the Template
struct yet, but could be added there. What do you think?
This could even be used to override default template functions if we want to allow that behavior.
Go stdlib already supports templating with extensible functions in its text/template
package. Why would we replicate that functionality?
The reason why we've publicized our pkg/template
is to give extension authors access to the --template
functionality from CLI. But if other kind of functionality is needed, one that doesn't exist in --template
, my suggestion for extension authors would be just to drop down to stdlib text/template
.
The point would be to get all the functions that CLI already defines for use in extensions. That's what I had to do with one of my extensions because I can't add some others. Overriding a function isn't really a major goal, but figured "just in case".
It'd be great if we could add more functions to the
template
package, perhaps using the "WithOptions" pattern as mentioned elsewhere. The existing templates are useful, but for extensions to add other useful helpers for their own needs, passing in a map to merge after initializing the default list (so extensions could override) could prove useful.