I have some html structures that are reused in quite a few different places. It's different from a overall template so I can't extend it, it can also be used to contain complicated content so I don't think defining it as a template tag does a good job. Below is some pseudo code describing my desired outcome, when using template_level2.html you can easily put stuff into the reusable_pattern_template by calling the block inside it. If I do use this code, what you write in 'actual content' of template_level_2.html wouldn't show up. How should I deal with this?
base.html
<html>
<head></head>
<body>
{% block content %}{% endblock %}
</body>
</html>
template_level1.html
{% extends 'base.html' %}
{% block content %}
Something here...
{% include 'reusable_pattern_template.html' %}
Something else here...
{% endblock %}
reusable_pattern_template.html
<div>
<div>
<div>
{% block local_content %}{% endblock %}
</div>
</div>
</div>
template_level2.html
{% extends 'template_level1.html' %}
{% block local_content %}
Actual content here...
{% endblock %}
update:
Sorry, the extends in template_level2.html has some misspelling, I've just corrected it.
It may not be very clear, but the code above is more of a pseudo code describing my desired outcome. In short,
I would like to include small pieces of reusable html patterns in my
templates.
These patterns are like boxes, that you can put whole pieces of html
content in them. So context variables may be a bit of too limited for
my purpose
Django does not process blocks in included files.
The include tag should be considered as an implementation of "render this subtemplate and include the HTML", not as "parse this subtemplate and include its contents as if it were part of the parent". This means that there is no shared state between included templates -- each include is a completely independent rendering process. (Django template tag documentation)
I came across this problem and ended up with the following compromise, hoping someone else might find it useful. It relies on using with blocks in the child templates.
base.html wants to reuse a common nav.html include, but define some blocks where variables inside nav.html might be overriden by child templates.
<!-- base.html: -->
<html>
[...]
<nav class="desktop">
{% block desktop_nav %}
{% include "includes/nav.html" %}
{% endblock %}
</nav>
[...]
<nav class="mobile">
{% block mobile_nav %}
{% include "includes/nav.html" %}
{% endblock %}
</nav>
[...]
The include template depends on a variable called selected, which base.html does not define, by default:
<!--includes/nav.html:-->
About
People
Contact
But child pages can override that value as follows:
<!--about.html:-->
{% extends "base.html" %}
{% block desktop_nav %}{% with selected='about' %}{{ block.super }}{% endwith %}{% endblock %}
{% block mobile_nav %}{% with selected='about' %}{{ block.super }}{% endwith %}{% endblock %}
so, not perfect, I still have to have two separate blocks and use those with blocks twice, but it does allow me to override variables in include blocks from the parent template.
It seems that the final template is trying to extend itself (if it was in quotes).
You really don't need that much of complexity. It's actually pretty much simpler.
The base template should hold the skeleton of your template, then you can extend it to make customizations. For reusable code blocks that you don't want to include in your every view, include them where appropriate but don't use any block, extends or include statement within the included file. Django will not parse those but the context variable passed from the view can still be used.
In short, you can create variables in whichever template you're planning to include e.g.
{{ localcontent }}
and then assign those variables wherever you include the template e.g.
{% include "name_snippet.html" with localcontent="Actual content" %}
You could split reusable_pattern_template into begin and end templates. Then in level1 you can go include begin, block, include end.
Alternatively you could pass a template name into reusable_pattern_template as a context variable and then include it in reusable_pattern_template. This will require changing the relationship between level1 and level2 in your example but is generally more powerful.
Not the exact thing but you can do this (I've used it for including navigation bars):
Use with and only
snippet.html:
<div>
{{ listItem1 }}{{ listItem2 }}...{{ listItemN }}
</div>
index.html:
{% include 'snippet.html' with listItem1='<li>HOME</li>' listItem2 ='<li>ABOUT</li>' only %}
Since, we have used only after listItem2, all further variables will be ignored.
Related
In the Wagtail docs (Your first Wagtail site) we are told to create a homepage.html template as follows:
{% extends "base.html" %}
{% load wagtailcore_tags %}
{% block body_class %}template-homepage{% endblock %}
{% block content %}
{{ page.body|richtext }}
{% endblock %}
In the above code, what is that tag {% block body_class %}template-homepage{% endblock %} supposed to be doing? I can't find any mention of it in the text of the tutorial.
The tutorial goes on to instruct us to create two more templates, blog_index_page and blog_page templates, both of which are to contain {% block body_class %} tags. Again, I can find no mention at all of those lines in the docs, let alone an explanation of how they might be used/modified.
A search for "body_class" in the docs finds only the three code blocks just mentioned, and one other mention: in the version 1.2 release notes, under 'What's new — Minor features' the notation: "Simplified body_class in default homepage template."
Any insight as to what I'm supposed to do with these tags? What special meaning or function, if any, does the text enclosed within the tags in those tutorial templates (for example, "template-homepage" in the code above)?
In base.html you have a part that looks like <body class="{% block body_class %}{% endblock %}">. What you add into that block in your templates will be rendered into that section.
For example, lets say on your design your <body> contains a bottom margin, however on a particular template you don't want the margin there and create a css class .remove-margin { margin-bottom: 0 };
You can then add {% block body_class %}remove-margin{% endblock %} into your template and it will apply the class to the <body> tag without you having to modify the base.html template for that one use case.
You are also able to create your own ones. In base.html add a custom block such as {% block my_custom_block %}{% endblock %} and then in your template include some text or html inside that my_custom_block and it will be rendered wherever you've place that part in the base template.
Just to help clarify the correct answers above with a picture as I was also wondering what that block tag was doing, here is the rendered html. As per answer above, this is standard Django.
In the base.html you have this line:
<body class="{% block body_class %}{% endblock %}">
The substitution happens in the home_page.html template:
{% block body_class %}template-homepage{% endblock %}
And it renders as per below screenshot:
<body class="template-homepage">
I want to cycle the include tags in a django template, but I am unable to nest cycle inside of includes. The cycle should be like
include cycle left_align.html right_align.html
I am trying to avoid creating a custom template just to keep it simple. I wanted to see if anyone had any suggestions of how to do this:
{% for s in sections %}
<section class="{% cycle 'lighter-section' 'cover cover-bg-section' %}">
{% if s.media.values %}
{% include 'web_builder/apple-pie/sections/left_align.html' %}
{% else %}
{% include 'web_builder/apple-pie/sections/center_align.html' %}
{% endif %}
</section>
{% endfor %}
Unfortunately there is no way to assign result of cycle templatetag to a variable with with block but you can use as keyword to dump its result to the variable and use it wherever you wish e.g. {% cycle 'left_align.html' 'right_align.html' as include_file %}. However this has a side effect.
This instruction itself produces cycle result although it is also registered in the variable. As a work-around you can place it for instance in a data- attr of some HTML element so that it isn't displayed and use the variable later in full template path concatenation inside include tag.
Full example:
{% for i in "xxxxxxxxxxxxxxxxx" %}
<section data-include-file="{% cycle 'left_align.html' 'right_align.html' as include_file %}">
{% include 'web_builder/apple-pie/sections/'|add:include_file %}
</section>
{% endfor %}
However since it looks ugly and complicated I would also consider writing custom inclusion tag for that.
I would like to have some advice in constructing django template levels.
Reading the docs, I do not understand how to create a template hierarchy structure with more than 2 levels.
For example, I would like to create 3 levels of inheritance:
base.html
└── base_level2.html
├── level2_level3_1.html
└── level2_level3_2.html
This is my code:
base.html
First level
{% block level2 %}{% endblock %}
base_level2.html
{% extends "base.html" %}
{% block level2 %}
Second level
{% block level3_1 %}{% endblock %}
{% block level3_2 %}{% endblock %}
{% endblock %}
level2_level3_1.html
{% extends "base_level2.html" %}
{% block level3_1 %}
Third level, part 1
{% endblock %}
level2_level3_2.html
{% extends "base_level2.html" %}
{% block level3_2 %}
Third level, part 2
{% endblock %}
views.py:
def myView(request):
return render_to_response('level2_level3_1.html', {}, context_instance=RequestContext(request))
In this way I can see the following on my browser:
First level
Second level
Third level, part 1
And this is logical to me because I call render_to response only on level2_level3_1.html.
Of course, if call level2_level3_2.html, I get the message Third level, part 2 but not the Third level, part1.
How to solve this? Is that a good approach? I've structured stuff in this way because my real templates are very big, a lot of lines of code, so I would like to keep some order.
Any advice will be appreciated.
It's hard to say if it's a good or bad idea or not without knowing the specific functionality of your templates, but my immediate reaction is that you're trying to over organize your templates. I think most people would urge you away from more than a 3-tier system because it makes it more difficult to make small changes in the website and more difficult to keep track of where things are. from the Zen of Python:
Flat is Better than Nested
The recommendation for a 3-tier system inTwo Scoops of Django goes like this:
Each app has a base_<app_name>.html template. App-level base templates share a common parent, base.html.
Templates within apps share a common parent base_<app_name>.html template.
Any template at the same level as base.html inherits base.html
and for your naming schema, it might look like this:
| Templates/
|--base.html
|--someothertemplate.html # extends base.html
|--level2/
|----base_level2.html # extends base.html
|----level2_1.html # extends base_level2.html
|----level2_2.html # extends base_level3.html
EDIT: and there's no real reason for this:
Second level
{% block level3_1 %}{% endblock %}
{% block level3_2 %}{% endblock %}
where each block refers to the content of one template. you can simplify that to one block like
{% block level3 %}{% endblock level3%}
and then in each of the level3 templates, rename the blocks accordingly
Probably not the best way of doing it but you might user include https://docs.djangoproject.com/en/dev/ref/templates/builtins/#include
something like this for base_level2.html
{% extends "base.html" %}
{% block level2 %}
Second level
{% include "level2_level3_1.html" %}
{% include "level2_level3_2.html" %}
{% endblock %}
i've not tested this, so not sure it works.
and btw:
The include tag should be considered as an implementation of “render this subtemplate and include the HTML”, not as “parse this subtemplate and include its contents as if it were part of the parent”. This means that there is no shared state between included templates – each include is a completely independent rendering process.
In my project, I need to treat CSS requirements differently depending on several parameters. Thus, I need an additional level of abstraction compared to available static management systems.
In my templates, I would like to be able to register CSS (and JS) requirements with a template tag which would look like {% register_css 'myfile.css' %}. This approach works like a charm.
However, there is still one problem with this approach : the tag works perfectly when inserted in a block, but never gets called when inserted on top of a child template. The tag definition is:
#register.simple_tag(takes_context = True)
def register_css(context, *args):
context['static_registry'].register_css(streamlet)
return ''
This is my test template:
{% extends main_skelton %}
{% load static_registry %}
{% register_css 'base' %}
{% block title %}Welcome{% endblock %}
{% block content %}
{% register_css 'home' %}
<p>Some content here</p>
{% endblock %}
In that template, the 'home' css gets registered, but not the 'base' one. How may I make both work?
Thanks!
Include an empty {% block init %} in your base template, then override that block in the child templates to register files - {% block init %}{{ block.super }} {% register_css 'foo %}{% endblock %}
The underlying issue is that in a child template, only blocks that match something in the parent template will get rendered. AFAIK there's no easy way around that, but using a dummy block works just fine.
I have the following structure of templates (simplified for clarity):
base1.html:
<html>
<head>{% block head %}{% endblock %}</head>
<body>{% block body %}{% endblock %}</body>
</html>
base2.html:
{% extends "base1.html" %}
{% block head %}
<meta .... />
<title .... />
css includes etc.
{% endblock %}
{% block body %}
{% block header %}{% endblock %}
{% block featured %}{% endblock %}
{% block navigation %}{% endblock %}
{% block content %}{% endblock %}
{% block footer %}{% endblock %}
{% endblock %}
Also base3.html and base4.html which futher detalize the generic body structure defined in previous base templates (not shown here). The last template extends base4.html, overriding blocks with concrete content (markup is handled by base templates).
The question is: I have two templates: main.html and article.html which both extend base4.html. But in article.html I want the order of body blocks defined in base2.html to be different (featured block to go after navigation). How can I achieve that? Or how to refactor the structure of templates to make this possible? Overriding the block body in top-level template doesn't work.
I don't think that you're going to have any luck going about it that way. A simple solution could be to have an optional variable that base2.html looks at, which determines the alternate order. In fact it may even be that you can define the presence of this variable in the article.html template itself. I haven't tried this, but something like the following may work:
{% with alternate_order=1 %}
{% include base4.html
{% endwith %}
Why do you have so many levels of inheritance? As a note, django provides no limitations, but typically we use the three-level approach. See docs
Here are a few suggestions:
You can probably combine base1.html and base2.html.
If you can put the html code in the parent then do so. I usually implement my templates like this:
<div id='sidebar'>{% block sidebar_content %}{% endblock %}</div>
As for your problem, if you need a different layout, that's when you branch. That is, if using a different css won't work.