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
This template tag provides an easy way to render objects in your template, even if you don't know ahead of time what type they are. For example, if you've got a search page with a result list comprised of objects from various models, you can simply loop through them and render them using the tag. The tag will choose the best template and render the object for you. The tag's docstring has all the details. I hope you find this as useful as I have. Questions, comments, complaints welcome.
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/)
As a demo, I was asked to write a `render_to_file()` function to load a template and render it to a file. Turns out it's amazingly easy, and I think it's a neat trick to have in your bag of tools.
Easy way to caching template. Very simple usage: @django_template("my_site.html") def master_home(request): variables = { 'title' : "Hello World!" } return variables
Simple decorator to render an html template or return a json response. The view must return a dict object. Usage example: @render('page.html') def a_view(request): #do something return {'key': 'value'}
**Problem:** You want to render an arbitrary number of fields assigned dynamically, as in [snippet #27](http://www.djangosnippets.org/snippets/27/), but using multiple `if` statements in a template would be tedious. **Solution:** newforms BoundField The example demonstrates a form with medication fields. We don't know in advance how many meds will be prescribed to a patient, but we want to display a minimum of 4 medication fields, each consisting of a label, name, and dosage. My code uses a cheap hack of assigning a .bf attribute to the fields during __init__, but it's easy to render in a template loop: `{% for med in form.med_list %}` *Special thanks to Honza for advice on BoundField.*
I was looking for a way to save screen real estate, by using icons instead of labels for my list of choices, which in addition should be displayed as horizontal radio buttons. For example, I wanted to use thumbs_up.gif instead of "approve". I found a HorizontalRadioRenderer here: [https://wikis.utexas.edu/display/~bm6432/Django-Modifying+RadioSelect+Widget+to+have+horizontal+buttons](https://wikis.utexas.edu/display/~bm6432/Django-Modifying+RadioSelect+Widget+to+have+horizontal+buttons) Thanks to Barry McClendon for this snippet! At first, I tried to achieve display of icons instead of labels by modifying the render method, but after a while I gave up on that and decided to just use the choices tuple. This doesn't work too well with a select box (no icons, no text), but in combination with a radio widget it looks quite nice. If you mark the strings for translation, you can also easily change icons, alt and title for each language.
Renders a view to an email. You need to set all of the required settings for email support.
You need the mini-detector middleware installed [http://www.iterasi.net/openviewer.aspx?sqrlitid=-e2dfig9w0yrclxaigp-uw](http://www.iterasi.net/openviewer.aspx?sqrlitid=-e2dfig9w0yrclxaigp-uw). This is a drop in replacement to render_to_response. When using mini_render_to_response it will try to load a version of your template with mini at the end. For example "home_mini.html" instead of "home.html". If it doesn't find the _mini version it falls back to the regular "home.html" version of your template. Easy way to maintain a "small screen" version of your templates for iPhone or other small screen devices.
You can use this as a decorator for your views, this way you can return a simple dictionary and the decorator will do the rest. **@TODO:** Automatically set the template based on the app/view request
In order to context_processors work, you need to use the RequestContext instead of Context. This is a shortcut I use.