Visions of Aestia

One of the reasons I’m implementing my own wiki instead of sticking with MediaWiki is that I hate PHP. Another, more valid reason is that I want to experiment with better approaches to dealing with structured information.

I picked Django for my implementation, because most of the code I’m going to integrate (such as sparta) is already in Python. I also think the model closely fits what I want to do.

Here’s some samples to help make it clear what types of things I want to do.

Normal XHTML wiki stuff - for starters, we can just do the normal wiki magic. Some subset of this stuff will also work for other mime types but the focus is on text.

• /pageName
• /pageName/+edit
• /pageName/history

Structured document export formats - It won’t be perfect until we modify the input language, but we can get something quite reasonable in most cases.

• /pageName/format/odt
• /pageName/format/DocBook
• /pageName/format/pdf

RDF - Of course, this is the real motivation. Here we’re dealing with all the abitrary RDF you want to provide. The first one will be an XHTML page displaying the data; the others will be served with more appropriate mime-types.

• /pageName/metadata
• /pageName/metadata/rdf
• /pageName/metadata/n3
• /pageName/metadata/+edit
• /pageName/metadata/history

Explicitly supported subsets - This is the kicker. We explicitly provide display and edit support for specific ontologies (especially ones that are easy to implement).

• /pageName/metadata/foaf/
• /pageName/metadata/DublinCore/+edit

I’m still ramping up on Django, so I’m still looking at the basic XHTML stuff, but already I have XHTML strict output for straightfoward MediaWiki markup, including tables, and tomorrow I hope to have the full page lifecycle implemented.

I’m also very much cheating by just grabbing some MediaWiki output and using that as the basis for my initial templates; that way I have something familiar-looking to experiment with.

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.

Back in September I started transitioning to a new (virtual) server. I moved everything over, upgraded all the software and never got around to updating DNS.

I figured I’d stop blogging until the new server was up - which was when I got the distro mastered. Which, of course, has stil not happened.

So, I’ve started blogging again, today. Lots of writing in the queue and I really need to get moving. But I’ve disabled comments until the transition is complete. That way I have a reason to actually, you know, finish the server transition.