Limit rate request decorator for view. Authenificated user can't request decorated view often then timeout. Usage: @limit_request_rate(time_beetween_request_sec) def my_view(request): ... get_cell_value from [here](http://code.activestate.com/recipes/439096/)
This template tag was built to be used in web applications that are permission based. It renders the html for an html link tag if the user has permissions to access the view (if not, returns an empty string). It also checks if the current token is the active url address and, if so, adds class="active" to the html link for presentation purposes. Example usage: 1. {% url home as home_url %} {% get_link_if_allowed home_url "Home" %} 2. {% url project_dashboard project.id as project_dashboard_url %} {% get_link_if_allowed project_dashboard_url "Projects" %}
I was in need to have pluggable components that all have more or less some media files. I didn't want to pollute my config with dozens of media paths so I wrote this custom command that copies contents `<appdir>/app_media` to your `MEDIA_ROOT/<appname>` path. In template you will refer your media files like `{{MEDIA_URL}}/appname/<path to media>`
A python implementation of the old MySQL PASSWORD() function. This is insecure. There is a reason MySQL changed this in version 4.1. Use it only if you have to!
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/)
Truncates string to a given number of characters.
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.