ReportBug() allows you to send exception details to you, via email, but with
far more detail than the default. It uses the base function for the traceback
used by the Debug mode on Django.
This is a first revision, so the emails have no decent styling, but it works,
and shows scope on each stack.
It will automatically generate a random serial number per error, so you can track them
in your favourite bug tracker. It also has support for you to pass it a request variable,
so the mail would also contain request/response context. Again, i'm gonna look into doing
this manually in the future.
Hope this helps!
Mwah.
Cal Leeming.
cal [at] simplicitymedialtd.co.uk.
Simplicity Media Ltd.
- email
- debug
- mail
- exception
- report
- bug
- mail_admins
- reportbug
This is the `local_settings.py` trick extended to Django templates.
Sometimes you need to insert some arbitrary code in the HTML of the production site for external service integration like uservoice, typekit, google analytics... You don't want to put this code into source control because some other sites using the same source code may not need it.
So, add this template tag to your collection and do:
{% try_to_include 'head.html' %}
And leave `head.html` out of source control. Then when you need to include some code on your production site, just add the `head.html` template with the desired code to include.
I usually have one included template in the header for extra `<head>` tags, and one in the footer for extra javascript.
Node that the included template is rendered against the current context. If the template doesn't exist, an empty string is returned.
Also see the [full blog post](http://bruno.im/2009/dec/07/silently-failing-include-tag-in-django/) about this tag.
- templatetag
- include
- silent
There are several snippets that provide a basic caching decorator for functions and methods (e.g. #202, #1130, etc.). The `Cacheable` class in this snippet extends them by (*if you don't see an unordered list below, the Markdown on this site is still broken...*):
- Specifying how cache keys are determined in one of two general, flexible ways.
- Exposing a few extra methods for (re)setting and deleting the cached value transparently. Given these methods, cache key management should follow DRY: keys are specified once (and only once) at instantiation time, without having to be repeated at later interactions with the cache.
- Adding a variant for cacheable properties.
Unlike some other snippets, the way cache keys are generated must be explicitly specified by the client; there is no automagic key generation for arbitrary `func(*args, **kwds)` calls (but can be added if desired). The reason is that all usual serialization approaches (`func.__name__`/`func.__module__`, `repr`, `pickle`, etc.) are generally fragile, unsafe, inefficient or all of the above. Explicit is better than implicit in this case.