October 26, 2005
A couple of days ago, Hurricane Wilma hit Florida, with the city of Naples almost directly in its path.
The local newspaper there, the Naples Daily News, used Django to create several hurriance-related Web applications on deadline. Listen to new-media director Rob Curley talk, among other things, about the importance of agile Web development in a news setting.
October 24, 2005
Because we're perfectionists, we've taken care when designing Django to make sure It Does The Right Thing when it comes to following HTTP standards.
Ryan Tomayko touched on HTTP, and how most Web frameworks don't use it correctly, in his "On HTTP Abuse" piece earlier this year. In the article, he rhetorically asked which frameworks make certain HTTP functionality easy, or do it the "right" way.
Let's take a detailed look at each of his questions and point out precisely what Django does in each case.
For instance, which frameworks...help implement content negotiation properly?
A few parts of Django perform server-driven content negotiation for you automatically. For instance, the GZipMiddleware compresses content for browsers that understand gzip compression.
Django gives developers a simple way to set the Vary header, as mentioned in the RFC linked above, "to express the parameters the server uses to select a representation that is subject to server-driven negotiation." See the "Using Vary headers" documentation. By default, all functionality that comes with Django, such as the session and cache systems, sets the appropriate Vary header(s) automatically.
For more obscure content-negotiation needs, you can access all HTTP headers in any request object. If you can think of any useful negotiation-related functionality we could add to Django, please let us know by posting to django-developers or our ticket system.
...provide facilities for implementing a smart caching strategy for dynamic content? (proper use of If-Modified-Since, Expires, Cache-Control, etc.)
...make dealing with media types easy?
It's outside Django's scope to deal with media files at this point.
...make dealing with character encodings easy?
Django's got you covered here. The DEFAULT_CHARSET setting lets you specify the systemwide character encoding of input and output in all Django-powered pages. Things Just Work.
...encourage the use of standard HTTP authentication schemes?
Django's session support doesn't use standard HTTP authentication, because we don't like the usability (or, lack thereof) of HTTP authentication in modern browsers -- particularly the fact that a user can't log out without closing her browser. If there's interest, we can add support for HTTP auth.
...have a sane mechanism for attaching different behavior to different verbs for a single resource?
Yes. We're fanatical about this. This is why each request object has separate GET and POST attributes -- so developers can differentiate between the two. You can use request.META["REQUEST_METHOD"] to get the exact request method, in case you need to support something less common, such as PUT.
...help ensure that URIs stay cool?
An emphatic yes. This is another thing we're fanatical about. Django's URL-dispatching syntax encourages cool URLs -- URLs without file extensions. It also makes it simple to support legacy (e.g. ".php") URLs and redirect them as needed.
...make dealing with transfer encodings (gzip, compress, etc.) easy?
Just turn on GZipMiddleware, and Django automatically will gzip your pages for browsers that support it. We don't have a "compress" middleware, but adding one would be a cinch.
...help you use response status codes properly? (e.g. Nearly all dynamic content returns either a 200 or 500).
Here's another thing we're passionate about. Each response object uses status code 200 by default. The HttpResponse subclasses (e.g. HttpResponseServerError or HttpResponseNotFound) all return the right status code. We encourage you to use the right response types in your applications.
The built-in Django pages, such as error pages and "page not found" error pages, use 500 and 404, respectively.
October 18, 2005
I've committed a change that fixes ticket #627. The Django admin app has been refactored, to make things simpler and tighter -- both conceptually and in code layout.
The major change is that an admin site no longer requires its own settings file. Yes, you can run the admin and "main" sites off of the same Django installation!
This should eliminate the problem that some newbies have in keeping track of whether they're using "myproject.settings.admin" or "myproject.settings.main." Now it's just "myproject.settings." Plus, instead of "myproject.settings.urls.main" and "myproject.settings.urls.admin," it's now just "myproject.urls."
The whole thing just got a heckuva lot simpler. :)
Unfortunately, this was impossible to do without breaking backwards-compatibility. I've outlined all the code changes you'll need to make on the backwards-incompatible changes page.
I've also updated the tutorial to reflect the changes. You might find it useful to read the tutorial again to note the subtle differences.
Feel free to post questions to the django-users mailing list.
October 17, 2005
We've added Django settings documentation, which explains how settings work and which settings are available.
October 14, 2005
We've added a new piece of documentation, Design philosophies, that lays out the fundamental philosophies we've used in creating the Django framework. Its goal is to explain the past and guide the future.
October 11, 2005
Django-served pages are now, by default, cache-friendly. That is, they output Vary HTTP headers behind the scenes, to instruct caching servers (such as Squid or other proxies) when to cache and what to cache by.
You, the Web-app writer, have fine-grained control over which Vary headers are sent out for a particular view. Check out our new "Controlling cache" documentation for the full scoop.
Also, we've added two performance-enhancing middleware modules: support for conditional GET and gzipping output. They were part of the cache middleware before, but we've split them to give people more flexibility; now you can, for instance, activate conditional GET but not gzip, or vice versa. See the middleware documentation.