Servprise Dev Weblog

We recently upgraded our weblog engine from Typo 4.1 to Typo 4.1.1. In the process, the Jabber configuration got messed up and the net effect was that no comments could be submitted.

At this point, we think the problem has been fixed and apologize for any inconvenience. If you wanted to comment on any posts, please feel free to do so now.

Recently, there was a discussion on the mailing list relating to a potential overhaul of URLConf. I really didn't get involved due to time constraints, but I did think about the matter. URLConf is one the core features of Django and has remained largely unchanged in the two years since I started using the framework. Two of the core tenets of modern Web application frameworks are Don't Repeat Yourself (DRY) and convention over configuration; traditionally, URLConf has broken both.

On the DRY front, URLConf has come some ways. Django 0.96, the latest released version, added the url template tag, which made it possible to generate URLs in your templates without needing to repeat the same info as in your URLConf. There was a limitation relating to view reuse, but the SVN trunk version of Django fixes this problem. Hopefully a 0.97 release is not terribly far off, making the enhancement available to a wider audience.

The issue of convention over configuration, however, has largely been unaddressed with regards to URLConf. If you want to serve up a page, you add a URLConf entry -- that is the Django way. Sure, other things can be done, but you have to go out of your way to do it. We came across this limitation hard when converting dev.servprise.com, which was largely a static site, over to Django. Having to specify a new URLConf entry for each ported resource was cumbersome, so we resorted to custom middleware. I posted the snippet so it could be used by others, and in the process learned of other solutions via comments left about the snippet. While educational, I was left wondering why this burden is placed on each individual developer. This seems like a large step back from using a Web application framework at all. In the old days, I put a file in a directory and Apache served it up. It was the ultimate in convention over configuration. If the Apache folks told me I needed to add a Location tag for every URL I wanted to serve, I'd have thought they were insane.

Moreover, having one entry for each served up resource means that the URLConf can quickly grow out of hand. Once again, being that it is all Python code, there are surely ways for each developer to handle the complexity, but these approaches address the symptoms, not the problem (thanks Malcolm). One of the proposed solutions to the problem pitched in the aforementioned discussion is using a decorator on the view function to dynamically add URLConfs. This, to me, wasn't actually all that bad of an idea. I'd propose taking it a step further though.

If URLConf entries are simply mappings from URLs to views, and each element in that mapping is adequately named, why not let the view name dictate the URL? This also would advocate a cleaner organization of views (rather than a monolithic views.py), using the package name to build up URLs. As an added benefit, it is consistent with the approach taken by the url template tag. Undoubtedly, this has flaws as well. Mapping the same view to multiple URLs is going to require some additional thought. This is the same problem I mentioned with the url template tag in Django 0.96. My gut feeling is that code delegation in the view functions is an adequate solution. In those cases where it is not, use URLConf as the fallback. There is no need to remove URLConf altogether, but it should be the fallback rather than the primary way to map URLs to views.

To address issues of "magic" in the URL mappings, I'd either enhance the sitemaps contrib app or create a new one that could graphically depict the page's organization via URL templates to particular views. This sort of app could be useful right now, actually. Magic or not, getting a good handle on a site's structure can be a daunting task.

Questioning how URLConf could be better is one of the first steps in progress. I proposed a potential solution, but invariably, it has its own set of flaws. I'd like to see a good discussion on the matter, perhaps during the upcoming sprint, and see a better solution prevail.

We started evaluating Satchmo for our main store page when we discovered that Satchmo 0.5 does not support the newforms-admin branch of django. Satchmo tracks the latest django trunk, which does get merged back into newforms-admin periodically. Unfortunately, Satchmo appears to augment or at least rely on the old-style admin site. As such, it will not run using the newforms-admin branch. This is a bit of an issue for us, since we have come to rely on having newforms-admin.

We'll probably set up a separate environment to test in, but even then, Satchmo may be problematic for us. It's one thing for us to have to chase trunk or newforms-admin revisions and a completely separate one to coordinate with a third party project that also relies on an unreleased/unstable version of django. We have run into issues in the past with different developers in our own team running "svn up" at different times and running into inexplicable issues with the code, only to find out it was related to update timing. It's something we do not look forward to doing with another remote team.

The project does look interesting though and we'll likely weigh in on it more as we further evaluate it.