Snippet List
Based fully on [snippet 1929](http://www.djangosnippets.org/snippets/1929/)
**The update is:**
It checks to see the view returns an instance of HttpResponse and returns that rather than trying to render it.
This allows you to return something like `HttpResponseRedirect('/')`, or use a normal `render_to_response` to use a different template.
*Also updates cleandict as per comment on original snippet*
In this case the 'render_template' decorator assumes there is a myview.html template. this keeps things simple and you DRY. Hope it helps.
- template
- decorator
- rendering
- dry
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'),
}
- render_to_response
- requestcontext
- decorator
- rendering
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'
- render_to_response
- requestcontext
- shortcut
- decorator
- rendering
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.
- render_to_response
- ajax
- decorator
- rendering
As an alternative to using forms rendered with the
default hard-coded html, this factory function will
take a template name as argument, and return a Form class based on django.newforms.BaseForm, which will
render each form field using the supplied template.
As an example, I'm using this class as follows in one
project (slightly edited with respect to project and
app names):
# Get a form class which renders fields using a given template
CustomForm = proj.utils.makeTemplatedForm(template="app/formfield.html")
# Get base form class for the details model
BaseAppForm = forms.form_for_model(models.AppDetail, form=CustomForm)
using this template:
{% if errors %}
<ul class="errorlist">
{% for error in errors %}
<li>{{ error }}</li>
{% endfor %}
</ul>
{% endif %}
{% if field.required %}<span class="required">*</span>{% endif %}{{ text }}
{{ help_text }}
- template
- newforms
- rendering
WTForm is an extension to the django newforms library allowing
the developer, in a very flexible way, to layout the form
fields using fieldsets and columns
WTForm was built with the well-documented [YUI Grid CSS](http://developer.yahoo.com/yui/grids/) in
mind when rendering the columns and fields. This should make
it easy to implement WTForm in your own applications.
Here is an image of an [example form rendered with WTForm](http://www.gmta.info/files/wtform.png).
- newforms
- html
- css
- fieldset
- form
- yui
- rendering
- grid
- columns
- layout
7 snippets posted so far.