14👍
Yes, it matters. First of all extends
can only occur as the very first line of the file. Secondly, include
pushes and pops a context object on the resolve stack, which means that value created in the context while in the include will go out of scope when it returns.
My rule is: create base.html
template files that define the overall structure of your site and use liberal amounts of {% block foo %}
around critical areas. Then all of your other templates extends
the base (or something that itself extends the base) and you replace those blocks as needed.
include
, on the other hand, is good for encapsulating things you may need to use in more than one place, maybe even on the same page.
Update:
I have been using my own library of template_tags
for so long that I forget that Django’s template language still has major gaps in functionality. The tag in question here is from an early django snippet called expr
which I have heavily edited and extended. You can say, for example, {% expr 'Fred' as name %}
(or any valid Python expression), and it will store the result in the ‘name’ slot in the current Context. If this occurs in an included
template, name
‘s value will be popped on exit from the template file.
You can sort of achieve this with the {% with %}
tag, but expr
gives me much greater flexibility, including doing arbitrarily complex calls. This originally came up when having to create complex cached objects that required expensive DBMS interactions that couldn’t be done up in the view, they had to be invoked in the template itself.
Email me (in my profile) if you need to get deeper into this.
3👍
( his friend )
What I actually meant was defining a base.html
so you can inherit a base template consistent of several generic sections, this one includes the doctype, html element defines 3 blocks for content and nav and optional area to override/insert script/link elements in the head.
<!doctype>
<html>
<head>
{%block extrahead %} {%endblock %}
</head>
{%block nav %}
<nav>
<ul>
<li>home</li>
</ul>
</nav>
<div id="content">
{% endblock %}
{%block content %}
{% endblock %}
</div>
</html>
Then you can define homepage.html
:
{% extends "base.html" %}
{% block content %}
homepage content
{% endblock %}
homepage.html
would then have the navigation because it extends base.html
.
- Create DB Constraint via Django
- Django attribute error. 'module' object has no attribute 'rindex'
- Django-compressor not setting absolute CSS image paths on Heroku
- Disable prefers-color-scheme: dark in django admin
3👍
In this case placing the menu in base.html
and extending from this seems to be more senseful.
including
is great for splitting complex template and reusing those chunks.
let’s say, you use the same list-style in different places of the site, but you send other queryset to it. as long, as you call the querysets the same, you only need to write the template code once.
Here I use differnt templates for normal- and ajax-requests. But using include let me re-use most parts in both templates
- How to debug Django custom management command using VS Code
- Django Views: When is request.data a dict vs a QueryDict?
- PyCharm include and modify External library in project
- Django formset not validating because ID is required
- UWSGI listen queue of socket full