Just a quick tip on how to use the pyfacebook django middleware as a decorator since you probably dont want to add the facebook object to all incoming requests.
This snippet provides a uuid field for models, improving on the work in http://www.djangosnippets.org/snippets/335/
This snippet updates http://www.djangosnippets.org/snippets/383/ for Django 1.0+, and adds support for sqlite3. Original snippet text: A CompressedTextField to transparently save data gzipped in the database and uncompress at retrieval.
This cache_page decorator can be used in replacement to Django's django.views.decorators.cache.cache_page. It resolves two problems: - invalidation (its cache key is not dependent of header nor request, then you can use model signals (or method 'put' in Google App Engine) to invalidate a URL or a list of them) - easier to scale (can be used at once memcached server by many differente servers) Feel free to show me where it can have problems or limitations. **Updated and improved a lot**
Install [sqlparse](http://code.google.com/p/python-sqlparse/) with `easy_install sqlparse` and then you can easily debug the SQL like this: def view(request): data = MyModel.objects.filter(something__very=complex) print_sql(data) ... Inspired by [Simon Willison](http://simonwillison.net/2009/Apr/28/)
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.
Renders a view to an email. You need to set all of the required settings for email support.
This snippet is for [django-flag](http://code.google.com/p/django-flag/) Pinax app to make it generic moderator for any content model. You don't need to modify neither your model nor your views to moderate your flagged content objects.
If you want all the objects in your models' admin interface to have a direct link to their databrowse page (just like the *history* link).. follow these steps: 1) copy the *change_form.html* admin template in mytemplates/admin/ 2) edit *change_form.html* by adding this code right next to (before or after) the following line (=the history button markup): `<li><a href="history/" class="historylink">History</a></li>` 3) Make sure that all of you models are registered with [databrowse](http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/) That's it. Obviously if you don't want ALL the models to have this link, you should use a different recipe, for example this one: [http://www.djangosnippets.org/snippets/1016/](http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/)
If you would like to see the latest queries you have done when running a unittest, this is not so easy. You have to initialize the queries list and set DEBUG to True manually. Then you have to figure out a way to print the queries you want to see just now and format them. I.e., monitoring queries when doing TDD is a bit of a hassle, and this should help. This little helper does all this for you; your UnitTest only needs to import django.db.connection and store the current length (offset) of the queries list. Then, using Python's coroutine functionality, all you have to do is send that offset to the QueryPrinter coroutine (which you can, for example, initialize as a global variable or a class variable of your UnitTest) and you get the latest SQL printed as a simple table.
Let's say you have a dataset and you want to render a page with sections/subsections/subsubsections down to some arbitrary depth and with arbitrary keys. For example, you might want to show cars broken out by year/price_range or price_range/year or price_range/manufacturer/model. The outliner template tag allows you to support multiple breakdowns of your data in a DRY sort of way. In order to use it, you supply four things: 1. a template for surrounding each subsection (think turtles all the way down) 2. a queryset (really anything iterable) 3. sectionizer dictionary/objects (see sample code, you must supply key_method) 4. inner html to render the lowest subsections The template provides the following: 1. It recursively uses each of your sectionizers' key methods to divvy up data sets. 2. It surrounds each section with templates of your choosing. 3. It renders the inner template for all the "leaf" elements of your tree. 4. It supplies some handy context vars for things like depth and outline ids. What this is not: 1. this is not for arbitrary tree data--think of the tree as fixed depth 2. this is not as simple as the regroup tag--if you have a concrete organization to your data, you should keep it simple and hand-code your templates
DEPRECATED: Django has cookie based messages since version 1.2 This messages stores messages for the user in a cookie. I prefer this to session based messages, because the session column is a hot spot in the database if one user works with several browser tabs/windows.
I wanted to store ipv4 and ipv6 ip's in django but I wanted to use the postgresql inet network field type: http://www.postgresql.org/docs/8.3/static/datatype-net-types.html and I wanted to use IPy.py IP objects in python. I followed these very helpful examples along with the django documentation: http://vaig.be/2009/03/numeric-ip-field-for-django.html http://www.djangosnippets.org/snippets/1381/ It took me awhile to figure out how this works (not that I completely understand it now..) and figured I would share it. If anyone finds problems with this or can make it better I will definitely use it.
ACNField - Australian Company Number Form Field ABNField - Australian Business Number Form Field Any feedback / Improvements Appreciated.
You need the mini-detector middleware installed [http://www.iterasi.net/openviewer.aspx?sqrlitid=-e2dfig9w0yrclxaigp-uw](http://www.iterasi.net/openviewer.aspx?sqrlitid=-e2dfig9w0yrclxaigp-uw). This is a drop in replacement to render_to_response. When using mini_render_to_response it will try to load a version of your template with mini at the end. For example "home_mini.html" instead of "home.html". If it doesn't find the _mini version it falls back to the regular "home.html" version of your template. Easy way to maintain a "small screen" version of your templates for iPhone or other small screen devices.