<p>My only experience with building a dynamic web site is with PHP.</p>
<p>I feel there is something fundamentally different with Golang text/template & html/template library. For a start, we don't have access to simple arithmetic in the templates, we also can't use loops (Beside <em>range</em>). It seems like I can only replace simple text placement and not do actual logic with it.</p>
<p>I've been wondering, how exactly do we write dynamic web sites with go?</p>
<hr/>**评论：**<br/><br/>letsencrypt: <pre><p>The general experience with dynamic websites using Go is that you will use Go as a service to power the interface, and consume the data from a frontend <em>(generally written in JavaScript)</em>. That is what is popular nowadays with the myriad of JavaScript frameworks out there, otherwise you will end up having a static site generator which is the other approach that some people are following. If you try to translate the big features of a dynamic scripting language like PHP then you are going to have a bad time, but if you translate your knowledge to JavaScript, for example, and power the website using a backend written in Go then <em>that</em> is going to give you better results.</p></pre>titpetric: <pre><p>If you want to do server side templating, you can look at ego or egon for an erb templating method. It generates go code from template files, so it's not as convenient at the built in text/template or html/template. It was suggested to use javascript, but that's a non-answer really - the person is basically saying "if you want to do a front-end, don't use go". You may look at some projects like hugo for some ideas.</p></pre>titpetric: <pre><p>I'm using this exact fork of egon: <a href="https://github.com/SlinSo/egon" rel="nofollow">https://github.com/SlinSo/egon</a> - I can't say that I'm exactly thrilled with it, it needs some work before it could be closer to EJS <a href="http://ejs.co/" rel="nofollow">http://ejs.co/</a> - some deviation with syntax, etc.</p>
<p>Generally I'd advise to stick with html/template. It's syntax is a bit removed from go (which is also my biggest butthurt), but it's a very close fit for what a template engine should do. You would get the benefit of speed by using EGON (it's compiled into go code!), and you can pretty much use the full go syntax (structs, chans, etc.). It does require a build step before you invoke go build/run, which adds to complexity.</p></pre>Sphax: <pre><p>You can loop with range, as you said. You can use if/else to control the flow.</p></pre>Kraigius: <pre><p>but I can't use a for/while/do while or modulo. I rarely ever need a range, I need to iterate and control the iteration. You can creatively create a function that will provide the for loop functionality (why isn't it built it the template?) but you won't be able to control the index due to how scoping works with variables in the template. </p>
<p>I can't even increment a variable without creating a function for it.
It all lead me to believe that text/template & html/template isn't made to do logic.</p></pre>shovelpost: <pre><p>1) </p>
<blockquote>
<p>I can't use a for/while/do while</p>
</blockquote>
<p>You do not need 3 kind of loops. That's why Go has only <code>for</code>. Similarly templates have range. You do not need anything else.</p>
<p>2) </p>
<blockquote>
<p>I need to iterate and control the iteration. </p>
</blockquote>
<p><code>{{range $i, $v:= .Dir}}{{$i}} {{$v}} {{end}}</code></p>
<p>3) </p>
<blockquote>
<p>You can creatively create a function</p>
</blockquote>
<p>Yes, that's the way to do it, if you need something extra. For example I like to create a <code>join</code> function for convenience in many projects. Also on a small project, I happened to do some strange loops and I needed a function to find me the <code>last</code> element of a slice. </p>
<pre><code>var fns = template.FuncMap{
"last": func(s []string) string {
if len(s) == 0 {
return ""
}
return s[len(s)-1]
},
"join": strings.Join,
}
</code></pre>
<p>Ta-da! I created the function with simple Go code. But from that small project, it was easy to see that having complex logic and loops in my templates is not so good. They make things unnecessary complex, harder to test and harder to maintain. Nevertheless, if you really need it, you can make it.</p>
<p>4) </p>
<blockquote>
<p>It all lead me to believe that text/template & html/template isn't made to do logic.</p>
</blockquote>
<p>To my experience, logic in templates is bad. Try to use as little as possible if you cannot avoid it altogether. The heavy lifting has to be done before you reach the template rendering phase.</p></pre>daveddev: <pre><p>Place the required logic in your application and/or template functions. It will reinforce better separation of concerns.</p></pre>echophant: <pre><p>You're right, text/template and html/template are not made to do the logic. You retrieve and format all of your data from your handler, and pass the formatted data into the template engine. Incrementing variables and using while loops don't have many valid use cases in a template, it's much more common to build a page by inserting bits of information and iterating over data.</p></pre>asdf072: <pre><p><a href="https://golang.org/pkg/text/template/" rel="nofollow">https://golang.org/pkg/text/template/</a></p>
<p>There are plenty of options. It looks like most of the capabilities found in most php template libraries are in go templates, including sub-templates.</p></pre>bgeyts667: <pre><p>We move the logic of the website into the application code, which it totally separated from templates. Yes, templates are not made to do logic, they are purely for displaying stuff.</p>
<p>That's kinda different from php, where you place logic into the same place, where you render the page. In go, we make a handler, which accepts the request, queries the data, processes it and only then loads it into the template.</p>
<p>PS. Some other commentors try to prove how powerful the templates are. But after all, templates can't replace fully-featured scripting language like php. And they shouldn't try to replace it, because they are meant to be used differently.</p></pre>
