This one takes a template path as an argument. Return dictionary with template values from your view. It's simple as: @render_to_template('posts/post_list.html') def api_get_all(request): return {'test': 'testing!'}
I'll throw my implementation into the mix - shortcut for render_to_response as a decorator.
Automatically render your view using render_to_response with the given template name and context, using RequestContext (if you don't know what this is you probably want to be using it). For example: @render_with('books/ledger/index.html') def ledger_index(request): return { 'accounts': ledger.Account.objects.order_by('number'), }
This code improves on Django's render_to_response shortcut function in the following ways: 1. If the caller does not provide a MIME type, and the caller is passing a RequestContext, it interrogates the request to determine if the HTTP client supports application/xhtml+xml encoding. If so, it sets the request type to application/xhtml+xml to override the HttpRequest class's default mime type of text/html. 2. It caches parsed templates in its own cache to improve performance. If you aren't using XHTML in your templates, you may choose to comment out the code that tests for and sets the application/xhtml+xml MIME type. I place this code in a file named "util.py" in my application. In my views, I write "from app.util import render_to_response" where I used to write "from django.shortcuts import render_to_response". Note that the caching functionality provided by this code means that you will need to recycle your Django instance when you make template changes. Instructions for doing this depend on how you have deployed your Django application.
Decorator, written for views simplification. Will render dict, returned by view, as context for template, using RequestContext. Additionally you can override template, returning two-tuple (context's dict and template name) instead of just dict. Usage: @render_to('my/template.html') def my_view(request, param): if param == 'something': return {'data': 'some_data'} else: return {'data': 'some_other_data'}, 'another/template.html'
This view decorator renders automaticaly the template with the context provided both by the view "return" statement. For example: @auto_render def my_view(request): ... return 'base.html', locals() You can still return HttpResponse and HttpResponseRedirect objects without any problems. If you use Ajax requests, this decorator is even more useful. Imagine this layout: def aggregating_view(request): ... context = locals() partial1 = partial_view_1(request, only_context=True) partial2 = partial_view_2(request, only_context=True) # aggregate template include partial templates return 'aggregate.htmt', context.update(partial1).update(partial2) def partial_view_1(request): ... return 'partial_1.html', locals() def partial_view_2(request): ... return 'partial_2.html', locals() This way you can render you view individualy for specific ajax calls and also get their context for the aggregating view.
I'm finding this much more efficient (from a coding perspective) than using the `render_to_response` shortcut. It looks complex, but it's simple to use: just look at the example in the docstring. Call this script `renderer.py` and chuck it in your project root.
Simplifies using RequestContext in render_to_response. Simply call the wrapper with request as the first argument, and the rest of the arguments are as normal for render_to_response. ex: render_response(request, 'foo_list.html', {'foo': Foo.objects.all()})