A new group of websites based on open source web mapping software stack was launched last month.
The project was developed with GeoDjango and other well known OSS components in about six months.
I’ve spent the last six months learning a new programming language (Python) and a new framework (Django). The result is a platform which integrates some state-of-the-art web development and web mapping technologies:
- Django
- postgis
- pg_routing
- ExtJS
- GeoExt
- OpenLayers
My client is a market leader in GPS wandering and track planning, who needed a complex CMS to publish and promote his activities.
The project’s goal was to develop a Geographic CMS multi-site, multi-admin (resellable) , multi-language using open source tools. Among other interesting features, we needed to support all well-known mapping providers (Google Maps, Yahoo Maps, OpenStreet Map etc.) plus an internal maps with tracks arc-node network, suitable for routing calculations.
The new website(s) are reachable at www.movimentolento.it at the time of this writing, the Italian language is the only one with some contents.
Python vs. PHP
After more than seven years of PHP programming, the language switch was a risky move, but I rapidly fell in love with Python and its vibrant users community. I usually avoid flame wars about programming languages, but I’m now deeply convinced that Python is far more advanced than PHP, even if PHP has its own advantages, expecially when deployment time comes.
(Geo)Django a powerful framework
The choice of Django as the barebone framework was dictated by Django being the one having an advanced support of Geographic extensions (GeoDjango) and by its beautiful documentation. Of course the ideal framework does not exists (yet) and is maybe impossible to create since they are always a compromise between ready-to-use functionalities and flexibility. Django authors must have had a good time providing (almost) all the necessary hooks for customization.
I’ve found Django a very interesting project for many reasons:
Lack of “magic”
While most widespread principles like DRY and convention over configuration are valuable, I’ve often found confusing for first time users the lot of under the hood features that are are triggered because you’ve named a function or a class in a certain way, I think Django has wisely chose to not implement too much of this outside of the ORM DB design phase. The result is a clean application design flow without too many conventions that you must have in the top of your head.
Powerful ORM
I really like the way you can build complex queries and retrieve related object in Django, even M2M relations can be handled in an understandable way. If you need multi-class (multi-table) references you can build them quite easily with the ContenType contribution classes.
Flexible templates
This is maybe what I love much in Django: the templating engine is so powerful and flexible that it can really save you a lot of work allowing you to put presentation logic inside the template itself. I agree that separating concerns in a pure MVC patterns (presentation and controller logic) is a must but think of Django templates like they were the presentation part of the view component and you’ve got the point.
Reusable apps
“Reusable apps” are ready to use applications that you should be able to drop into your applications, and they are reusable indeed. Even if I probably had to modify most of them in order to add multilingual and multi-site support, reusable apps can save you a lot of time.
Missing features
This is a short description of the main problems I’ve encountered when developing missing features in Django. I ended up without core modifications and with a single real patch, so it wasn’t that bad after all.
Multisite
Django comes with the “Sites” framework, it allows you to share the same DB from different websites, but you are supposed to run each website into a different Django instance. While this remains the recommended way, my clients required new sites to be added from the control panel in an easy way.
Site ID is hardcoded in the settings and due to the fact that static class methods are shared among processes (and moreover among threads, of course) you cannot use it directly without modifications. I’ve had to modify queryst managers and to create a middleware to change Site ID on the fly based on the requested domain. A catch-all DNS record allows to create third level domains within the control panel having them online within minutes.
Something similar is available as reusable app: django-multisite.
Multilingual
Django does not support multiple language for the content (it does for the interface static strings). I started from a reusable app (transmeta) and did some modifications to allow for optional translations and to easy control panel interface development and presentation. FTS integrations was also added.
Full text search (FTS)
DB is Postgresql which now comes with integrated FTS, I added some triggers and management commands to support multilanguage FTS. Django doesn’t provide any utility to handle FTS.
