One way to accomplish this may be to use embedding to wrap both Templates
into a new type:
package main
import (
txt "text/template"
"html/template"
)
// CsvTemplate wraps a html/template.Template and adds a
text/template.Template // field for CSV output.
type CsvTemplate struct {
template.Template
t txt.Template
}
On Monday, December 31, 2018 at 1:51:34 PM UTC-7, Renee Jylkka wrote:
>
> Hello,
>
> The project that I am working on is a web app written on a custom web
> server using Go and Go templates. I store all of the templates in a
> map[string]Template, where the string is the page name. When someone
> visits a page, the server checks whether that page is in the map, then if
> so calls a function to fill in a data structure, then executes the
> appropriate template, passing it the data structure. All was rosy until I
> was asked to create csv downloads for some of the more complex pages. I
> cannot use a html/template.Template for those pages, I have to use a
> text/template.Template for those pages, otherwise the character escaping
> implemented by html/template creates extra columns in some of the rows. My
> immediate thought was that since text/template.Template and
> html/template.Template have identical function lists, I should of course
> create an interface which would be implemented by both types. However, I
> have no idea how to create an interface to include arguments and return
> types of that interface type, such as:
> func Must(t *Template, err error) *Template
> func (t *Template) Funcs(funcMap FuncMap) *Template
>
> If I try to use *Template, the compiler gives an error that Template is
> undefined. If I use my interface name in place of *Template, the compiler
> gives the error that neither text/template.Template nor
> html/template.Template implements my interface. Both of these are expected
> behavior, but of course if I use text/template.Template or
> html/template.Template in place of *Template, only one of the two packages
> would implement my interface.
>
> Is there a correct way to wrap these two data types (using an interface or
> otherwise) so that I can deal with either one in the same data structures
> and functions, or am I stuck with a lot of duplicate code and data
> structures, with only slight differences beyond which package I'm using?
>
> Thanks!
> Renee Jylkka
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
