Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
text/template: make blocks easier to use #14285
I spent a little too much time trying to get the new
Which is telling me that you should try to supply a "more real" example in the documentation.
Hugo uses the built-in associative transitive map to store its templates, so adding a new template is something like:
As I understand the new
How to do that with the above I cannot figure out (other than the simple standalone clone example in the doc -- I could clone it, but how do I replace the template in the map?).
My naive approach would be:
m, _ := hugoTemplates.New("home").Parse(master) m.Parse(overlay)
And this works ... for the first template. Adding a second breaks in confusing ways.
Also see #3812
I think the issue is that hugo does things one way, while the block feature wants to do them another. The deal with blocks is that you create new
Maybe @spf13 can comment on the approach taken by Hugo.
I am working on a better example of template blocks.
Hugo's approach is basically:
If I read you correct, this approach will not work with blocks and master/overlay templates, but you would have to get rid of the global and track the individual templates (with funcs and all the other dependencies (templates) duplicated/cloned) in your own registry?
I guess that would work, but it sounds like fighting the original design .
Not sure what I expected by the new
@bep knows this as well as anyone.
I'm not sure if I understand this all correctly at all. From my reading of this thread and some of the related ones it sounds to me like go template blocks will use a vanilla *template.Template for the children (overriders)?
If so I think the approach the go team has taken makes sense from an implementation perspective, but is also a bit shortsighted. I don't think it's reasonable to assume that people would want a plain
I've always thought the templates worked a bit strangely as you need to create a template and then chain off of it to create others, but it's worked really well for Hugo by creating an empty template at the root, customizing it and then all of the others effectively extend it. It's disappointing that this feature would not respect that valid use pattern.
Please correct me if I'm wrong.
@spf13 this sentence
leads me to believe you misunderstand how blocks should be used. You first declare a master
@adg: I guess the CL was a "yes" to the question above.
I suggest you keep this issue open to track obvious improvements to the "master/overlay" feature.
I will put the Hugo-issue in freeze-mode for now.
Your new example is just a little slightly more practical example of the same.
If you look at
With the current master/overlay-dance you will have to re-implement similar logic yourself, which may or may not be a simple thing, depending on the use case.
Simplicity is hard.
@agl what you have added is convenience methods that behaves very differently from their
I'm sorry if I couldn't convey my message better, but these two methods I think are better left out of the API as is, it will confuse more than it helps.
What I would expect of
This is how the template API looks like. There may be technical challenges making this overlay construct fit into that API, but if it's impossible, then just leave it as is.
It would parse the
In the above,
Maybe my construct would make more sense looking like this:
Anyhow, I would expect the
(sorry about the username confusion, but agl is about as close to your real name as adg ..)
I maybe missing something significant but why not keep overlay information in templates themselves?.
Something like this http://play.golang.org/p/qRmZPnKYCF
@fazal you'll need to describe your proposal in a lot more detail. There
On 24 February 2016 at 21:39, fazal email@example.com wrote: