Snippet List
[A comment on a recent blog entry of mine](http://www.b-list.org/weblog/2008/feb/25/managers/#c63422) asked about a setup where one model has foreign keys pointing at it from several others, and how to write a manager which could attach to any of those models and query seamlessly on the relation regardless of what it's named.
This is a simple example of how to do it: in this case, both `Movie` and `Restaurant` have foreign keys to `Review`, albeit under different names. However, they both use `ReviewedObjectManager` to provide a method for querying objects whose review assigned a certain rating; this works because an instance of `ReviewedObjectManager` "knows" what model it's attached to, and can introspect that model, using [Django's model-introspection API](http://www.b-list.org/weblog/2007/nov/04/working-models/), to find out the correct name to use for the relation, and then use that to perform the query.
Using model introspection in this fashion is something of an advanced topic, but is extremely useful for writing flexible, reusable code.
**Also**, note that the introspection cannot be done in the manager's `__init__()` method -- at that point, `self.model` is still `None` (it won't be filled in with the correct model until a bit later) -- so it's necessary to come up with some way to defer the introspection. In this case, I'm doing it in a method that's called when the relation name is first needed, and which caches the result in an attribute.
- managers
- models
- introspection
When I initially set up my blog, I put together the archives with URL patterns like so:
* `/weblog/2007/` goes to `archive_year`
* `/weblog/2007/08/` goes to `archive_month`
* `/weblog/2007/08/24/` goes to `archive_day`
* `/weblog/2007/08/24/some-slug` goes to `object_detail`
The same patterns held for links, only the prefix was `/links/` instead of `/weblog/`.
For a forthcoming redesign/rewrite, I'm switching to using abbreviated month names (e.g., "aug", "sep", "oct", etc.) in the URLs, which means I need to redirect from the old-style URLs to the new. This snippet is the solution I hit upon. Two things are notable here:
1. Each one of these views uses [reverse()](http://www.djangoproject.com/documentation/url_dispatch/#reverse), called with the appropriate arguments, to generate the URL to redirect to. This means URLs don't have to be hard-coded in.
2. Each view takes an argument -- `object_type` -- which is used to generate the view name to pass to `reverse`, meaning that only one set of redirect views had to be written to handle both entries and links.
This is just one of many handy tricks `reverse` can do :)
Based heavily on [snippet #119](/snippets/119/), this is an all-in-one function which applies Markdown and typogrify, and adds Pygments highlighting (selected from a class name or by having Pygments guess the language) to any `<code>` elements found in the text.
It also adds some niceties for picking up useful arguments to Markdown and Pygments, and registers itself as a markup filter with the `template_utils` formatter.
Requirements:
* [BeautifulSoup](http://www.crummy.com/software/BeautifulSoup/)
* [Pygments](http://pygments.org/)
* [python-markdown](http://www.freewisdom.org/projects/python-markdown/)
* [template_utils](http://code.google.com/p/django-template-utils/)
* [typogrify](http://code.google.com/p/typogrify/)
- pygments
- markup
- markdown
- typogrify
In response to [#366](/snippets/366/), this is a subclass of the `CommentModerator` class from `comment_utils` which does nothing except email the "owner" of an object whenever a new comment is posted on it; all other moderation options remain inactive.
When you have two models joined by a foreign key, it's common to want to retrieve a set of objects from the "target" of the foreign key based on whether there are any objects "pointing" to them. This snippet demonstrates how to do so, using the `extra` method of the default model manager.
Note that this is probably more efficient than using two ORM methods (e.g., selecting all values from one table, and using an `id__in` lookup on the other) since it does the whole thing in one query and avoids instantiating any intermediate objects.
A slightly improved version of [snippet #195](/snippets/195/) which keeps the logic but makes use of the `simple_tag` decorator to drastically simplify the code.
For an alternative to this sort of tag, check out the media context processor in my [template_utils app](http://code.google.com/p/django-template-utils/).
- template
- tag
- media
- simple_tag
**Before using this snippet**, please note that it's largely been superseded by [comment_utils](http://code.google.com/p/django-comment-utils/), which includes a more featureful and extensible version of this system, particularly with respect to additional moderation options and useful things like email notifications of comments.
Once upon a time I hacked the copy of `django.contrib.comments` I'm using on my blog, so that I could have comments get set to `is_public=False` if posted more than 30 days after the entry's publication, and to add Akismet spam filtering. I've regretted it ever since, because it's made upgrading my copy of Django a pain.
So here's an improved version which doesn't require hacking directly on Django. To use it, you'll need to do a few things:
1. Grab the [Python Akismet module](http://www.voidspace.org.uk/python/modules.shtml#akismet) and install it somewhere on your server.
2. In your settings file, add `AKISMET_API_KEY`, and make sure its value is a valid Akismet key. If you don't have an Akismet key, you can [get one at wordpress.com](http://wordpress.com/api-keys/).
3. Put this code -- both the function and the dispatcher calls -- somewhere in your project that's _guaranteed_ to be imported early (until this code is executed, the moderation function won't be set up to listen for comments posting).
To have comments on a certain type of object (say, weblog entries) automatically go into moderation when the object reaches a certain age, define a method on that object's model called `comments_open`, and have it return `False` when comments should be auto-moderated.
- akismet
- comments
- moderation
This is a pretty straightforward bit of code for getting the most-commented objects of a particular model; just drop it into a custom manager for that model, and you should be good to go. Check the docstring for how to make it look at `Comment` instead of `FreeComment`.
- managers
- comments
- popularity
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.
- markup
- markdown
- textile
- restructuredtext
Jonathan Buchanan's [Django tagging](http://code.google.com/p/django-tagging/) application is the best thing since sliced bread, and makes adding generic tagging to any model trivially easy. But you can make it just a tiny bit easier to use by setting up a property on your model for handling the tags.
Once you've set this up, you can access and set tags in a fairly natural way:
>>> obj = MyModel.objects.get(pk=1)
>>> obj.tags = 'foo bar'
>>> obj.tags
[<Tag: foo>, <Tag: bar>]
And remember that `obj.tags` will return a `QuerySet`, so you can do filtering on it.
This is, I think, a slightly cleaner implentation of what [snippet 31](/snippets/31/) is trying to do; by starting off with a dictionary containing the things we want to look for, and using a list comprehension to kill anything which comes out of the form as `None`, we can avoid some of the intermediate data structures the other snippet was using, and hopefully get better performance.
This is also quite a bit more maintainable, because supporting additional options now only requires adding a new key/value pair to `qdict`.
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.
This is part of the user-registration code used on this site (see [the django-registration project on Google Code](http://code.google.com/p/django-registration/) for full source code), and shows a couple of interesting tricks you can do with manager methods.
In this case there's a separate `RegistrationProfile` model used to store an activation key and expiration time for a new user's account, and the manager provides a couple of useful methods for working with them: `create_inactive_user` creates a new user and a new `RegistrationProfile` and emails an activation link, `activate_user` knows how to activate a user's account, and `delete_expired_users` knows how to clean out old accounts that were never activated.
Putting this code into custom manager methods helps a lot with re-use, because it means that this code doesn't have to be copied over into different views for each site which uses registration, and also makes more sense in terms of design, because these are methods which need to "know about" the model and work with it, and so they belong in a place close to the model.
This is a method from the custom manager for the Snippet model used on this site; the basic idea is to be able to ask for the top `n` "foo", where "foo" is something related to Snippet. For example, you can use `top_items('tag')` to get the top Tags ordered by how many Snippets are associated with them.
I have a feeling that I could get this down to one query, but haven't yet put in the time for it.
- snippets
- sql
- managers
- group-by
ubernostrum has posted 14 snippets.