Tag Archives: django

>Django – Named URLS Gotcha

>A post in two parts.

First of all – thanks to Magus on #django for pointing out one of my errors to me. I’ve been working through Practical Django Projects over the last couple of days and it talks about having named urls. Take a look at these three one liners:

# from urls.links.py

(r'^$', 'archive_index',link_info_dict, 'coltrane_link_archive_index'),

# from urls.py

(r'^weblog/links/', include('coltrane.urls.links')),

# In my template I get the url using

{% url coltrane_link_archive_index %}

We give our view a name (coltrane_link_archive_index), then we call that view with urls.py so it’s context will be /weblog/links – and then in our template we can just use the url tag to call that named url. If the url gets moved, your templates will still work – and of course it saves a lot of tedious typing. Great.

So working through the book, the blog application requires a lot of templates and views and stuff. So I thought I’d just do the main one and get the minor ones working later. But I did check to make sure that links to those views were working and they were not.

Written like this, the problem is obvious, a named view won’t work if the view it’s pointing to doesn’t work. So if your url tag’s don’t function – make sure what they should be taking you to are ok.

But there’s more. Because when I wrote the underlying views it still wasn’t working. And I discovered something interesting. I had a problem last night after restarting the web server – The first time I’d go to a page I’d get

ImproperlyConfigured: Error while importing URLconf 'coltrane.urls.tags': name 'Link' is not defined

For some reason I couldn’t work out why that was happening last night. I have no idea why I could not – it’s blatantly obvious. I wasn’t doing an import of the Link model for my tags url file. But I was ignoring it yesterday because I found that if you just asked for the page again it then displays (not the tags page, I hadn’t written that, but the rest of the site seemed to be working. I put it down to some strange ‘glitch’. It wasn’t.

I’m guessing here somewhat but I think what happens is the first time you load your site up, Django precompiles the regular expressions used for your urls. During that compile if it hits an error you’ll have some urls working (up to where it failed) and some not. The second time you hit the site that doesn’t happen (it thinks the regular expression compilation has completed) and doesn’t raise the error again. But of course all the urls that failed won’t be working (hence why url tag wasn’t working).

On a final note, you’d think by now that I would have learnt that when you have a ‘strange glitch’ there’s something bigger lurking there that you really need to understand.

>NewForms Admin – Flatpages

>Practical Django Projects (Chapter three), talks about defining an admin interface which is all well and good unless you’re using the NewForms Admin branch (which is intended to become part of Release 1.0). So if you’re an early adopter or reading this after the big change, you’ll be needing to do the following.

The reason I bothered writing this was I couldn’t work out how to override the fact that FlatPage had already registered a ModelAdmin (try to register yours throws an error). A pointer from #django on irc and a look at the source code revealed that unregister was the baby you wanted.

from django.contrib import admin
from search.models import SearchKeyword
from django.contrib.flatpages.models import FlatPage

class SearchKeywordInline(admin.TabularInline):
model = SearchKeyword

class FlatPageAdmin(admin.ModelAdmin):
inlines = [

# We have to unregister it, and then reregister
admin.site.register(FlatPage, FlatPageAdmin)

>Django OR statements / conditions


I’m having major problems focusing on one thing at a time at the moment. I thought that being in Japan would help me but it appears not. I’ve made some changes to how I work recently and I’m going to have a go at documenting what I’m doing with code and sysadmin stuff here. Partly as a brain dump for when I can’t remember how I did stuff and partly to see if it makes it stick in my brain. Past experience shows this won’t be something I keep up by anyway. Today I’m plodding through writing some Django code which is a rewrite of some pure python/sql stuff I did before. I know a lot of sql and therefore am having to force myself to try and use the Django API efficiently as much as possible (partly so I know when I shouldn’t use it). Todays question is how do I do OR statements.

Well according to the docs you setup Q objects. OK … I’ll stay calm. Here’s my current code.

    usages = Usage.objects.filter(parttype=parttypeid)
usages = usages.filter(client=self.client)

Just to point out that I’m doing two conditions here which are AND’ed together. Firstly to find any Usage record with a parttype of whatever parttypeid is and secondly to find any client which is the same as our client record. I could have given the first condition a PartType record or I could have given the second condition an id instead of a Client object. Although these two conditions are given in different lines they won’t be evaluated until I try and access the records at which point just one query will be thrown at the database. I also want to do an OR statement so that whatever is found in the above two statements much match. This is where I must use my Q object. Import it from django.db.models.Q


That looks like a long fieldname. Actually it’s some black magic that Django does for working across relationships. dockcode is a related table to usage, productionline is related to the dockcode table and destination is the actual destination we want to get to. They are double underscores to show you are referring to a related table. I don’t like the syntax but I can live with it for the moment. OK – but we want to look for two possible destination ids. So we end up with this

   qs = ( Q(dockcode__productionline__destination=destinationidA)|                  

And we just add that to our filter which we haven’t actually executed yet. So in total we end up with

    usages = Usage.objects.filter(parttype=parttypeid)
usages = usages.filter(client=self.client)
qs = ( Q(dockcode__productionline__destination=destinationidA)|
usages = usages.filter(qs)

That will return any usage record which has the given parttype, the given client and one of two possible destination ids. Well it will – when you try and access the result.

>Django Settings File

>Whilst I love Django, there’s a number of odd things about it which make me puzzled. One of those is the settings file. When you have a team of programmers it’s important to be able to check each others code out with the minimum of fuss and to be able to deploy that code live in the same fashion.

Thus it was that the settings.py file used within Django has always puzzled me. You specify directories for where your templates go and you’ll see the following

# Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.

I have no idea why this does this, and I’m not the only person but as I’m as thick as a whale omelette I am not going to argue with the developers. The real ‘wtf’ is why the comments lead people to put paths in that will break when used on the next developer’s machine. I’m developing on linux in my home directory, we deploy onto linux into a different users directory, the other developers mostly use Macs which have a different directory structure for homes.

Anyway – enough. As the ticket comments for this ‘fault’ say. The solution is simple. settings.py is a python file so do something like this.

import os
"%s/legacy/templates" % root_path,
"%s/edi/templates" % root_path,

And your world will be a better place.