> @buroz okay see the problem

[sp213]

@buroz okay see the problem

you have built your own layout system, although we offer this possibility with the {{embed}} placeholder and the layout specification, where you specify where the content of the template you are running should be rendered in

please check the basic example with the layout: https://github.com/gofiber/template/tree/master/html#basic-example

problem with your variant with the define blocks is that the identifiers of these are not unique

because before using the template engine everything is parsed and added to the go template engine, later when calling the render method only the template is picked out which should be rendered, but here exist several blocks with the same name and the base file doesn't know which one it should take

in my test the base file uses e.g. the define block from the place file although i specified the home file for rendering, probably this is because the other file was added sooner or later in the pre-rendering process by the go template system and then overwrites the block

here some infos about the go template system https://github.com/gofiber/template/blob/master/html/TEMPLATES_CHEATCHEET.md

Hi, what if I want to render different css files from user.html and product.html using the same layout.html?

The {{embed}} I used is for body rendering.

When I use {{template "css" .}} in layout.html, and then use {{define "css"}} {{end}} separately in user.html and product.html, the last one overrides previous ones according to the order of parsing files, which leads to loading css file.

How can I fix this?

Thanks.

Originally posted by @ospng in #149 (comment)

[ReneWerner87]

the define blocks are for sections that no longer change in the complete template area

if you have something dynamic, you can customize it using the injected variables to render other content or swap files or even customize css content using this method

the decision to preanalyze all files in the view folder was made because of performance issues

but i think you can handle it and there are enough ways to solve every problem

[sp213]

thank you anyway, using injected variables is not very convenient, decided to switch back to gin.

[preslavrachev]

I stumbled upon this same issue recently. I think that this needs to be documented somewhere. I was completely unaware that a single template.Template instance gets stored for parsing all templates. This basically obviates the use of define altogether (unless you want to use to globally split templates, for convenience).