Pyramid experiment, (temporarily) no Django¶

I’m currently experimenting with a pyramid site at work. Why not Django, which we use for everything else?

(For Pyramid, see a summary of a Dutch Python usergroup meeting talk about Pyramid.)

Current situation: well-structured collection of Django apps¶ Well, our current system (called Lizard) is a big structured collection of Django apps. “Lizard-ui” is an app with base python views (class based views) and base templates for the UI and a whole bunch of css (bootstrap-based) and javascript (jquery, openlayers, lots of extras). This gives you a generic layout with a header, sidebar, the correct colors. Lots of stuff to make it easy to quickly build your project (once you buy into the basic structure and learn to work with it).

“Lizard-map” builds upon lizard-ui and adds map views. Geographical information. Some “adapter mechanism” that basically provides an interface to connect any kind of data source to our map mechanism. There are quite a lot of data sources that we’ve mapped to maps this way. Rendering it, querying, returning a location’s CSV data, a location’s flot/matplotlib graph, combining various data sources, etc. Great to get going, but you do have to get to know the underdocumented interface. And it is clunky in places.

“lizard-something”. Lots of apps (40 or so) that use lizard-ui for the UI and lizard-map for the map stuff. The good thing: we’ve created 20 or 30 sites based on this structure. Mixing various Django Lizard apps. Works like a charm. Why this structure? We made it collaboratively, but there’s a big piece of me at the core. I’m used to base templates (through Plone). I’m used to lots of python packages (so I introduced buildout/setuptools/pypi). I’m used to having a structure to work in. Etc. Why? Well, if you know “belbin team roles” you can look at mine. One of my regular roles is “shaper”. Melodramatically you could translate that with “Reinout, bringer of structure”…

Good points¶ The good things basically comes from using Django as far as possible: A build-in admin. Handy for quickly getting an app to work, often enough for simple admin tasks. We hardly make custom forms (apart from admin.py customizations).

Templates, template inheritance. Django template blocks. Everything inherits from a base lizardbase.html which sets up a bunch of blocks and generic layout and hooks in most of the css.

Views. Class based views that fill in most of the template blocks’ data with good defaults. Override what you need to, leave the rest alone. Inherit from the base templates and you save yourself a lot of work.

Static data: javascript/css. Django’s staticfiles functionality works great. UI/map provide most of the javascript/css libraries that you need in your project. And overriding a logo simply means placing a static/lizard_ui/logo.png in your site to override lizard-ui’s default one.

Django apps. In our case they’re pretty much pluggable as they use the lizard-ui/lizard-map base apps.

The corresponding drawbacks¶ The bad and suboptimal also come from using Django as far as possible: It all works because it is such a high stack. That’s also the problem. You need to buy into the whole stack and you need to work with the whole stack. And you need to get to know the whole stack.

The code and the templates belong together. Templates have an inheritance tree; the view code also. A template needs the view that belongs to it. A view prepares what the template needs. This is one of the main reasons you can develop something quickly, but it also ties you very much to the template implementation. Doing a nice fresh pure html+javascript interface that wants to talk to the site? You don’t know where to start. You have to buy into too much of the stack, currently.

Everything you do pulls in the whole universe. To get your app’s view and template to work, your app depends on lizard-ui and lizard-map. Which pulls in matplotlib (for the graphs), mapnik (for custom map rendering), etc. And a whole bunch of geo libraries. Even if you don’t need them in your app.

Apart from getting the full base template and view functionality, even if you don’t need all of it, you also get a bunch of javascript/css libraries with specific versions even if you need a slightly different one.

Theoretical interlude¶ Lizard does almost everything with inheritance. Inheritance of view code and inheritance (if you can call it that way) of templates. Django makes that easy with class based views and with blocks in templates. At least, it looks that way to me. From reading Pyramid documentation I get the impression that composition is a way better structuring mechanism than inheritance. I have to think about this: would it improve Lizard’s structure? It sounds very plausible.