Snippet List
This utility makes a text dump of a model instance, including objects related by a forward or reverse foreign key. The result is a hierarchical data structure where
* each instance is represented as a list of fields,
* each field as a (<name>, <value>) tuple,
* each <value> as a primitive type, a related object (as a list of fields), or a list of related objects.
See the docstring for examples.
We used this to make text dumps of parts of the database before and after running a batch job. The format was more useful than stock `dumpdata` output since all related data is included with each object. These dumps lend themselves particularly well for comparison with a visual diff tool like [Meld](http://meldmerge.org/).
- serialize
- dump
- model
- instance
Out of the box, Django e-mail fields for both database models and forms only accept plain e-mail addresses. For example, `[email protected]` is accepted.
On the other hand, full e-mail addresses which include a human-readable name, for example the following address fails validation in Django:
Joe Hacker <[email protected]>
This package adds support for validating full e-mail addresses.
**Database model example**
from django import models
from full_email.models import FullEmailField
class MyModel(models.Model):
email = FullEmailField()
**Forms example**
from django import forms
from full_email.formfields import FullEmailField
class MyForm(forms.Form):
email = FullEmailField(label='E-mail address')
I maintain this code in a [GitHub gist](https://gist.github.com/1505228). It includes some unit tests as well.
- forms
- model
- email
- validation
- orm
- database
You can use this cache backend to cache data in-process and avoid the overhead of pickling. Make absolutely sure you don't modify any data you've stored to or retrieved from the cache. Make deep copies instead if necessary.
The backend is basically identical to Django's stock locmem cache (as of r15852 - after 1.3rc1) with pickling removed. It has been tested with that specific Django revision, so basically it's >=1.3 compatible.
See [Django ticket #6124](http://code.djangoproject.com/ticket/6124) for some background information.
- cache
- pickle
- backend
- locmem
- memory
- process
When deleting objects in Django's admin interface, it lists other objects which would be deleted and asks for confirmation. This snippet does the same programmatically.
The snippet works in Django 1.3 (more specifically, revision 14507 or later). It uses Django internals which are not a part of the public API, so this might not work with future versions.
Usage:
`polls/models.py`:
from django.db import models
class Poll(models.Model):
question = models.CharField(max_length=200)
def __unicode__(self):
return self.question
class Choice(models.Model):
poll = models.ForeignKey(Poll)
choice = models.CharField(max_length=200)
def __unicode__(self):
return '%s %s' % (self.poll, self.choice)
`$ ./manage.py shell`
>>> from polls.models import Poll, Choice
>>> from datetime import datetime
>>> from pprint import pprint
>>> poll1 = Poll.objects.create(question='Me?')
>>> Choice.objects.create(poll=poll1, choice='Yes')
>>> Choice.objects.create(poll=poll1, choice='No')
>>> poll2 = Poll.objects.create(question='Really?')
>>> Choice.objects.create(poll=poll2, choice='Yes')
>>> Choice.objects.create(poll=poll2, choice='No')
>>> pprint(get_related(Poll.objects.all()))
{<class 'polls.models.Poll'>: [<Poll: Me?>, <Poll: Really?>],
<class 'polls.models.Choice'>: [<Choice: Me? Yes>,
<Choice: Me? No>,
<Choice: Really? Yes>,
<Choice: Really? No>]}
So you need to change some settings when running an individual test in a test case. You could just wrap the test between `old_value = settings.MY_SETTING` and `settings.MY_SETTING = old_value`. This snippet provides a helper which makes this a bit more convenient, since settings are restored to their old values automatically.
Example usage:
class MyTestCase(TestCase):
def test_something(self):
with patch_settings(MY_SETTING='my value',
OTHER_SETTING='other value'):
do_my_test()
- settings
- testing
- unittest
This server-side middleware implements some of the functionality in the Yahoo
User Interface Loader component. YUI JavaScript and CSS modules requirements
can be declared anywhere in the base, inherited or included templates, and the
resulting, optimized `<script>` and `<link rel="stylesheet">` tags are inserted at
the specified position of the resulting page.
Requirements may be specified in multiple locations. This is useful when zero
or more components are included in the HTML head section, and inherited and/or
included templates require possibly overlapping sets of YUI components in the
body across inherited and included templates. All tags are collected in the
head section, and duplicate tags are automatically eliminated.
The middleware understands component dependencies and ensures that resources
are loaded in the right order. It knows about built-in rollup files that ship
with YUI. By automatically using rolled-up files, the number of HTTP requests
is reduced.
The default syntax looks like HTML comments. Markup for the insertion point is
replaced with `<script>` and `<link>` tags:
<!-- YUI_init -->
Component requirements are indicated, possibly in multiple locations, with the
`YUI_include` markup. It is removed from the resulting page by the
middleware. Example:
<!-- YUI_include fonts grids event dragdrop -->
Non-minified and compressed versions are requested, respectively, by:
<!-- YUI_version raw -->
<!-- YUI_version debug -->
Example:
<html><head>
<!-- YUI_init -->
<!-- YUI_include dom event -->
</head><body>
<!-- YUI_include element selector reset fonts base -->
</body></html>
Renders:
<html><head>
<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.5.1/build/reset-fonts/reset-fonts.css" />
<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.5.1/build/base/base-min.css" />
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/yahoo-dom-event/yahoo-dom-event.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/element/element-beta-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/selector/selector-beta-min.js"></script>
</head><body>
</body></html>
The markup format can be customized with global Django settings. Example:
YUI_INCLUDE_PREFIX_RE = r'{!'
YUI_INCLUDE_SUFFIX_RE = r'!}'
would change markup to e.g. `{! init !}` and `{! include dom event !}`.
The base URL is customized with the `YUI_INCLUDE_BASE` setting, e.g.:
YUI_INCLUDE_BASE = 'http://localhost:8000/yui/build/'
To remove the XHTML trailing slash from the `<link>` tag, use:
YUI_INCLUDE_CSS_TAG = '<link rel="stylesheet" type="text/css" href="%s">'
See also the [home page for this module](http://trac.ambitone.com/ambidjangolib/wiki/YUI_include).
We had some fun today on the #django IRC channel searching and counting through past logs for people saying "thanks" to [a known very helpful person](http://djangopeople.net/magus/).
Here's a unix shell script for checking your own score if you're using Pidgin and have logging turned on.
Replace ".purple" with ".gaim" in the script if you're using Gaim (an older version of Pidgin).
- log
- help
- irc
- thanks
- score
This middleware replaces the behavior of the APPEND_SLASH setting in the CommonMiddleware. Please set `APPEND_SLASH = False` and `SMART_APPEND_SLASH = True` if you are going to use this middleware.
In your URL patterns, omit the trailing slash for URLs you want accessible without the slash. Include the slash for those URLs you wish to be automatically redirected from an URL with the slash missing.
If a URL pattern exists both with and without a slash, they are treated as two distinct URLs and no redirection is done.
Example
urlpatterns = patterns('some_site.some_app.views',
(r'^test/no_append$','test_no_append'),
(r'^test/append/$','test_append'),
(r'^test/distinct_url$', 'view_one'),
(r'^test/distinct_url/$', 'view_two'), )
Behavior of URLs against the above patterns with SMART_APPEND_SLASH enabled:
http://some_site/test/no_append → test_no_append()
http://some_site/test/no_append/ → 404
http://some_site/test/append → http://some_site/test/append/
http://some_site/test/append/ → test_append()
http://some_site/test/distinct_url → view_one()
http://some_site/test/distinct_url/ → view_two()
This module is also available [in our SVN repository](http://trac.ambitone.com/ambidjangolib/browser/trunk/middleware/common.py).
When writing clean and easy-to-read templates, it's usually good to have structural template tags (e.g. {%for%}, {%if%}) alone on their own line with proper indentation.
When such a template is rendered, the resulting HTML will have blank lines in place of the template tags. The leading blank space used for indentation is also intact.
This template tag strips all empty and all-whitespace lines when rendering the template. Be careful not to apply it when not intended, e.g. when empty lines are wanted inside PRE tags.
- template
- html
- strip
- empty
- blank
**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/).
This snippet uses signals to replace the `contrib.auth.models.User.set_password()` function with one that uses *crypt* instead of *sha1* to hash the password.
*Crypt* is of course cryptographically inferior to *sha1*, but this may be useful for interoperability with legacy systems e.g. when sharing a user authentication database with unix, a MTA etc.
For some reason the `User` class doesn't emit a `class_prepared` signal, which would otherwise be a better choice here. That's why I had to resort to patching each `User` instance separately.
A clean way to deploy this snippet is to place it in the `models.py` of an otherwise empty app, and add the app in `settings.INSTALLED_APPS`. The order of `INSTALLED_APPS` doesn't matter since we're patching instances, not classes.
If you work with Django like I do, you have a separate installation or Subversion check-out of Django for each of your projects. Currently each one of them eats 22 MB of disk space.
This utility hard-links all identical files between copies of Django. They can even be different versions or svn revisions, and you'll still be able to free a good amount of disk space.
Run this every now and then if you update installed copies of Django or add new ones.
This utility is available also [here](http://trac.ambitone.com/ambidjangolib/browser/trunk/hardlink_django_instances/hardlink_django_instances.py).
When using a JavaScript WYSIWYG editor widget for text area content, the resulting HTML should be sanitized so no unallowed HTML tags (esp. script tags) are present.
The [BeautifulSoup](http://www.crummy.com/software/BeautifulSoup/) library handles HTML processing in the solution presented above, so you should place it in the Python path.
The snippet also assumes that you have [the Dojo Toolkit](http://dojotoolkit.org/) and its Editor2 widget loaded on your page.
**Note**: this snippet was originally written for use with Dojo Toolkit 0.4, and it hasn't been updated for 0.9 or 1.0.
- forms
- html
- wysiwyg
- dojo
- security
- sanitize
I once needed to convert a Django project from PostgreSQL to SQLite. At that time I was either unaware of manage.py dumpdata/loaddata or it they didn't yet exist. I asked for advice on the #django IRC channel where ubernostrum came up with this plan:
simple process:
1) Select everything.
2) Pickle it.
3) Save to file.
4) Read file.
5) Unpickle.
6) Save to db.
:)
Or something like that.
First I thought it was funny, but then started to think about it and it made perfect sense. And so dbpickle.py was born.
I've used this script also for migrating schema changes to production databases.
For migration you can write plugins to hook on dbpickle.py's object retrieval and saving. This way you can add/remove/rename fields of objects on the fly when loading a dumped database. It's also possible to populate new fields with default values or even values computed based on the object's other properties.
A good way to use this is to create a database migration plugin for each schema change and use it with dbpickle.py to migrate the project.
See also [original blog posting](http://akaihola.blogspot.com/2006/11/database-conversion-django-style.html) and [my usenet posting](http://groups.google.com/group/django-users/browse_thread/thread/6a4e9781d08ae815/c5c063a288483e07#c5c063a288483e07) wondering about the feasibility of this functionality with manage.py dumpdata/loaddata.
See [trac site](http://trac.ambitone.com/ambidjangolib/browser/trunk/dbpickle/dbpickle.py) for version history.
- dump
- database
- migration
- load
- pickle
akaihola has posted 14 snippets.