Just use {{if}}...{{elseif}} statements that will check .MainContent 
equality to specific value and will invoke specific {{template ...}}




On Wednesday, September 11, 2019 at 3:40:22 PM UTC+3, dun...@gmail.com 
wrote:
>
>
>
> On Tuesday, April 17, 2012 at 2:52:03 PM UTC+1, Rob 'Commander' Pike wrote:
>>
>> You can't, for safety reasons in html/template. The text/template
>> package has the same property so the packages are consistent.
>>
>> The examples in the documentation for text/template show how the same
>> effect can be achieved safely.
>>
>
> What's unsafe about the code above?
>
> The basic issue I'm trying to solve is that I want to have a general 
> "layout" framework for web pages, in which I have a navbar at the top, a 
> navbar at the side, and content in the mail part.  The natural way to do 
> this would be to have a template that looks like this:
>
> {{define "page"}}
> {{template "navbarTop" .NavbarTopArgs}}
> {{template "navbarLeft" .NavbarLeftArgs}}
> {{template .MainContent .MainContentArgs}}
> {{end}}
>
> Then you define templates for the different main pages, and call the 
> "page" template at the top saying which of the templates to render.
>
> Looking around, there are basically three alternate solutions to this 
> problem, none of which are very satisfying:
>
> * Solution 1: Multiple parsed templates
>
> In this one, you define your main template like this:
>
> {{define "page"}}
> {{template "navbarTop" .NavbarTopArgs}}
> {{template "navbarLeft" .NavbarLeftArgs}}
> {{template "content" .MainContentArgs}}
> {{end}}
>
> Then for each "main content" page, you define a separate file that 
> contains a "content" template.
>
> But this means having a fully separate template variable, and all the 
> template code, for each different view of the webpage.  This seems really 
> repetitive an inefficient.
>
> Examples suggesting this:
>
>
> https://blog.rubylearning.com/go-web-programming-nesting-templates-f008418c6cc8
>
>
> https://hackernoon.com/golang-template-2-template-composition-and-how-to-organize-template-files-4cb40bcdf8f6
>
> * Solution 2: Invert the nesting
>
> In this option, you have each "main content" template manually include the 
> navbars, thus:
>
> {{define "MainContentAbout"}}
> {{template "navbarTop" .NavbarTopArgs}}
> {{template "navbarLeft" .NavbarLeftArgs}}
> ... content of 'about' page...
> {{end}}
>
> This again is repetitive -- each page has to include the navbars, and if I 
> (say) wanted to add a footer, I'd have to manually go and add it to each of 
> my content pages; and I might make a mistake and miss some.
>
> Examples suggesting this:
>
>
> https://levelup.gitconnected.com/using-go-templates-for-effective-web-development-f7df10b0e4a0
>
> The problem with both #1 and #2 is that they're violating the Don't Repeat 
> Yourself principle.
>
> * Solution 3: Work around the limitation with functions
>
> In this case, you define a function that will do the work of 
> programmatically nesting templates for you, like this:
>
> {{define "page"}}
> {{template "navbarTop" .NavbarTopArgs}}
> {{template "navbarLeft" .NavbarLeftArgs}}
> {{content .MainContentTemplate .MainContentArgs}}
> {{end}}
>
> And then implementing a function that looks like this:
>
>     funcs := template.FuncMap{
>         "content": func(t string, arg interface{}) (template.HTML, error) {
>             buf := bytes.NewBuffer(nil)
>             mtmpl, err := template.ParseFiles("templates/study.html.tmpl")
>             if err == nil {
>                 err = mtmpl.ExecuteTemplate(w, t, arg)
>             }
>             return template.HTML(buf.String()), err
>         },
>     }
>
> This has the benefit of being able to make our layout fully 
> parameterisable.  But it means having this weird structure where we go into 
> a template, go out into go, and go back into a *different* template.
>
> Examples of people recommending this approach:
>
> https://github.com/spbooks/go1/blob/master/chapter4/3_layouts/template.go
>
> It seems like it would be much better to simply incorporate #3 into the 
> language itself.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/efcad4f0-8296-4df1-9e60-07f677b2d253%40googlegroups.com.

Reply via email to