Tag to inspect template context, filter to inspect variable. Originally by denis, [http://www.djangosnippets.org/snippets/1550/](http://www.djangosnippets.org/snippets/1550/). This just extracts variables from the context to locals for quicker access and autocompletion (When using ipdb). Additionally, 'vars' holds context keys for quick reference to whats available in the template.
This allows you to set up a breakpoint anywhere in your template code, by simply writing {% pdb_debug %}. You can then access your context variables using context.get(..) at the pdb prompt. Optionally, install the ipdb package for colors, completion, and more (easy_install ipdb).
This is a template tag that works like `{% include %}`, but instead of loading a template from a file, it uses some text from the current context, and renders that as though it were itself a template. This means, amongst other things, that you can use template tags and filters in database fields. For example, instead of: `{{ flatpage.content }}` you could use: `{% render_as_template flatpage.content %}` Then you can use template tags (such as `{% url showprofile user.id %}`) in flat pages, stored in the database. The template is rendered with the current context. Warning - only allow trusted users to edit content that gets rendered with this tag.
Allows getting the rendered content of a specific block tag. Useful if you want to send just a part of a template back for an AJAX request. Works for arbitrary template inheritance, even if a block is defined in the child template but not in the parent. Example: In `test1.html`: {% block block1 %}block1 from test1{% endblock %} {% block block2 %}block2 from test1{% endblock %} In `test2.html`: {% extends 'test1.html' %} {% block block1 %}block1 from test1{% endblock %} And from the Python shell: >>> from django.template import loader, Context >>> from template import render_block_to_string >>> print render_block_to_string('test2.html', 'block1', Context({})) u'block1 from test2' >>> print render_block_to_string('test2.html', 'block2', Context({})) u'block2 from test1' UPDATE: See also [zbyte64](http://www.djangosnippets.org/users/zbyte64/)'s implementation in snippet [#942](http://www.djangosnippets.org/snippets/942/)
Special thanks to the author of snippet 769 who provided most of the code for this snippet. Major differences: 1.Simpler/better handling of "extends" block tag 2.Searches If/Else blocks 3.Less code 4.Allow list of templates to be passed which is closer to the behavior of render_to_response
see comment block for example.
If you request static files such as images, javascript or css using http rather than https, the browser will complain that your site is not secure. This simple context processor will replace http:// with https:// in your MEDIA_URL if your static files are being included from an https page. In your settings.py just replace 'django.core.context_processors.media' with your new context processor.
Use these tags and filter when you're rolling your own search results. This is intended to be a whole templatetags module. I keep it in my apps as `templatetags/search.py`. These should not be used to perform search queries, but rather render the results. ### Basics There are three functions, each has both a tag *and* a filter of the same name. These functions accept, at a minimum, a body of text and a list of search terms: * **searchexcerpt**: Truncate the text so that each search term is shown, surrounded by some number of words of context. * **highlight**: Wrap all found search terms in an HTML span that can be styled to highlight the terms. * **hits**: Count the occurrences of the search terms in the text. The filters provide the most basic functionality as described above, while the tags offer more options as arguments, such as case sensitivity, whole word search, and saving the results to a context variable. ### Settings Defaults for both the tags and filters can be changed with the following settings. Note that these settings are merely a convenience for the tags, which accept these as arguments, but are necessary for changing behavior of the filters. * `SEARCH_CONTEXT_WORDS`: Number of words to show on the left and right of each search term. Default: 10 * `SEARCH_IGNORE_CASE`: False for case sensitive, True otherwise. Default: True * `SEARCH_WORD_BOUNDARY`: Find whole words and not strings in the middle of words. Default: False * `SEARCH_HIGHLIGHT_CLASS`: The class to give the HTML span element when wrapping highlighted search terms. Default: "highlight" ### Examples Suppose you have a list `flatpages` resulting from a search query, and the search terms (split into a list) are in the context variable `terms`. This will show 5 words of context around each term and highlight matches in the title: {% for page in flatpages %} <h3>{{ page.title|highlight:terms }}</h3> <p> {% searchexcerpt terms 5 %} {{ page.content|striptags }} {% endsearchexcerpt %} </p> {% endfor %} Add highlighting to the excerpt, and use a custom span class (the two flags are for case insensitivity and respecting word boundaries): {% highlight 1 1 "match" %} {% searchexcerpt terms 5 1 1 %} {{ page.content|striptags }} {% endsearchexcerpt %} {% endhighlight %} Show the number of hits in the body: <h3>{{ page.title }} (Hits: {{ page.content|striptags|hits:terms }}) </h3> All tags support an `as name` suffix, in which case an object will be stored in the template context with the given name; output will be suppressed. This is more efficient when you want both the excerpt and the number of hits. The stored object depends on the tag: * **searchexcerpt**: A dictionary with keys "original" (the text searched), "excerpt" (the summarized text with search terms), and "hits" (the number of hits in the text). * **searchcontext**: A dictionary with keys "original", "highlighted", and "hits", with obvious values. * **hits**: Just the number of hits, nothing special. Getting both the hits and the excerpt with "as": {% searchexcerpt terms 3 as content %} {{ page.content|striptags }} {% endsearchexcerpt %} <p>Hits: {{ content.hits }}<br>{{ content.excerpt }}</p> ### More For more examples see [Brian Beck's Text Adventure][announcement]. [announcement]: http://blog.brianbeck.com/post/29707610
Use this, if you want to "activate" menu items by URL. Typical usage is with CSS class 'active'.
Django's standard inclusion_tag doesn't include context variables by default. When you add takes_context you are required to manually merge the context variables into the dict which your tag returns, which tends to result in wasteful code or [possibly accidentally] leaking variables into the global context (`context.update({…})`). This decorator allows your inclusion tag to remain simple and still have safe access to the global context for things like `MEDIA_URL`: @register.inclusion_tag('my_template') @private_context def my_tag(context, …): return {"foo": 1, "bar": 2}
This approach allows you to avoid code duplication to produce same context data for different views. It could be usefull when you are using templates inheritace.
Here's a nice way of easily passing only certain settings variables to the template. Because of the way Django looks up context processors, we need a little hack with sys.modules. The [blog entry is here](http://sciyoshi.com/blog/2008/jul/10/dynamic-django-settings-context-processor/).
Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages) I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order. This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
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.
with this you can have context variables which know the media url and the urls of all your applications, if you need it. save the code as myapp/context_processors.py and add the following line to `TEMPLATE_CONTEXT_PROCESSORS` setting "mysite.myapp.context_processors.url_info", For each application you need to know the url set `MYAPP_URL` and add it to dict.