Recently I found the need to override the _get_FIELD_url() for a particular set of models in my Django app. The _get_FIELD_*() methods provide your FileField and ImageField with “magic” convenience methods. For example:

from django.db import models

class MyModel(models.Model):
    file = models.FileField(upload_to='some/path')

If you want to to retrieve the URL for the file you would use:

m = MyModel().objects.get(id=1)
m.get_file_url()

Notice that your class automagically gets a method called “get_file_url()”. This is the “magic” part and all of this is done behind the scenes for you. While this is really convenient for getting things done most of the time, there are some times where you need to have more control over what’s returned by these magic methods.

(more…)

I will be buying a new server to host my site and possibly use it for web hosting. I have been scoping out the competition. There are a lot of them out there and it’s scary what some of these web hosting companies appear to be offering. On the surface they certainly look very attractive, not so much for their glossy landing pages and slick designs, but because of the numbers they put out on their packages.

A colleague brought up one web hosting company the other day. Ultra-cheap packages and impressive numbers make it very attractive to those who are looking to host their site for the first time. I don’t know what bothers me more. Is it the fact that people buy into these bullshit packages? Or the fact that some unscrupulous web hosting companies take advantage of numbers to market their crappy service. To be fair to them (and so you don’t fall prey to them as well), I won’t mention that company here. However, I will take a look at the packages they offer.

(more…)

When you have several projects that share the same app, it is particularly important not to hard-code URL’s. Say you have a Blog app that you want to use with a couple of projects, you need to ensure that any URL’s used in the views as well as the templates are “portable”. That is, if you have one site with the Blog app rooted under /blog/ and the other site puts it under /diary/ you need to make sure that URL’s mapping to the views in the Blog app will work under these different roots.

For instance, viewing a post on one site would require a URL like /blog/posts/1/view/ and the other site it would be /diary/posts/1/view/. For blog archives you would have URLs like /blog/archives/ and /diary/archives/. You would use a URLconf pattern like this:

(r'^posts/(?P<post_id>\d+)/view/$', 'post_view'),
(r'^archives/$', 'post_archive'),

You can hard-code the URLs in your views and templates, but that would be less than ideal since you now have to maintain two slightly different versions of what is essentially the same code base. What you need to do is somehow obtain the URL properly rooted to either /blogs/ or /diary/.

(more…)

This is the first in a series of articles that I will be writing about Django, a Python-based web development framework that I have been using for two years now. While documentation for the framework is available, there are still vast amounts of “uncharted” regions in the code base. Articles in this series are my attempts to document undocumented behavior and code. I only use the latest stable version (0.96) at this point, so it is possible that it is already documented in the latest SVN version. In which case, you should also check the SVN version docs first.

First up are newforms. Older code based on 0.95 and earlier use the older “Manipulators” system. The replacement system is “newforms” which, until 0.96.1, had only been available from the SVN versions. Newer code should make use of the “newforms” system as Django team has already announced that they will remove the old Manipulators system eventually.

(more…)