<p><a href="https://github.com/steven-ferrer/plet">Plet</a> is a simple template package that wraps <a href="https://golang.org/pkg/html/template/"><code>html/template</code></a></p>
<hr/>**评论：**<br/><br/>daenney: <pre><p>I have to ask, how does this improve over <code>html/template</code>? I've looked at a few of the examples but it seems to roughly expose the same API as <code>html/template</code>.</p>
<p>Slightly related, you're using string concatenation to build up paths, use <a href="https://golang.org/pkg/path/filepath/#Join" rel="nofollow"><code>filepath.Join</code></a> instead so it works correctly on all platforms.</p></pre>srxf: <pre><p>Hi <a href="/u/daenney" rel="nofollow">/u/daenney</a> thanks for pointing that out. I'll have to make changes and use <code>filepath.Join</code> to set a good example :)</p>
<p><code>html/template</code> is already an amazing package but I find it tedious to type all the filenames if I have template definitions in separate files. </p>
<p>So, with <a href="https://github.com/steven-ferrer/plet" rel="nofollow">plet</a>, i just have to put them all in one folder and it will manage to find all the template definitions.</p>
<p>By the way, I separated the template definitions in <a href="https://github.com/steven-ferrer/plet/tree/master/examples/tmplt/content/simple" rel="nofollow">examples/tmplt/content/simple</a> folder to make my point clear :)</p></pre>joncalhoun: <pre><p>Are there any other differences? I find the directory issue can be solved easily with a glob.</p></pre>srxf: <pre><p>Oh right, thanks for pointing that out <a href="/u/joncalhoun" rel="nofollow">/u/joncalhoun</a>. </p>
<p>I have defined a type called <code>Templates</code>. this is just a map that holds the collection of templates. So, when you do <code>templates.Add(someTemplate)</code> it uses the base directory name of the content dir of <code>someTemplate</code> as the map key so that you can do <code>templates.Get("myTemplate")</code>. Please see <a href="https://github.com/steven-ferrer/plet/blob/master/examples/templates.go" rel="nofollow">this</a> example.</p>
<p><strong>EDIT</strong>: I just realized that my explanation is unclear so I re-edited it.</p>
<p>Also, by default it caches the compiled templates so that it wouldn't need to recompile the templates every time. But when developing, you would want your templates to re-compile every time you run <code>Template.Execute</code>. This can easily be done by setting <code>Template.HotReload</code> to true.</p></pre>throwlikepollock: <pre><blockquote>
<p>Slightly related, you're using string concatenation to build up paths, use filepath.Join instead so it works correctly on all platforms.</p>
</blockquote>
<p>I've always used filepath.Join fwiw, but I've often been confused as to <em>why</em> we are. If you look at some <em>(I don't remember examples offhand)</em> path functions, they mention that they use standard unix paths, abstracting away any platform specific oddities like the windows backslash.</p>
<p>So not that I'm trying to justify not using <code>filepath.Join</code>, but in what cases will manual separator management actually cause problems? Perhaps some functions intended for pathing, like <code>path</code> and <code>filepath</code>, will abstract the separators from you - but things like <code>os.Open</code> won't?</p>
<p>Anyway, a bit unrelated, just wanted to ask haha.</p></pre>daenney: <pre><p>To the best of my knowledge, <code>path</code> package is meant to handle forward-slash separated paths only, like URLs for example. You can still use <code>path</code> with the <code>/</code> to build up file paths too since that logic is abstracted away but you have to call <code>filepath.FromSlash(...)</code> if you want to hand that path to the OS, to open a file etc. for example. Using <code>path/filepath</code> takes care of this problem entirely and deals specifically in OS agnostic file paths. Those can be safely and directly passed to any function dealing with files at an OS level.</p></pre>srxf: <pre><blockquote>
<p>Slightly related, you're using string concatenation to build up paths, use filepath.Join instead so it works correctly on all platforms.</p>
</blockquote>
<p>I tried running the tests on Windows without using the <code>filepath.Join</code> and it still worked correctly. Any explanation why it still worked?</p></pre>daenney: <pre><p>I suppose that happens b/c of your use of <code>filepath.Base()</code> and <code>filepath.Walk()</code> which knows how to deal with <code>/</code>-separated file paths.</p></pre>srxf: <pre><p>Hi guys! I've created a simple package for managing templates for web apps.
Please criticize :)</p></pre>kickinespresso: <pre><p>Is this similar to other templating systems? It looks a bit like Handlebars. </p></pre>srxf: <pre><p>No its not, its just a wrapper for <a href="https://golang.org/pkg/html/template/" rel="nofollow"><code>html/template</code></a>. </p>
<p><code>html/template</code> is the standard template engine for Go.</p>
<p>If you are looking for other template engines, then you might wanna check <a href="https://github.com/avelino/awesome-go#template-engines" rel="nofollow">this</a> out.</p></pre>Mikojan: <pre><p>Managing templates really is somewhat of a pain.</p>
<p>I use <a href="https://github.com/jteeuwen/go-bindata" rel="nofollow">bindata</a> to ship them with the binary <a href="https://github.com/hahanein/russenmagazin/blob/master/embedded-golang-templates.md" rel="nofollow">and a simple makefile to discover and bundle them.</a> Hasn't failed me yet</p></pre>
