Ola Sitarska absolutely loves the django admin interface.
She started out writing elaborate admin interfaces for silly games in PHP. At a certain moment she discovered django and hasn’t written a single line of PHP since. She organized djangocon.eu 2013 and djangogirls and she’s a core developer and…. she even named one of her cats “django” :-)
The django admin is not one of the most beautiful parts of the django code base. It is hard to wrap your head around the code at first, but it is very robust and backwards compatible. In the end it are just a couple of views and urls, though. Three important classes are AdminSite, ModelAdmin and Changelist.
AdminSite: encapsulates one instance of the django admin pages. If you add
/admin to your
urls.py, you’re effectively instantiating an
AdminSite. Which means you can do it yourself by hand, too. With a different
name and different behaviour.
.get_urls() is an important method. It sets up the urls, for instance for
login and logout. And it iterates over all registered models, ading urls for
There’s also some basic config you can do on AdminSite, like site_title, site_header, index_title.
ModelAdmin: this encapsulates the models and allows you to edit them. It contains all the options and functionality for showing the models. There are a lot of things you can tweak. Look up the full documentation and see the goodness that is available. Some favourites: actions_on_top, fieldsets (handy for grouping fields to make the form more clear), list_display, list_editable (but note that there is a bug report for that, it might be unsafe to edit a list when other people might swap the order around at the same time). radio_fields.
Also very useful:
save_as. That gives you a “save as new” button that is handy
for making almost-duplicates of existing entries.
ChangeList: you often don’t have to touch this. If you’re modifying it, you’re probably delving a couple of levels too deep.
There are some tricks that she uses almost always to make the admin more useable and beautiful. As an example, she used the djangogirls website(s): all of them are edited from one single django admin.
One admin and multiple djangogirls workshop organizers? That means permissions
need to be set per-event. For this, you can add a
get_queryset() method to
your ModelAdmin that limits the results to the ones the user is allowed to
see. The method gets passed the request, so this is reasonably simple.
For even more customization, you can edit the
get_form() method to
override certain fields. A dropdown can thus be limited to show only the
values the user is allowed to enter. You can do all sorts of adjustments here.
Organizers can now edit only their own events. And… they can only edit future events.
Custom method fields. The list_display list can include method names. You can then write a method with that name that collects the information you need. For example a string with all the organizers and their email addresses.
You can also show images. A
def get_logo_display() that returns a bit of
html with an image tag. And a line afterwards
True to allow it to output html.
Actions are handy. They’re just a method on the ModelAdmin
show_on_homepage) that is configured as an action.
There are a couple of efforts to replace/rewrite the admin. None have been succesful yet. The current django admin just works and does a lot well and apparently it is hard to beat! The UI is a bit dated, though.
There is something that might land in a future django version. You can try it
out yourself already by installing
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):