Header graphic 1 of 8



Other stuff

Other sites

I wish this site were powered by Django

August 06th, 2008

GeoDjango has been merged into Django’s trunk yesterday

Filed under: Django,Python,Technology — jm @ 12:19

This means that GeoDjango will be part of Django 1.0! This is another great addition to this fabulous framework. It changes and extends Django's ORM so that it supports GIS types in multiple databases. Of course, that primarily means support for OpenGIS types in MySQL and PostgreSQL and querying them via Django's ORM.

Now, if they'd finally land aggregation support, I'd be totally happy with Django 1.0!

July 21st, 2008

Django: newforms-admin has been merged into trunk

Filed under: Django,Python,Technology — jm @ 15:37

Brian Rosner posted this update in the Django users group. This means that Django just made a big step forward!

July 02nd, 2008

Updates all around: Ruby, Django, Diablo

Filed under: Django,Games,Security,Technology — jm @ 11:27

I didn't touch my newsreader in a while and promptly I missed quite a bit of interesting things. Here are the most important:


Large file uploads: Revision 7814 finally lands the patch from ticket 2070 and finally allows Django to handle arbitrarily-sized file-uploads.

Ruby's security vulnerabilities

Man, I'm late to that particular party, but some serious vulnerabilities have been found in the main Ruby interpreter. Unfortunately it seems that the official maintainers messed up as well and only 3rd-party patches are available right now, because there's no known stable release code in the codebase that a quick patch release could be based off.

I think the most important lesson that can be learned from this, as Simon Willison points out, is that you need to keep release tags around in your SCM system, but also that you should never blindly trust any part of a system. At least it makes me wonder what surprises lurk in the Java VM or CPython.

Diablo III

Has been announced. Userfriendly pretty much hits the nail on the head.

February 15th, 2008

The state of Django and Unicode support

Filed under: Django,Python,Technology — jm @ 14:11

I still get a lot of traffic from my post Django 0.95 has unicode problems, too, but a lot has changed since then. So I'll try and give a short overview:

While Django-0.96.1, the current stable version, has no real integrated Unicode support, the Unicode-branch was merged into Trunk on the July, 4th 2008 in changeset 5609. With that patch Django gained full Unicode support and it also is finally possible to use legacy databases. There's an ongoing discussion about allowing UTF-8 characters in usernames on the developer mailing-list in Django's authentication. Also a lot of "general functionality that's necessary for a real website"-patches have become available over the 12 months:

  • FileFields and ImageFields now work as expected in newforms since changeset 5819

  • There's a pretty stable patch for large file uploads available that passes all tests, but has not been committed yet in ticket 2070

The newforms-admin branch that aims to align Django's excellent administration application with the newforms library tracks Trunk pretty closely and Michael Trier has a screencast that shows how to convert an application to newforms-admin, so that might also be a good place to start if you want to use the newforms-admin application.

The GeoDjango branch that integrates Django's ORM with GIS support also seems to have become quite stable and was recently featured on the excellent This Week In Django podcast #8. This Podcast by Michael Trier has replaced the "This week in Django"-posts on the Django weblog. I liked "reading the news" better, but Michael does an excellent job, so tracking this Podcast is important if you're serious about using Django!

So there you have it :-), things have come a long way since 2006. Even more information can be found in the excellent (and freely available) Django book.

March 25th, 2007

Django, Java and framework functionality

Filed under: Django,Java,Python,Technology — jm @ 08:06

Update: This post addresses the differences between Django and Tapestry 4.1 and it’s a bit outdated. I wrote another, higher-level, post on that topic that you might want to read.

It seems that every web framework has the desperate need for displaying tabular data, but only few solve it as well as Tapestry does with contrib:Table. Even if you’re stuck with plain JSP there’s the excellent Displaytag library. Django has no such thing at the moment.

Not only that, the more I work with Django the more it reminds me of early Servlet-based development environments. urls.py resembles <url-pattern>s, Middleware can be compared to javax.servlet.Filters. Now, of course, Django is much more fun to develop with, because of its Admin-application, the newforms library, it’s pythonic and it supports rapid-turnaround development. So there’s no XML-juggling involved and you don’t repeat yourself and generally the design revolves around easy to guess interfaces. But really, I’m missing some of the features that are available in a Java software stack.

Currently, if I’m working with Java that means I have:

Feature Library
Component-oriented development Tapestry 4.1
Dependency Injection and module discovery Apache Hivemind and of course Spring
Full Ajax support Tapestry 4.1
Declarative, fine-grained security Acegi, combined with Tapestry-Acegi (modified for form-based authentication)
Database access JPA / Hibernate
RSS/Atom support Rome
Full PDF support iText
Real full-text search Lucene

Of all these, Python has only a few equivalents. Rome, for example, is modeled after Mark Pilgrim’s excellent Universal feed parser and Django’s ORM solution works for most cases (I happen to think that EJB3 did a few things right), but there’s no equivalent to iText in terms of functionality and feature support and Acegi/Spring-security is simply the most-advanced authentication/authorization-library there is.

So if Sun would finally stop diluting the standard library and instead get their act together on fast and painless class-reloading, it would be a blast to work with (feature-wise, not language-wise, which might be fixable by using JVM-based scripting languages like Groovy or JRuby). But as long as I have to wait 30 seconds per round-trip for Tomcat to restart, I’d rather shoot myself than attempt to develop a CRUD web-application with Java again. If only someone wrote something like Django’s Admin application for Tapestry and JPA…

For now, it might at least be possible to integrate some of the libraries mentioned above with Python, by using gcj along the lines of PyLucene.

So I guess if I find time, which I don’t have, it’s pretty clear what has to be done. Someone needs to develop an Admin-application for Tapestry based on contrib:Table, BeanForm, JPA and annotations and then someone needs to develop a contrib:Table-lookalike and a fine-grained authentication and authorization middleware for Django based on decorators for views, but with the possibility of an external configuration file (dare I say it: possibly XML-based).

August 31st, 2006

Django 0.95 has unicode problems, too

Filed under: Django,Python,Technology,Web — jm @ 04:48

I had to revise my post titled “UTF8-encoded Unicode support“, because I found out that django’s unicode support has it’s own problems. Some are, of course, connected to the character-set handling of their database code, but generally they currently handle all strings as binary, assuming that everything works within the DEFAULT_ENCODING setting.

That way, foreign character sets can break functions (#1355) in django and even worse, you can’t hook up a legacy database that uses a different character-set without patching the database driver. At least, current work on SQLAlchemy integration might make that less of a concern. I’m just hoping that django 1.0 will include full unicode support. For more information read the update on the old post.

Update (02/15/2008)

Django has come a long way since this post. An update can be found here.

August 08th, 2006

UTF8-encoded Unicode support

Filed under: Attitude,Cutting the crap,Django,Java,Python,Technology — jm @ 02:15

From this post at MySQL DBA:

The utf8 spec says that a utf8 character can take up to 4 bytes, mySQL currently only supports up to 3 bytes.

……holy crap. Let’s summarize how different languages and frameworks support Unicode at the moment:

For some reasons, someone over at Sun decided that Java’s char-data type should have 2 bytes and be represented in modifed UTF8, so that certain characters that would normally require 4 bytes in normal UTF8, now require 6. This actually makes sense to keep compatibility with C programs (modified UTF8 has no “0-bytes” in strings), but makes it hard to support Unicode’s supplementary plane, where characters can have up to 4 bytes. The details can be found in JSR-204. Ever since then… string operations in Java cannot reliably calculate string length, because these methods do actually count valid UTF-16 characters.

PHP… don’t even get me started. PHP just sucks.

Ruby apparently also has problems with moving to Unicode (and this language was designed in Japan)?

So while I’m very glad that I decided to focus on Django and Python, which have has excellent Unicode support, I really feel, more than ever, the need to get the word out that text processing is incredibly hard and that there is no excuse for so many developers and teachers not caring about it.

Update (08/31/2006)

Django’s unicode support apparently also sucks. They try to do the right thing in their MySQL driver (using SET NAMES 'utf8'), but fail to set the connection character set properly, so even if the model is in UTF8, MySQL will treat every incoming string as latin1. This leads to ugly reencoding errors. It seems to work better with PostgreSQL, but it’s still a huge fucking bug. The developers try to get their act together, though and the “unicodification” will probably be done before they hit 1.0. #1356, #1355 and #952 read very badly. At least I have now pointers on what to fix (follow the links), but out-of-the-box you’re fucked if you want to connect your legacy Windows-1252 database to the web using UTF8 with django.

This reminds me a bit of the sad situation with Typo3. At least, with django, it’s not the programming language that’s the core problem.

Update (02/15/2008)

Unlike Java and PHP, Django has come a long way since this post was written. I wrote an update on Django’s Unicode capabilities that can be found here.