I have been working on a multi-user blogging and publishing platform using Django 1.0 lately. Naturally this requires the backend to be able to handle file uploads. A lot of things have changed from Django 0.96 which I am still using on some legacy code. One of those changes is the way Django 1.0 handles file uploads. Most of the changes done were made to allow Django apps to handle large files without soaking up too much memory.

So what has changed? The most visible change is that there are now at least two separate API’s that you have to work with. You have the File API and the Storage API. The File API which exposes the File class provides a thin wrapper around Python file objects. The Storage API, on the other hand, exposes a base class Storage that you can use to implement custom storage facilities. There is another API that provides FileUploadHandler. This will allow you to customize the way Django handles the uploaded files in their “raw” form. For most purposes, the File and Storage API will suffice.

This post is meant to supplement the information found in the “Handling Uploaded Files” section of the Django File Uploads documentation. You will still need to refer to documentation.

(more…)

I recently found myself writing my first Facebook app using Python with the Django web framework. I have to admit that it was not a very pleasant experience. The usual Django development cycle of programming and testing locally does not work. I have a very simple workflow nailed down when writing Django apps: write, test locally, commit to VCS, and upload to server. When writing a Facebook app, I had to change the current workflow a bit: write, commit to VCS, upload to server, test on production.

Facebook, being a PHP-powered site, likes to make the assumption that you will also be writing your app using PHP. They don’t even make any efforts to hide their bias towards PHP. The “official” client library is for PHP. The example program they give to you the first time you sign up is written in PHP. All the relevant starting points all lead towards PHP-centric development.

Thankfully, there are those who realize that PHP is not the be-all and end-all to programming web applications. You can find unofficial client libraries for other programming languages. Download and install the client library for your programming language of choice and follow the documentation and hopefully you get to have everything working on your first try.

(more…)

You have worked around the quirks and you have lived with the inconsistencies. You have stood by and watched your code fail spectacularly between minor point releases. You scrambled to fix your code’s dependence on register_globals set to on when they got turned off by default in version 4.2.0. You have lived with the disappointment when version 5 failed to deliver on better object orientation. There have been a lot of warning signs telling you to look for better alternatives, but still you persevered. Then came the recent changes that really make you shake your head in disbelief. Face it, PHP’s direction as of late has really taken a downturn. You’re thinking it’s time to look for alternatives.

If you are one of those folks who have been using PHP and nothing but PHP for a long time you will be hard pressed to find an alternative. PHP is, after all, one of those things that are “easy to get into, but difficult to get out of”. PHP lures you in with its forgiving nature, vast library of pre-built extensions, ease of deployment and just plain “instant gratification”. It’s easy to forget that there are other languages for server-side programming/scripting.

(more…)

Now see this is why I love Django. It’s an awesome framework with a great community behind it.