This is useful when you don't want to put any `{% verbatim %}` tag in the file(s) you're including within template(s) (because you want it/them completely raw) and when you want to load such file(s) from static dir(s), as native `{% include %}` tag can't achieve that (still).
Put the provided code in *templatetags/rawinclude.py* in your Django app, and then use it in your template(s) like this:
`{% load rawinclude %}{% raw_include 'file.html' %}`
[The problem](http://stackoverflow.com/questions/671369/django-specifying-a-base-template-by-directory): {% extends "./../base.html" %} won't work with extends.
It causes a lot of inconvenience, if you have an extensive hierarchy of django templates.
This library allows relative paths in argument of 'extends' and 'include' template tags. Relative path must start from "./"
Just write in your templates as follows:
```
{% load relative_path %}
{% extends "./base.html" %}
```
this will extend template "base.html", located in the same folder, where your template placed
```
{% load relative_path %}
{% extends "./../../base.html" %}
```
extend template "base.html", located at two levels higher
same things works with 'include' tag.
```
{% load relative_path %}
{% include "./base.html" %}
```
include base.html, located near of your template.
**Warning!**
The rule 'extends tag must be first tag into template' is disabled by this library.
Write your template with caution.
**Compatibility**
Code was tested with Django versions from 1.4 to 1.9
Installation.
-------------
Installation is differs for Django version 1.9 and previous versions, because 1.9 brings many changes into template's mechanizm.
**Django 1.9**
Plug reference to library code in 'TEMPLATES' key of settings.py or django.settings.configure()
```
TEMPLATES = [{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [os.path.join(ROOT_PROJECT, 'tpl').replace('\\', '/')],
'OPTIONS': {
'loaders': [
'dotted_path_to_relative_path_file.FileSystem19',
'dotted_path_to_relative_path_file.AppDirectories19',
],
'libraries': {
'relative_path': 'dotted_path_to_relative_path_file',
},
},
}]
```
**Django 1.4/1.8**
Put 'relative_path.py' file to the 'templatetags' folders of your app. (app must be included into INSTALLED_APPS tuple)
In settings.py or django.settings.configure(), replace standard django template loaders by loaders from this library
```
TEMPLATE_LOADERS = (
'dotted_path_to_relative_path_file.FileSystem',
'dotted_path_to_relative_path_file.AppDirectories',
)
```
Lets you include another template and pass in named variables. Use like:
{% partial field_template field=form.city %}
If no key is specified, it will use "item" instead. You may pass in multiple variables as comma-separated key=value pairs.
This is in the spirit of php's include_once or a C preprocessor #ifndef. Kind of. As you might've guessed, the output of
{% renderonce %}foo{% endrenderonce %}
{% renderonce %}foo{% endrenderonce %}
in a template will be a single 'foo'. I use it for js script tags personally, to prevent duplicate inclusions. If you ended up here, chances are you've already explored the "use inheritance" or "use django-(app X)" solutions, so feel free to omit such comments.
This is the `local_settings.py` trick extended to Django templates.
Sometimes you need to insert some arbitrary code in the HTML of the production site for external service integration like uservoice, typekit, google analytics... You don't want to put this code into source control because some other sites using the same source code may not need it.
So, add this template tag to your collection and do:
{% try_to_include 'head.html' %}
And leave `head.html` out of source control. Then when you need to include some code on your production site, just add the `head.html` template with the desired code to include.
I usually have one included template in the header for extra `<head>` tags, and one in the footer for extra javascript.
Node that the included template is rendered against the current context. If the template doesn't exist, an empty string is returned.
Also see the [full blog post](http://bruno.im/2009/dec/07/silently-failing-include-tag-in-django/) about this tag.
This snippet adds simple partial support to your templates. You can pass data to the partial, and use it as you would in a regular template. It is different from Django's {% include %}, because it allows you to pass a custom variable (context), instead of reusing the same context for the included template. This decouples the templates from each other and allows for their greater reuse.
The attached code needs to go into templatetags folder underneath your project. The usage is pretty simple - {% load ... %} the tag library, and use {% partial_template template-name data %} in your template. This will result in template passed as template-name to be loaded from your regular template folders.
The variables are passed in a with compatiable syntax, eg.
VAR as NAME and VAR as NAME
No limitations on the number of variables passed.
In principle it's a DRY code of a template node that can be used for creating project-wide template-tags. These can be used to display conceptually common blocks in templates with applications specific looks and content. E.g.:
1. application-specific info message,
2. model instances details in the list context,
3. login messages like 'Please login or signup to [some app-dependent text]' with appropriate url's,
4. standard forms (e.g with same CSS classes, displayed with uni_form).
The code is profusely commented so look it up for details. Basically, when you have your project-wide `SubIncludeNode` tag defined, then just define appropriately named templates in applications template subdirectories e.g. `'profiles/_show_item.html'`.
** Example usage: login or signup message **
Let's say we are editing template rendered by the view indicated by the pattern named 'project_list' in the 'projects' app:
{# those are equivalent #}
{% login_or_signup %}
{% login_or_signup project_list %}
{% login_or_signup "project_list" %}
{# academic purposes direct sub_include usage #}
{# those two includes are also equivalent if there is no template called '_login_or_signup.html' in the 'projects' subdirectory #}
{% url acct_signup as signup_url %}
{% url acct_login as login_url %}
{% url project_list as next_url %}
{% sub_include "_login_or_signup.html" %}
{% include "_login_or_signup.html" %}
{# and those two are also equivalent if there is a template called '_login_or_signup.html' in the 'projects' subdirectory #}
{% sub_include "_login_or_signup.html" from "projects" %}
{% sub_include "_login_or_signup.html" %}
{# also equivalent include if there is no variable called 'projects' in tempalte's context #}
{% sub_include "_login_or_signup.html" from projects %}
{# those are examples of using custom subcontext #}
{% url acct_signup as signup_url %}
{% url acct_login as login_url %}
{% sub_include "_login_or_signup.html" from "default" with login_url,signup_url,next_url="/welcome" %}
{% sub_include "_login_or_signup.html" with login_url="/login",next_url="/welcome",signup_url="/signup" %}
** Mored advanced usage proposal **
Say you have an subclasses of some model from the original app in a separate extending apps. You want to display subclasses instances differently using the original app templates. In the original app you do not know what the set of subclasses is (as the original app is not aware of the extending apps). Subclassing the `SubIncludeNode` you can override the `default_subdir` method such that it returns the app label of a model instance that was passed as a argument of your tag. This way you just put templates like `_show_instance.html` in extending apps subdirectories and voila - you have implementation of the overrideable templates displaying appropriately details about the model subclass instances.
I had an issue with the django templating system, where by if I included several different files at the same level on one template.. and all the included templates extended the same base template. It would render the defined blocks for the first inclusion for all. i.e. everything in the parent that is being extended would be not updated for the subsequent inclusion.
So, if anyone else has this problem. I have a solution that I sorta wanted for other reasons anyway. It's called a decorator tag, you can include and extend a template at the same time - in-line, with local context scoping so it only affects that tag.
This is also a nice way to avoid creating .html files for simple extending purposes.
At WWU Housing, we started using the [Tempest jQuery plugin](http://plugins.jquery.com/project/tempest) for javascript templating, which has the same {{ var }} syntax as Django's templating.
We wanted to be able to use the same templates in our server-side python and our client-side js, so we had to have a way of including the unrendered template for the js. At the same time, for convenience, it had to be modular so we could push the same code from our dev- to our live-server and not worry about absolute paths (which is why the {% ssi %} tag did not work).
So the {% include_raw %} tag was born.
Inserts the output of a view, using fully qualified view name (and then some
args), a or local Django URL.
{% view view_or_url arg[ arg2] k=v [k2=v2...] %}
This might be helpful if you are trying to do 'on-server' AJAX of page
panels. Most browsers can call back to the server to get panels of content
asynchonously, whilst others (such as mobiles that don't support AJAX very
well) can have a template that embeds the output of the URL synchronously
into the main page. Yay! Go the mobile web!
Follow standard templatetag instructions for installing.
**IMPORTANT**: the calling template must receive a context variable called
'request' containing the original HttpRequest. This means you should be OK
with permissions and other session state.
**ALSO NOTE**: that middleware is not invoked on this 'inner' view.
Example usage...
Using a view name (or something that evaluates to a view name):
{% view "mymodule.views.inner" "value" %}
{% view "mymodule.views.inner" keyword="value" %}
{% view "mymodule.views.inner" arg_expr %}
{% view "mymodule.views.inner" keyword=arg_expr %}
{% view view_expr "value" %}
{% view view_expr keyword="value" %}
{% view view_expr arg_expr %}
{% view view_expr keyword=arg_expr %}
Using a URL (or something that evaluates to a URL):
{% view "/inner" %}
{% view url_expr %}
(Note that every argument will be evaluated against context except for the
names of any keyword arguments. If you're warped enough to need evaluated
keyword names, then you're probably smart enough to add this yourself!)
Executive summary: url "include" on steroids--granular extra parms and validate names in passing
We maintain multiple Django applications, and we use the excellent built-in include mechanism to allow one urls.py to borrow from another:
http://docs.djangoproject.com/en/dev/topics/http/urls/
If you scroll down to the section entitled "Passing extra options to include," you will see this annoying limitation:
'''
Note that extra options will always be passed to every line in the included URLconf, regardless of whether the line's view actually accepts those options as valid. For this reason, this technique is only useful if you're certain that every view in the included URLconf accepts the extra options you're passing.
'''
My snippet overcomes this limitation, allowing you to extend individual urls without polluting the namespace. The function also has the nice side effect of validating that the parent hasn't changed names on you.
Looks up for a template based on the template-name plus the current users language code. Loads the template and renders it with the current context.
Example::
{% langinclude "foo/some_include.html" %}
Based on the users LANGUAGE_CODE, assumed we have 'de', it tries to render the template 'foo/some_include.html.de'. If that doesn't exists, it renders the template 'foo/some_include.html'. This is the default behavior of the include-Tag.
Basically this is a shortcut for the following code, just with a fallback for the default template::
{% ifequal LANGUAGE_CODE "de" %}
{% include "foo/some_include.html.de" %}
{% else %}
{% include "foo/some_include.html" %}
{% endifequal %}
---
Ein deutscher [Weblogeintrag mit Beschreibung](http://www.mahner.org/weblog/sprachabhangige-template-imports/)
This is an extension of the snippet http://www.djangosnippets.org/snippets/1302/ to make it a bit more flexible and been able pass more than one parameter to our "Partial Template". To use it you can
{% partial_template template_name param1:variable1 param2:variable2 ... %}
or:
{% partial_template partials/mini_template.html item:data1 var2:"False" var3:"2*2" %}
This snippet adds simple partial support to your templates. You can pass data to the partial, and use it as you would in a regular template. It is different from Django's `{% include %}`, because it allows you to pass a custom variable (context), instead of reusing the same context for the included template. This decouples the templates from each other and allows for their greater reuse.
The attached code needs to go into `templatetags` folder underneath your project. The usage is pretty simple - `{% load ... %}` the tag library, and use `{% partial_template template-name data %}` in your template. This will result in template passed as **template-name** to be loaded from **partials** folder. The **.html** extension will be appended to the file name. The file has to be in one of template paths accessible to the loader) and rendered with **data** as its context. The data is available in the template as an `item` context variable.
You can find more information in the [relevant Django documentation](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#howto-custom-template-tags)