Visions of Aestia

I’ve been planning to learn Django lately, but after working through the tutorial, was struggling a little to figure out ow to model what I wanted.

Then I had a small epiphany - by doing model-first design, I was approaching the problem backwards. As soon as I realised that, I was able to start making real headway on my first project.

Obviously, if you already have a model worked out, model first is the way to go. What is far more valuable for many (especially when prototyping) is to start with the screens - then figure out what model is needed to support them.

So here’s my “backwards” methodology. It’s not a real tutorial, so you’ll need some to look at the actual Django docs.

1. Name your app (the ever popular “myapp” for this exampe) and run “manage.py startapp myapp”
2. Figure out what URLs you’d like and work out the regular expressions to support them. This will tell you which views you need to create.
3. Prototype your screens as raw XHTML + CSS with some placeholder content.
4. Stick the prototypes in the templates directory, then write basic views that invoke the appropriate template.
5. Take a first pass at a model based on the placeholder content.
6. Use “manage.py install myapp” to initialize the database.
7. Fill in some starter content with the shell or the admin app.
8. Modify the views to get model objects and pass them to the templates.
9. Modify the templates to use the passed-in objects.

The nice part of this is that after step 4, you (should) have enough info to build a realistic model, and at the same time you have a static prototype to show to clients. After step 9 you can strip out unimplemented bits from the templates and be in a shipping state; from there on in it’s normal development methodology; including incrementally adding new screens, revamping the URL structures, or evolving the model.

It’s not the best approach for everyone; there are a lot of people who prefer the ‘bottom-up’ approach shown in the tutorial. But I suspect a lot of Web developers prefer to start with the screens and work backwards to the underlying model. It’s certainly more agile since you only need to build the model bits needed to support your screen.