From my talk this morning at PyCon UK 2008: a very simple multiple user blog model with an admin interface configured to only allow people to edit or delete entries that they have created themselves, unless they are a super user.
Decorator, written for views simplification. Will render dict, returned by view, as context for template, using RequestContext. Additionally you can override template, returning two-tuple (context's dict and template name) instead of just dict. Usage: @render_to('my/template.html') def my_view(request, param): if param == 'something': return {'data': 'some_data'} else: return {'data': 'some_other_data'}, 'another/template.html'
which you would use like this: The item is {% if item|in_list:list %} in list {% else %} not in list {% endif %}
A simple decorator that requires a user to be logged in. If they are not logged in the request is examined for a 'authorization' header. If the header is present it is tested for basic authentication and the user is logged in with the provided credentials. If the header is not present a http 401 is sent back to the requestor to provide credentials. The purpose of this is that in several django projects I have needed several specific views that need to support basic authentication, yet the web site as a whole used django's provided authentication. The uses for this are for urls that are access programmatically such as by rss feed readers, yet the view requires a user to be logged in. Many rss readers support supplying the authentication credentials via http basic auth (and they do NOT support a redirect to a form where they post a username/password.) Use is simple: ` @logged_in_or_basicauth def your_view: ... ` You can provide the name of the realm to ask for authentication within.
Described more fully on [my blog](http://e-scribe.com/news/230), but the gist is: this model becomes a sort of mini-app in your admin, allowing you to record and track issues related to your other applications. Sorting still needs some work. UPDATED 2007-03-14: Fixed repeat in Admin.list_display (thanks, burly!); added Admin.list_filter; changed app list (why did I call that `PROJECTS`, anyway?) to omit "django.*" apps
When debugging AJAX with Firebug, if a response is 500, it is a pain to have to view the entire source of the pretty exception page. This is a simple middleware that just returns the exception without any markup. You can add this anywhere in your python path and then put it in you settings file. It will only unprettify your exceptions when there is a XMLHttpRequest header. Tested in FF2 with the YUI XHR. Comments welcome. EDIT: I recently changed the request checking to use the is_ajax() method. This gives you access to these simple exceptions for get requests as well (even though you could just point your browser there).
I put this in a file called auth.py, then referenced it in the settings.py like so: AUTHENTICATION_BACKENDS = ('myproject.myapp.auth.ActiveDirectoryBackend',) This has been tested on my office network, with the following setup: Django 0.96 Python 2.4.4 python-ldap Fedora Core 5 (On the server hosting Django) AD Native Mode 2 Windows 2003 AD servers
A subclass of `HttpResponse` which will transform a `QuerySet`, or sequence of sequences, into either an Excel spreadsheet or CSV file formatted for Excel, depending on the amount of data. All of this is done in-memory and on-the-fly, with no disk writes, thanks to the StringIO library. **Requires:** [xlwt](http://pypi.python.org/pypi/xlwt/) **Example:** def excelview(request): objs = SomeModel.objects.all() return ExcelResponse(objs)
Sometimes it's useful to dispatch to a different view method based on request.method - e.g. when building RESTful APIs where GET, PUT and DELETE all use different code paths. RestView is an extremely simple class-based generic view which (although it's a stretch to even call it that) which provides a simple mechanism for dividing up view logic based on the HTTP method.
Peeping middleware, that replaces active user to another one for current http request. Admin permissions required to activate, so you can place this snippet even on the production server. Very useful for debugging purposes. Wish it to be part of Django. How to use: Put this middleware after all other middlewares in the list. Then just add ?as_user=username or &as_user=username to the url, where username is the name of user whose views you want to see.
Use: ... <head> ... {% gmap-script %} ... </head> ... <body> ... {% gmap name:mimapa width:300 height:300 latitude:x longitude:y zoom:20 view:hybrid %} Message for a marker at that point {% endgmap %} ... </body>
template tag for producing tag clouds for a given model, using django-tagging application: http://code.google.com/p/django-tagging/ Sample: http://skam.webfactional.com/tags/ Usage: {% tags_cloud_for_model articles.Article as object_list %} {% tags_cloud_for_model articles.Article as object_list step 6 %}
Drop this package wherever you want, import the decorator, and use it with one argument to decorate any function you want (`@xmlrpc('pingback.ping')`). That function is now available on your XML-RPC interface, available through this view. Make sure to provide the view (`call_xmlrpc`) with a URL so that it's accessible.
I'm a big fan of Markdown, and often set up models to automatically apply it to certain fields before saving. But that's not really flexible, because if I then distribute the code someone else might want to use reStructuredText or Textile or whatever, and then they have to hack my code. So here's a function which looks for a setting called `MARKUP_FILTER` and, based on what it finds there (see the docstring for what it looks at), chooses a text-to-HTML conversion function and applies it to a piece of text. Since Textile, Markdown and reStructuredText all support various useful options, it has the ability to pick up arbitrary keyword arguments and pass them through.
This is an excerpt from the form code used on this site; the tricky bit here is making the `choices` for the `language` field get filled in dynamically from `Language.objects.all()` on each form instantiation, so that new languages can be picked up automatically. It also adds a blank choice at the beginning so that users can't accidentally ignore the field and incorrectly end up with whatever Language was first in the list. If you use this, always remember that you have to call the superclass `__init__` _before_ you set your dynamic choices, and that you need to accept `*args` and `**kwargs` so you can pass them to it. In theory, `ModelChoiceField` will solve this, but it still seems to be a bit buggy.