v1.2

Atom Twitter Authors

A series of articles about upcoming releases of the Django web framework.

jQuery in the Admin

Zain Memon February 23rd 2010

Changeset r12297 dropped a bomb on everyone: a new file in the django/contrib/admin/media/js directory called jquery.js. This change ushers in a new era for the Django admin; an era of fancy new features, pretty widgets, and better usability.

The case for jQuery

Despite being discussed in the past, integration of jQuery into the admin wasn't on the map until the GSoC admin-ui proposal this summer, which suggested some UI-heavy features that would be difficult without the use of a framework.

It’s easy to see the need for a Javascript framework in the admin. Raw Javascript in any decently sized project slowly approaches the size and complexity of a framework. That process becomes a minefield of dealing with cross-browser issues, workarounds, and normalization; a framework short-circuits that pain and lets developers focus on building cool stuff. We live in the future, and there’s just no good reason to write Javascript straight to the DOM APIs when we could be adding useful functionality (with fewer bugs) instead.

It’s also easy to see why jQuery is the framework of choice: jQuery has soundly won the JS framework wars. Almost 30% of the sites tracked by builtwith.com use jQuery. Picking something else would mean fewer knowledgeable devs, less available code, and a smaller community of support.

This doesn’t mean Django endorses jQuery

There's some concern in the community that the inclusion of jQuery appears to be an endorsement of one framework over another — that's not the case at all.

Django proper remains blissfully agnostic to toolkit choice. The admin is an optional app designed for end-users, not other developers. Data entry clerks are unaffected by the admin’s tooling, and developers are not constrained by it.

If you're modifying the Django admin, jQuery stays out of your way. For example, the admin uses jQuery.noConflict() to make sure the $ variable isn’t polluting your namespace, so you can use Prototype’s $() in your own widgets without any conflicts. Also, jQuery is only loaded on pages with widgets that require it.

Your apps can still use whatever makes sense for you. For the Django admin, including a well-tested, proven framework makes more sense than to add even more undocumented, unvetted spaghetti Javascript.

This does mean Django’s admin will grow much faster

The front-end of the admin has stagnated a bit. A perfect storm is brewing for some kick-ass new front-end features: jQuery, a newly (re)appointed design czar, and a general focus in the community on better usability.

Django 1.2 mainly focused on laying the groundwork for future admin-ui improvements and most visible changes won't be felt until Django 1.3 and later. However, a few things did make it in.

New features

One of the first jQuery features in the admin is the dynamic addition of new inlines. For a demo of this functionality, check out this screencast:

A lot of implemented features missed the cut for Django 1.2, like drag-and-drop reordering of inlines for models with an ordering field, and an autocomplete widget for Foreign Key and M2M relations to be used instead of the select drop-down (or raw_id_fields). Those features (and others) will most likely land in Django 1.3.

These are exciting times for the users of the Django admin. There’s already some admin hotness in 1.2, and it’s only going to get better by the time 1.3 ships. jQuery it up!