Every three months there’s a Dutch Django meeting with two 30 minute talks and a bunch of 5 minute lightning talks. This time, the third, like last, it was in Amsterdam. (See also my full list of summaries)
I’ve summarized the two bigger talks in separate posts:
I briefly told that django-staticfiles is real handy to store your css/js/images in your application. So a /media dir that works just like /templates with a bit of setup.
Read my django-staticfiles blog entry to get the full scoop.
Next year the djangocon.eu conference is in Amsterdam, see for instance the notes from the first organizer’s meeting. Remco Wendt is the main organizer (or at least the front man).
He had some great contacts with the city of Amsterdam. One of their economic main points is the necessity of attracting developers to Amsterdam. So they embraced this djangocon conference and they’ll officially help out.
The date isn’t finished yet and I was explicitly forbidden from mentioning the currently-most-probable date on my weblog :-)
One of the goals is making the program available much earlier than normal at Django conferences, so we’re going to hunt for good talks at an earlier stage.
Sanoma is a big publisher in the Netherlands. To Dutch people it might be better known as the former “ilse.nl” search engine. They own some 150 websites like nu.nl, startpagina.nl and schoolbank.nl.
The development department develops internally: so the colleagues are the clients. For instance common parts of the various websites. But in the end all the various tools used a lot of different websites… So standardisation to the rescue! They chose a handful of allowed frameworks, like wordpress.
But… with for instance wordpress, once you get really big it starts to get unwieldy. So there was a gap between the simple sites and the really big sites. That gap was filled in the end with Django.
Drawback: they were mostly php developers (and some .net ones). So Django being Python was a drawback. On the other hand they knew a lot more than php like javascript, html, css, etcetera. Seen from that perspective it wasn’t too strange to add another language to the mix after all.
Reusable apps: one half calls them junk and the other half manages to build great sites with reusable apps and just one or two lines in their settings.py. So the quest is to find out how the second half manages their feat.
A bit part of reusable apps is the reusability of models. Often the reusability is a bit hampered by having to add fields to your base models. Every customer wants it just a little bit different.
Django doesn’t support this really well. You can get by a little bit by:
Evil monkeypatching.
Copy-pasting your “reusable” app…
I mentioned zope/plone’s ability to dynamically add fields to an existing content type as they use the zope object database (so: a NoSQL database without fixed SQL relational columns) and as the editable fields are looked up through and adapter (this allows you to configure your app to inject fields).
An option suggested by someone was to put some extension configuration to classes in your settings.py. The application, knowing that it has to be extended, could look up these extra fields in the config setting.
Another suggestion: look at aspects. Alfresco was mentioned as an example.
Another suggestion: just make site-specific model subclasses and view subclasses. That could mean a whole lot of subclassing, though.
Another suggestion: look at django-registration, that solves it quite cleanly.
This might be the last time Diederik visits a Dutch Django meeting as he lives in Canada :-)
Once you build a website, you want to know how people use your website. We’re quite advanced in determining which pages are loaded in which order. But where exactly are they clicking on your page? Is your page well-designed?
There are existing commercial solutions that come with quite a hefty fee.
So he decided to try and build his own. Python comes with batteries included, so he uses matplotlib, numpy, PIL, webkit2png and so.
Django-mousechaser is an early-alpha experiment. It tracks the location of your browser and it detects the x/y locations of your divs. Behind the scenes it uses an iframe to submit tracking data to your server. The tracking data is visualized in a so-called heatmap.
You can enable it by adding a javascript to your existing site.
There are still some location problems. Matplotlib thinks in dpi, not in screen pixels. And “liquid” layouts with non-fixed sizes are currently a problem. He doesn’t always get the correct data from jquery. (My suggestion was to look at flowplayer.org’s jquerytools: it contains some x/y location jquery tool (at least I thought it did, but I can’t find it right now, aargh…).
He wrote a bit of code: ResizeImageField as an extension of RemovableImageField. It is a replacement of Django’s imagefield. It creates a thumbnail automatically that is shown in the Django admin interface. RemovableImageField adds the easy option to remove an already-added image.
ResizeImageField also adds the option to create various image sizes, accessible through different URLs.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):
