The "testdata" tag allows you to inline test data into your templates, similar in spirit to Python doctests. There are two sections--the test data and the actual template to be rendered. In non-test mode your template renders normally from whatever views call it, and there is very little overhead to skip over the test data section (happens at parse time).
Here are the goals:
1. Provide convenient way to test templates without surrounding infrastructure.
2. Make templates be self-documenting in terms of expected data.
3. Allow insertion of test data at arbitrary places in template structure.
Hello-world looks like this:
{% load handytags %}
{% testdata %}
{
'greeting': 'Hello',
'planet': 'World',
}
{% --- %}
{# This is where the actual template begins #}
{{ greeting }} <b>{{ planet }}</b>
{% endtestdata %}
To invoke it, set up urls.py with something like this:
url(r'^testdata/(?P<template_path>.*)', test_template)
def test_template(request, template_path):
context = {'testdata_use': True}
# put request vars into context to help choose
# which test data we want to render
for field in request.GET:
context[field] = request.GET[field]
return render_with_request(template_path, context, request)
Then call:
http://127.0.0.1:8000/testdata/hello_world.html
Features:
1. The testdata tag's rendering will expose missing variables a bit more aggressively than Django normally does.
2. You have the full power of the template language to set the test data (which ultimately gets eval'ed as a Python expression).
3. As mentioned above, the tag is mostly unobtrusive.
Limitations/caveats:
1. Right now the only data format I support is pure Python, but the tag could be modified pretty easily to support JSON or YAML.
2. The VerboseContext class is pretty heavy-handed--I really just want a hook into Django to tell it to render a section with more strictness about variables. Suggestions welcome.
3. You can put the testdata tag pretty much anywhere, but the normal rules apply...for example, if you are in a template that has the extend tag, you'll want
to put the testdata tag in individual blocks.
- templates
- testing
- doctest
- custom-template-tag
A simple tag to render breadcrumbs.
Usage:
{% load breadcrumbs %}
{% breadcrumbs "['Home','Home','home']" "['Articles','Articles','articles']" "['object','object','object.get_absolute_url']" %}
Loads up the template in "modules/breadcrumbs.html" and renders it with a list of items.
You can provide the tag either with plain text stuff and named urls as the third argument ( any more arguments per bracket-block is parsed as args / kwargs for the reverse() call ) or the object directly, and the script tries after failing the reverse() to resolve the provided arguments.
Have pun.
- django
- templatetag
- breadcrumbs
Decorates signals for executing only one time
Exemple usage :
from django.core.mail import EmailMultiAlternatives
from django.template.loader import render_to_string
from django.contrib.auth.models import User
@one
def user_welcome(sender, instance, created, **kwargs):
# Send a welcome email
if created == True and isinstance(instance, User):
instance.message_set.create(message=_(u"Ho, Welcome %s!" % instance))
subject, from_email, to = 'Welcome !', '[email protected]', instance.email
text_content = render_to_string('mail/welcome.html', { 'user': instance })
msg = EmailMultiAlternatives(subject, text_content, from_email, [to])
msg.send()