Given a collection of html/templates and a collection of text/templates that are read at program start
package main
import (
"fmt"
ht "html/template"
tt "text/template"
)
func ttNames(a []*tt.Template) []string {
names := make([]string, len(a))
for p := range a {
names[p] = a[p].Name()
}
return names
}
func htNames(a []*ht.Template) []string {
names := make([]string, len(a))
for p := range a {
names[p] = a[p].Name()
}
return names
}
func main() {
html := ht.Must(ht.New("html").ParseGlob("page/*"))
cmds := tt.Must(tt.New("cmds").ParseGlob("command/*"))
fmt.Print(ttNames(cmds.Templates()))
fmt.Print(htNames(html.Templates()))
}
where the page and command contain one template file “test” each, I get
[test][test html]
as output. So html.Templates() returned the root template “html”, while the cmds.Templates() did not.
I can handle this, but it feels strange somehow. Shouldn’t a html/template Template.Templates() call behave the same as text/template Template.Templates()?
As I wrote, I first thought of a similar approach, handling html/template and text/template through a custom abstraction of the defined template functions. But in the end I found that it is better to keep the handling split as the packages and types are.
But still the Templates() return asymmetry does not feel natural and is error prone, though documented.
BTW: It’s after midnight over here - so whatever You link to … I’ll read later.
Just, IMHO it cannot be a bug. Why? 'cause @rsc himself keeps re-iterating the intended equivalency of the API’s, (and very carefully details the differences, such as the default-set of TemplateFuncs …
BTW: I’ve read the godoc’s of this pair of pack’s a couple of times - monthes ago - and I am impressed about it’s style, completeness, eloquence and quality.
I think this is a bug. Either cmds should be returned in the first, or html should not be returned in the second. Please file an issue at golang.org/issue/new. Thanks.