Is it worth the effort to create package that compile template to Go code

[Felix Sun]

I think the current text/template lose the benefit of a compiled language, for example not existed  method call in template don't show error until in runtime, I wonder is it feasible to create a template language that similar to the syntax of the text/template, but it compiles to Go code for example:

{{func Header(data HeadData)}}

<div>

{{data.Name}}

</div>

{{end}}

Will compile to:

func Header(w io.Writter, data HeadData) {

    io.WriteString(w, "<div>")

    io.WriteString(w, data.Name)

    io.WriteString(w, "</div>")

}

Is there any reason that we don't encourage people to do this?

[André Moraes]

Because you will not be able to change the template.

If you want to hardcode the template, make it a private variable, wrap
the call to template.Execute using a function and the arguments passed
to the template should be passed to the function first.

Then, write a mytemplate_test.go file and include some tests to ensure
the template is valid.

--
André Moraes
http://amoraes.info

[Felix Sun]

Maybe I am not clear with my intention, What I want to ask is:

1. a template language (which probably not text/template, but could be similar) that errors could be caught at compile time, including the type errors that arguments might passing wrong.

2. template partials could pass in more arguments would be a big plus.

So comes to the idea of compiling the template to go code and then compile to binary together with the app

It would work exactly as JSP in Java, see: https://gist.github.com/sunfmin/5124605

This will have a few benefits:

 

- that templates code are compiled into go code, and are automatically embedded into binary. so you can just copy the binary to deploy (No needs to copy templates over)

- As for speed matters, Of course the current text/template is super fast, But this compiled go code will be as fast as pure go code, because it is pure go code without any using of reflections. 

- Full use of Go compiling system to ensure that the template code correct. and fitting into the system defined data types as good as possible 

- Template compiled into funcs, Gives more flexibility that might reusing the func in other system part as easy as simple func call.

[Andy Balholm]

If you make a template system that compiles into Go code, you probably might as well allow actual Go code in the code snippets in the template, rather than trying to compile the dynamically-typed text/template language into Go.

[Felix Sun]

I wrote a blog post to describe more about the idea

http://sunfmin.com/2013/03/22/a-compiled-template-for-golang.html

[David DENG]

http://geps.daviddengcn.com/

FYI

David

[Caleb Doxsey]

I think a compile time version of text/template is potentially worthwhile but I'd avoid the JSP route. There's a reason PHP, ASP (classic), JSP and other templating languages like them have fallen by the wayside in favor of micro templating languages like Mustache.

By combining view logic with (sophisticated) programming logic code becomes extremely difficult to debug and maintain. And read:

<div>

    <script>

        document.write("<style>body{background:<%=BLACK%>}</style>")

    </script>

</div>

Once you're 5 embedded languages deep it's really easy to lose track of what's happening. 

[mortdeus]

Im working on a go prototype generator for wayland if you want to take a peek at that be my guest. It shouldnt be hard to hack with. 

https://github.com/mortdeus/gowl/tree/master/generator

[meta keule]

Why not use functions?

Have a look at 

https://github.com/metakeule/goh4

[John Nagle]

On 3/8/2013 3:41 PM, Felix Sun wrote:
> I think the current text/template lose the benefit of a compiled language,
> for example not existed method call in template don't show error until in
> runtime, I wonder is it feasible to create a template language that similar
> to the syntax of the text/template, but it compiles to Go code for example:

I'm starting to get the feeling that if Go doesn't get a good
template feature, it's going to get a bad one. One in the form
of some preprocessor, like this, or the M4 hack, or the CPP hack.
Or worse.

John Nagle

[Felix Sun]

What do you guys think about the Play Framework template engine: http://www.playframework.com/documentation/2.1.0/ScalaTemplates

I really like is it's compiled, and all the coding in templates also type safe and checked by compiler.

[John Jeffery]

FWIW, the Dart guys went down this path for a while. See http://blog.sethladd.com/2012/03/first-look-at-darts-html-template.html.

I thought it looked pretty good -- it provided a convenient, type-safe way to build HTML templates. In the end they stopped work on it in favour of their web component framework.

[mortdeus]

I do this in my goal project. I read from a Wayland XML protocol and use go's template system to automatically generate the functions. The cool thing is that its an embarrassingly parallel problem that is easily scales concurrently with goroutines.

On Mar 31, 2013 5:40 PM, "John Jeffery" <jjef...@sp.com.au> wrote:

FWIW, the Dart guys went down this path for a while. See http://blog.sethladd.com/2012/03/first-look-at-darts-html-template.html.

I thought it looked pretty good -- it provided a convenient, type-safe way to build HTML templates. In the end they stopped work on it in favour of their web component framework.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/-wYJik7iL60/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[mortdeus]

Gowl project*