Django and AJAX
Posted in Django
on October 12th, 2009 by
Stephen DeGrace
At the moment, Django does not heavily emphasize support for AJAX. Django does provide convenient serializers to exchange objects with the client in JSON or XML format, and of course it can easily send a response to a request in any format, so it certainly supports AXAJ, and JSON even when not running under Python 2.6 via the inclusion of simplejson in django.utils.
Where it arguably lacks, though, is in lack of built-in support to submit and validate forms via AJAX, and in not providing a range of AJAX-enabled widgets. I can't find the link right now, but the Django developers have stated that they have no intentions of "blessing" any one Javascript library, and essentially that Django provides all the support necessary to use any framework you want, or none, so go nuts. You can even read this hostile rant against "so-called web developers" who can't write in Javascript, implying a general hostility to libraries that make Javascript easier that is evidently quite common.
I have a lot of sympathy for the point of not wanting to tie Django to a particular Javascript framework. But as to providing helpers on the client side, what in the name of God do you think Django is doing on the server side? You could always turn the argument around and say that people should "grow the hell up and learn how to code Python" instead of using frameworks like Django that do much of the work for you. For that matter, perhaps you should "grow the hell up" and do everything in C, from scratch, no cheating by using libraries, instead of using languages like Python at all.
The counter-argument is the same on both sides - programmer time is a limited resource, often the limiting resource. This makes shortcuts enormously valuable, so people are going to write them, and other people are going to use them. The alleged fact that shortcuts can serve to enable bad or lazy programmers moreso than not having shortcuts is just something we have to deal with.
Django is weird about this, though. They provide an enormous amount of helpers that do things for you automatically (but hopefully not magically) when it comes to the traditional relationship between client and server, where the client requests pages and the server serves up the requested pages. Forms are an excellent example of this. Django forms are awesome, provided you never try to do any type of AJAX validation on them. But you have to jury-rig them to make them validatable by AJAX. You can do it, but it is not natural.
It is understandable that Django is a back-end technology and doesn't want to commit to a lot of front-end technology integration. It's particular origin and area of strength is in news-oriented web sites. But look where news-oriented web sites are going. Check out the new CTV News website, or the somewhat new CBC News website. Both of these are heavy on the AJAX-style interaction between components of the served page and the server (I believe CBC is using YUI?).
Love it or hate it, this is the direction professional web sites are going, including those sites in Django's main area of concentration. Django needs to think more seriously about making AJAX integration with front end widgets more natural or I think it's in danger of being left behind by its market, as people needing to implement these types of tools in a set time - "perfectionists with deadlines" you might call them - select tools that allow them to develop everything they need rapidly.
If Django were to move in this direction and found they needed to "bless" a framework to make this practical, my vote would be with jQuery.
My experience with jQuery so far has been that it's clean, fast, concise and it takes care of cross-browser differences for you very well. Also, it's compact - you can hold its entire feature set in your mind very well, and things work a consistent way - and it is very Javascript-y in its operation. That's a compliment. A lot of libraries use Javascript's ability to mutate itself to twist the whole language into resembling something else, or to give it "missing" language features like classes (quite unnecessary, IMO, FWIW). To me that's misguided and results in clunky and unnatural-feeling code.
In jQuery, everything works by passing function objects, and far from mutating built-in objects, jQuery scrupulously avoids polluting the namespace and leaves built-in objects alone. In my opinion, it is head and shoulders above every other framework I have looked at for elegance and practicality. By eliminating cross-browser event binding differences, leveraging the power of CSS 3 to access DOM elements, and providing a consistent interface to manipulate the DOM and handle AJAX, jQuery actually makes Javascript a pleasure to work with.
I am making a AJAX-heavy application for my site (the moderation interface for the new refback application) and so far jQuery and Django have played very well together. Where I'm having a problem is deciding what I'm going to do with forms. I have a form that is going to be in a jQuery dialog box and it has to be validated and submitted with AJAX. I'm not sure how I want to handle this. Do I create a Django form and instantiate it on the page? How will I deal with any errors that are generated in the form validation? Do I want to use as much of the built-in Django form functionality as possible, or would it be less trouble to roll all this on my own?
As I consider what I want to do I'm realizing that Django is starting to actively suffer a deficit in front-end integration compared to what is more and more becoming the norm.
UPDATE: I used Django forms with jQuery AJAX and added some jQuery to insert the error lists into the DOM for cases where the form failed validation. It looks good. Django and jQuery played extremely well together. In my $.post call I just used the jQuery form serialization to send the form and instantiated the form object in Django with Form(request.POST) type syntax and it worked flawlessly.
Comments:
There are 0 comments on this item. Be the first to comment.
Post a Comment
* Required field, your email will not be posted.