bluekeyes / templatetree Goto Github PK

The parse functions should options to configure things that are either not currently supported or are mandatory arguments:

• The root template (instead of passing nil)
• Flag to reload and parse on every render request
• Reload trigger channel
• A parse hook
  • Before each leaf template is parsed, call the hook function to modify the template
  • An alternative to a root template for things like defining functions
  • Useful to add a partial function that can render dynamically selected named templates defined in the same text.Template

Go 1.16 introduced the io/fs package and the fs.FS interface. I invented my own version of this in ca13449, but it would be nice to support the official thing now that it's available.

I think this is best implemented by removing the existing File type and parse methods and replacing them with the new fs types, then making a 0.3.0 release that requires Go 1.16 and breaks the API.

When executing a template via ExecuteTemplate errors are reported as coming from the base cloned template. Perform the same error mangling that we do for parse errors on execution.

Coming back to this library to add io/fs support left me with some ideas to change the API:

• Remove File; either use fs.File or take a map[string]string
• Remove Load* functions; everything should be Parse*
• Remove text and HTML variants and find some way to use single types

On the last point, I'm thinking about defining:

type Template interface {
  Name() string
  Execute(io.Writer, interface{}) error
}

type Tree map[string]Template

The concrete types in a Tree would be either text/template.Template or html/template.Template depending on parse options. Internally, I think most things would take a Template and then type assert / cast to concrete types as needed.

The main problem I see is this implies clients could provide their own Template implementations, which would break everything that assumes there are only two standard library implementations.

Because of that, it might make sense to expose something like the currently-internal template interface that defines all necessary methods and use that. This requires an adapter for the standard types because many of the methods return their own type for chaining.