IMPORTANT UPDATE: the approach proposed in this article is bad. Read this one instead.

You can start building a user interface using Django’s awesome CRUD in a matter of seconds, for example with just this server side configuration:

    url(delete/(?P<pk>\d+)/$', 
        generic.DeleteView.as_view(model=YourModel),
        name='yourapp_yourmodel_delete'),

http://www.w3.org/TR/html-markup/syntax.html#syntax-attr-unquoted

Stuff like this: Can now be: That should save some bits !

http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-showmodaldialog

This specification of HTML5 provides an API for modal dialogs, we will not need a plugin anymore. This blog will present a cool HTML5 feature every now and then.

The previously announced backward compatibility break, although minor, has been released.

So don’t do pip update -U django-autocomplete-light unless you’re ready to change to in your autocomplete_light templates overrides (actually, that might not even be necessary now that I think of it).

You’ve been warned !

In the next week(s), django-autocomplete-light v 1.1.0 will succeed to v1.0.26. It will include commit 2c756a may be short but it will break your custom Autocomplete classes that generate custom HTML and custom django-autocomplete_light templates.

To upgrade to 1.1.0, please replace all <div> by <span> with class div in your custom Autocomplete classes and autocomplete_light templates. If you have any, examples can be seen in commit d50fd which fixes some tests (thanks continuous integration provided travis !).

Asserting that signals were sent properly can be a bit tricky: they must be sent in a particular order with specific arguments.

Fortunately, mock-django provides plenty of cool features, including a nice signal receiver mock. The only problem with mock-django is that it’s not documented. So I had to reverse-engineer and here’s what I’ve found: the best way to test a signal is to use the call_args_list property of the receiver mock.

ZODB is an object oriented database for Python, or “NoSQL” database. In one sentence it resumes as such:

Don’t squeeze your objects into tables: store them in an object database.

It takes normal Python objects and make them persistent. ZODB has been there for more than ten years, it’s mature, more than the new “NoSQL” stuff like CouchDB, MongoDB, etc, etc … To be precise, it’s been doing NoSQL ten years before NoSQL even existed !

http://amoffat.github.com/sh/index.html

This article describes how to use django.contrib.staticfiles as this is a FAQ StackOverflow and IRC.

Structure

The HTTP server is to serve static files directly from a public folder, without going through Django at all.

Uploaded files

If the HTTP server configuration serves /srv/project/media_root/ on url /media_url/, for example with this nginx configuration:

    location ^~ /media_url/ {
        alias /srv/project/media_root/;
        autoindex off;
    }

Then:

• settings.MEDIA_ROOT should be /srv/project/media_root/
• settings.MEDIA_URL should be /media_url/

/srv/project/media_root/ is managed by Django’s FileField and ImageField file system storage, you should not add files there by yourself.

I just came across this fantastic repo, which contains many design pattern implementations in Python.

My advice: read them all :)