Dutch Django meeting in Amsterdam, part two¶

Reusable django apps - Klaas van Schelven¶

Basically a continuation of the lighting talk he gave last time.

They make software for lawyers. These sites don’t have lots of page views, so there are no performance issues, for instance. But the “problem” that they have is the amount of small customized changes that the customers want. One wants a social security number per person, the other wants to know the sex.

They do not want to clutter the generic code with all those small customizations, however. You’d end up with lots of SHOW_SSN = False switches in your settings, otherwise.

The official solution (*note Reinout: see James Bennett’s video) is to “parametrize your views”. def my_view(request, template="xyz", form_class=SomeForm, model_class=SomeClass). That’s a whole whopping lot of parameters!

Their solution: EightSpaces. “Class based everything”, basically. It is called “eight spaces” as what you’d normally put in your models.py is indented eight spaces to the right: it is wrapped in two levels of eightspaces code: one wrapping class definition and one wrapper method. I’ve seen worse names :-)

The wrapping (for models) is done to wrap a generic model and, by doing so, extend it with one or more attributes. The same for views. The regular view functions are now class methods. The advantage: the methods can reference self, which contains pointers to the extended models (self.app.models.Something) and so. This helps a lot with extending and mixing and matching.

An application is also a class. The views and models are not the regular auto-detected Django models.py and so, but they’re explicitly instantiated “model class wrappers”. That way, you can easily create new combinations of generic models/views/urls with custom tweaks to get new customized apps.

It amazing actually how much of Django’s default behavior keeps working when using eightspaces. They’re happy with it.

Quick and easy django apache wsgi setup with buildout - Reinout van Rees (myself)¶

Buildout has a handy buildout recipe for django. Just adding wsgi=true is enough for adding a ready-made django wsgi script:

[django]
recipe = djangorecipe
version = 1.2.3
wsgi = true
wsgilog = ${buildout:directory}/var/log/django.log
project = deltaportaal
projectegg = deltaportaal
settings = developmentsettings
test = deltaportaal
eggs = deltaportaal

The result: bin/django.wsgi.

But what about hooking it up in apache? Do it with a template that can replace some values for you to get absolute paths in there:

[apacheconf]
recipe = collective.recipe.template
input = ${buildout:directory}/etc/deltaportaal.apache.conf.in
output = ${buildout:directory}/etc/deltaportaal.apache.conf

The apache conf template looks something like this, at least the wsgi parts:

<VirtualHost *:80>
  ServerName xxx
  ServerAlias yyy
  ...
  WSGIProcessGroup some_id
  WSGIDaemonProcess some_id threads=10 maximum-requests=10000 user=buildout group=buildout
  ...
  WSGIScriptAlias / ${buildout:directory}/bin/django.wsgi
</VirtualHost>
WSGIImportScript ${buildout:directory}/bin/django.wsgi process-group=some_id application-group=%{GLOBAL}

apache2ctl -t doesn’t warn about missing log dirs, so your apache can still fail to start up despite saying the configuration is OK. So make sure those directories are there with a small buildout part:

[mkdir]
recipe = z3c.recipe.mkdir
paths =
    ${buildout:directory}/var/log
    ${buildout:directory}/var/media
    ${buildout:directory}/var/sqlite
    ${buildout:directory}/var/static

Wizard-like admin and validation - Joeri Bekker¶

With a couple of big models and a few inlines, you can quickly have a big scrollbar on the left hand side in your django admin. Why not try and get a more wizard-like step-wise interface? That’s what he tried.

The inlines are subdivided into several steps, showing up in separate pages in the django admin. With a “save and go to next step” button instead of just “save”. The advantage? That latter “save” button doesn’t require you to scroll down four pages!

He’ll put it up as a snippet (http://djangosnippets.org/, probably) so everyone can use the trick.

DjangoCon Europe 2011 update - Remco Wendt¶

He showed the new conference logo by Idan Gazit. Nice! The new site will be online soon at the regular http://djangocon.eu address.

The conference days are set: 6-8 June (monday-wednesday). Sprints are 9-10 June (thursday + friday).

We’re aiming for 200 people!

The conference location is reserved (pakhuis De Zwijger), as is the sprint location (an old big city gate building: de waag). The sprint location is available for two full days. Yes, that’s 48 hours non-stop. You can code till you drop! (There are field beds, so you can drop softly.) There’s massive bandwith there, btw.

Hotel rooms are blocked (and will available for booking soon).

Two experienced professional organizers are handling a lot of the practical work, ensuring a smooth conference.

The conference location is well connected. A photo I took from the conference venue back in 2007 (at a Dutch Plone users day) contains pedestrians, cyclists, cars, a tram stop and a train:

To close with: a view from the surroundings of the 2011 djangocon.eu conference location.