This is an improvement on other ButtonAdmin implementations. A few features : It allows you to specify whether button appears on change form or change list; whether the form is to be saved before the resulting function is called; whether the button should be displayed Look at the bottom of the snippet for usage. And make sure you admin urls are enabled using (r'^admin/', include(admin.site.urls)) instead of the old method
Date-based generic views do not provide pagination by default but Django is very extensible. It provides a Paginator that takes care of pagination. Since date based views usually order by descending order ie from latest entry to the oldest, I used a queryset to order the items (on a field called 'date_pub') and then pass this queryset to the paginator which takes care of the pagination.
Temporary and permanent view redirect decorators. Simplifies views that always redirect to a specific or configured url. You can use the reverse() function (or any other runtime-required lookup) via `lambda` to define the redirect url.
Useful if you can make sure your files will never collide unless they share the same contents. You point to the storage parameter when you declare an ImageField and use the hashed_path class method (seemed to make sense to bundle it with the class) to build a custom upload_to method that has to generate the path based on the file contents. Combining both will allow you to deduplicate files uploaded repeatedly.
This is a decorator which essentially replaces the decorated view with a view that always raises `Http404` (File Not Found) when `settings.DEBUG` is set to True.
signal handler for checking unique_together manually. Also available via django-tools: http://code.google.com/p/django-tools/
This was a wild experiment, which appears to work! One model holds all the data, from every object version ever to exist. The other model simply points to the latest object from its gigantic brother. All fields can be accessed transparently from the little model version, so the user need not know what is going on. Coincidently, Django model inheritance does exactly the same thing, so to keep things insanely simple, that's what we'll use: class EmployeeHistory(FullHistory): name = models.CharField(max_length=100) class Employee(EmployeeHistory): pass That's it! Django admin can be used to administer the `Employee` and every version will be kept as its own `EmployeeHistory` object, these can of course all be browsed using the admin :-) This is early days and just a proof of concept. I'd like to see how far I can go with this, handling `ForeignKey`s, `ManyToManyField`s, using custom managers and so on. It should all be straightforward, especially as the primary keys should be pretty static in the history objects... *updated 3 August 2009 for Django 1.1 and working date_updated fields*
To activate, store this file as `mysite/winauth.py` and use in settings.conf: AUTHENTICATION_BACKENDS = ('mysite.winauth.DomainControllerAuthBackend',) Needs [pywin32 extensions](http://sourceforge.net/projects/pywin32/) installed (and obviously only runs on Windows).
**Note**: The `--failfast` argument in Django since version 1.2 does this. Use this snippet for earlier versions. If a large number of your unit tests get "out of sync", it's often annoying to scan through a large number of test failures which overflow the terminal window's scroll buffer. This library strictly stops after the first failure in a doctest suite. If you're testing multiple applications, it also stops after the first test suite with failures in it. So effectively you'll get one failure at a time. This code has been tested with doctests only so far. You can also fetch the latest source from [my repository](http://trac.ambitone.com/ambidjangolib/browser/trunk/test/).
I've been working with a data set where a single object won't fit into memcached's 1 Mb slab limit. The two functions have been useful to me for debugging the size of the data structure once pickled, and if said pickled data structure is greater than 1 Mb. These functions assume CACHE_BACKEND is memcached, obviously.
Because BaseCommand catches all CommandError exceptions and turns them into nicely formatted strings before calling sys.exit(1), it can be tricky to properly test failure. Normally, this is great, but it makes testing that a command fails when we expect to a little harder. That's where this snippet comes in. It redirects sys.stderr to an instance StringIO where we can monitor what's output and catches the BaseException raised by sys.exit(1). Form here, it's trivial to test that a management command fails exactly as you'd expect it to.
Template designers often require access to individual form fields or sets of form fields to control complex form layouts. While this is possible via looping through form fields in the template it can lead to ugly logic inside templates as well as losing the ability to use the as_* form rendering methods. This class when mixed into a form class provides hooks for template designers to access individual fields or sets of fields based on various criteria such as field name prefix or fields appearing before or after certain fields in the form, while still being able to use the as_* form rendering methods against these fields.
Ok, I just took [wolever](http://djangosnippets.org/users/wolever/)'s snippet at [http://djangosnippets.org/snippets/1926/](http://djangosnippets.org/snippets/1926/) and added template variable/filter support for range values. For instance, you could write something like this: `{% mkrange 1 tool_page.paginator.num_pages|add:"1" as page_range %}` I'm just learning python and django, so any advice would be appreciated.
This is an inclusion tag that can be used to pull in posts from any feed to a template. It doesn't do any caching, so it may slow down page load times. Depends on [Feedparser](http://www.feedparser.org). Template usage: {% pull_feed 'http://www.djangosnippets.org/feeds/latest/' 3 %}
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.