proposal: text/template: allow template and block outputs to be chained

[sylr]

It would be nice to be able to post process the output of the template and block directives, e.g.:

{{ block "letter" . | GzipString | Base64EncodeString }}
Dear {{.Name}},
{{if .Attended}}It was a pleasure to see you at the wedding.
{{else}}It is a shame you couldn't make it to the wedding.{{end}}
{{with .Gift}}Thank you for the lovely {{.}}.
{{end}}
Best wishes,
Josie
{{ end }}

{{ define "letter" }}
Dear {{.Name}},
{{if .Attended}}It was a pleasure to see you at the wedding.
{{else}}It is a shame you couldn't make it to the wedding.{{end}}
{{with .Gift}}Thank you for the lovely {{.}}.
{{end}}
Best wishes,
Josie
{{ end }}
{{ template "letter" . | GzipString | Base64EncodeString }}

Regards.

[sylr]

Motivation: Azure/aks-engine#1663

[rsc]

/cc @robpike and @adg. I believe the Go 1.6 template blocks were meant to address this need, but maybe it is worth taking a second look to see how well it has done that.

[adg]

In the example provided in this issue, I don't see why the caller wouldn't do the gzipping and base64 encoding in plain Go. Is there some more context that I'm missing?

In the aks-engine PR, I'm not seeing the connection. I also wonder why the author is using text/template to generate JSON; it seems easier and safer to me to use encoding/json.

@sylr can you provide more context as to how these features would benefit you?

[sylr]

@adg aks-engine use text/template to generate a yaml string which is used as value in a json object. Only parts of the YAML are gzipped, e.g.:

https://github.com/Azure/aks-engine/blob/master/parts/k8s/cloud-init/nodecustomdata.yml#L6-L9

Some times the template content is not coming from functions but are defined in the templates:

https://github.com/Azure/aks-engine/blob/master/parts/k8s/cloud-init/nodecustomdata.yml#L245-L261

Allowing to chain template and block output would allow to do gzipping directly in the template.

[adg]

I can see how the feature would be useful, but the proposed syntax doesn't make sense. The syntax for a {{template}} block is:

{{template "name" pipeline}}

In the given example

{{ template "letter" . | GzipString | Base64EncodeString }}

the part that says

 . | GzipString | Base64EncodeString

would be considered the pipeline part, when really the dot and the Gzip/Base64 parts are separate. There'd need to be some other way to treat the template invocation as the value, for another pipeline. It's not clear how one might do that.

[sylr]

Yes it would need to change how parameters are handled.

It currently evaluates like this :

{{ template "name" (. | ...) }}

It would evaluate like this:

{{ (template "name" .) | (...) }}

[sylr]

As far as I see things it is the current syntax that does not make sense.

The 3rd parameter of the template statement is implicitly handled as a variadic argument which is confusing.

[adg]

The third argument to the template statement is not a variadic; it's a pipeline, which is just the text/template way of saying "expression". It's consistent with the rest of the grammar.

Any change we make here would need to be compatible with the existing uses of text/template, so changing the meaning of the grammar there is a non-starter.

[sylr]

Then what about a new type of block which takes an Argument rather than a Pipeline and which could be chained, e.g.:

{{ eval "letter" . |  ... }}

[adg]

To achieve that, you can define a function like 'eval' yourself. For example:

		"eval": func(name string, arg interface{}) (string, error) {
			var buf bytes.Buffer
			err := t.ExecuteTemplate(&buf, name, arg)
			return buf.String(), err
		},

The trick is to make that function enclose the template variable itself, for example:

package main

import (
	"bytes"
	"encoding/base64"
	"log"
	"os"
	"text/template"
)

const tmplText = `
{{ define "letter" }}
Dear {{.Name}},
{{if .Attended}}It was a pleasure to see you at the wedding.
{{else}}It is a shame you couldn't make it to the wedding.{{end}}
{{with .Gift}}Thank you for the lovely {{.}}.
{{end}}
Best wishes,
Josie
{{ end }}
{{(eval "letter" .) | base64 }}
`

func main() {
	t := template.New("")
	t.Funcs(template.FuncMap{
		"eval": func(name string, arg interface{}) (string, error) {
			var buf bytes.Buffer
			err := t.ExecuteTemplate(&buf, name, arg)
			return buf.String(), err
		},
		"base64": func(s string) string {
			return base64.StdEncoding.EncodeToString([]byte(s))
		},
	})
	_, err := t.Parse(tmplText)
	if err != nil {
		log.Fatal(err)
	}
	err = t.Execute(os.Stdout, map[string]interface{}{
		"Name":     "Joe",
		"Attended": true,
		"Gift":     "shoes",
	})
	if err != nil {
		log.Fatal(err)
	}
}

[rsc]

To summarize the discussion so far:

• the proposed syntax already has a different meaning; that syntax cannot be redefined.
• the specific need of redirecting a template's output can be done with a registered func
  like eval instead; that turns template execution into a value that can be part of a pipeline.

That is, the proposed feature can't be accepted with the suggested syntax, and the functionality can already be implemented with a short bit of Go code in the caller.

Those two together make it sound like we should decline this proposal. Am I reading anything wrong?

[sylr]

I am a bit sad this would not be not part of text/template but yes I think we can close this.

[rsc]

Based on the discussion, then, this seems like a likely decline.

[rsc]

No change in consensus, so declined.