The default 500 handler does not take into consideration if the HTTP request made is an XMLHttpRequest. If it's an XHR, then it may not be a good idea to send back your default 500 HTML page.
To use this custom 500 handler, just add the following to your urls.py:
handler500 = 'my_project.my_app.views.my_500'
Yet another SQL logger, this time with color and tresholds.
By default it will only print a summary line (total time, query count) unless one of the tresholds (total time, query count, individual query time) was exceeded.
You may use LOG_COLORSQL_VERBOSE = True to get the raw SQL for all requests regardless of any configured tresholds.
In either case the middleware will highlight problematic areas in yellow or red.
If you don't like the colors you can either set your tresholds to really high values, edit the code,
or use a different middleware. :-)
Tired of scrolling through hundreds of lines of code where the indentation is maddening?
Here's a middleware class that prettifys your html markup so it's nice and consistently indented. Intended only for debugging, and I add it to the middleware stack conditionally on TEMPLATE_DEBUG. Requires BeautifulSoup.
When writing clean and easy-to-read templates, it's usually good to have structural template tags (e.g. {%for%}, {%if%}) alone on their own line with proper indentation.
When such a template is rendered, the resulting HTML will have blank lines in place of the template tags. The leading blank space used for indentation is also intact.
This template tag strips all empty and all-whitespace lines when rendering the template. Be careful not to apply it when not intended, e.g. when empty lines are wanted inside PRE tags.
Decorator to make a view only accept requests from AJAX calls. Usage::
@require_xhr()
def my_view(request):
# Returns data
# ...
by [skam](http://skam.webfactional.com/)
[zope.testing](http://pypi.python.org/pypi/zope.testing/) is a test framework and test runner, similar to the django test runner and nose.
This snippet is a [Layer](http://pypi.python.org/pypi/zope.testing/3.5.1#layers) class which you can assign as a layer attribute of your test suite to initialise and clean up the django test environment appropriately and to reset the test database between tests.
for example:
tests/suite.py
import unittest
from zope.testing import doctest
def test_suite():
suite = doctest.DocFileSuite("models.txt")
suite.layer = DjangoLayer
return suite
runtests.py
import os
from zope.testing import testrunner
os.environ['DJANGO_SETTINGS_MODULE'] = 'project.settings'
defaults = [
'--path', 'tests',
'--tests-pattern', '^suite$',
'-c'
]
testrunner.run(defaults)
**This is a newforms field for OpenID 1 & 2.**
It normalizes and validates OpenID identifiers according to the [spec](http://openid.net/specs/openid-authentication-2_0.html#normalization):
* `xri://=joelwatts` to `=joelwatts`
* `joelwatts.com` to `http://joelwatts.com/`
* `www.joelwatts.com` to `http://joelwatts.com/`
An identifier that is well-formed, but not an OpenID (e.g. `example.com`), will cause a validation error.
Requires [Python OpenID Library](http://openidenabled.com/python-openid/) 2.x.x.
The Django docs show us how to give models a custom manager. Unfortunately, filter methods defined this way cannot be chained to each other or to standard queryset filters. Try it:
class NewsManager(models.Manager):
def live(self):
return self.filter(state='published')
def interesting(self):
return self.filter(interesting=True)
>>> NewsManager().live().interesting()
AttributeError: '_QuerySet' object has no attribute 'interesting'
So, instead of adding our new filters to the custom manager, we add them to a custom queryset. But we still want to be able to access them as methods of the manager. We could add stub methods on the manager for each new filter, calling the corresponding method on the queryset - but that would be a blatant DRY violation. A custom `__getattr__` method on the manager takes care of that problem.
And now we can do:
>>> NewsManager().live().interesting()
[<NewsItem: ...>]
Uses jsmin or jspacker to compact javascript files (usage example in [this blog post](http://pedro.valelima.com/blog/2008/jan/17/deploying-compacted-javascript-django/))
This mixin is intended for small lookup-style models that contain mostly static data and referenced by foreign keys from many other places. A good example is a list of Payment options in an e-shop that is referenced from Orders and is hitting database `order.payment` at least one time for an order.
The idea is to cache entire table in a dict in memory that will live for entire life of a whole process serving many requests.
The downside is that you need to restart the server when a cached lookup table changes.
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.
Based on the discussion at Empty Thoughts (http://blog.michaeltrier.com/2007/8/6/age-in-years-calculation) I built a quick and dirty custom filter.
Save this as a file in your "templatetags" folder. I called mine "calculate_age.py" and then in your template "{% load calculate_age %}" then use it, "{{ object.birthdate|age }}"
The built-in escape filter only works with certain characters. It works great in environments where you can declare your charset (UTF-8). However, not everything can handle anything outside of the ASCII charset.
This replaces all non-ASCII characters with their encoded value as `®` for ®, for example.