Pretty much all the 'work' applications I've built in the last couple of years can be split into 2 parts:

1) CRUD: The database, and a UI for manipulating the data in it 2) LOGIC: The actual application functionality. (i.e. the reason for the app to exist)

These days I'm finding that the amount of actual logic/functionality I put into each app is pretty small, and so part (1) becomes a correspondingly big piece of each application. This is especially true now that we're getting used to gluing small applications together with HTTP rather than building big pieces. This appears to be a global trend - especially with web2.0 mashup buzz and lots of apps that focus on doing a single thing well.

The interesting thing is that the CRUD part is usually pretty generic. One UI fronting a bunch of crud operations on a database isn't that much different to another. Thus it makes sense to factor this out and implement the two parts as seperate physical deployments that share the same database.

Breaking the two parts out means you can choose different technologies for each one. This works really well with web applications because you can stitch the seperate deployments together into a cohesive looking site using links and a shared CSS. In my most recent app I used Django for the CRUD UI, and implemented the application logic (which didn't need much of a UI - it was an opaque service) using tomcat. In fact the actual app functionality was implemented as a single servlet.

So why Django for the CRUD UI? Well mainly because it dynamically creates a pretty sophisticated admin UI for you for free.

Aside: A few years ago I wrote a small webapp that dynamically generated a UI to edit relational database tables. Sortof similar to phpmyadmin, but it used FK information to work out relationships between entities and gave you hyperlinks and drop-down lists. This was fine, except that RDBs don't provide particularly intuitive mechanisms for dealing with complex relationships (ownership, many-many etc..), so you can only get so far using one.

Django goes further than this by moving the model definition from the database into a configuration file (well, actually a python source file but you can treat it as a config file). This allows you to augument the basic entities with relationship metadata. Django can then autogenerate tables from the config (or you can wire the model up to existing tables). However, the icing on the cake is that the config also enables you to give django UI hints for how the dynamically-generated admin GUI should look. I think this is a really powerful idea and gives Django a edge over Rails when building simple CRUD apps.

So this leads me to think that there's a killer business application here just waiting to be written: Decent dynamic RDB CRUD GUIs without code.

(yes, I know dabbledb does something like this, but I think relational DBs are key here. Both because they're well understood by 'business' developers and because they're an excellent technology for integrating data with the 'functionality' bit of an application.)

Here's some basic ideas:

• UI for creating tables and metadata. Metadata stored in the RDB with the tables.
• Auto generated sophisticated admin gui, a-la Django.
• Security model that enables access control at a data level. (e.g. think unix file permissioning: if I add a row, only people in appropriate group can edit it)

It might make sense to actually implement this with django.

(N.B. I'm not intending to actually write this app - I've got my spare-time hands full with large-scale data aggregation. Hopefully somebody else will do it. LazyWeb?)

I've been experimenting with adding openid authentication to django. I couldn't find another software package to do this (although I did see this, which implies there is some other code out there) Anyway - here's mine so far.

The main problem I've hit is that the username column in the django authentication db schema (v0.90) only has 30 characters, so I can't use the openid url as the username.

Instead I'm currently using the first 30 chars of an md5 hash of the url, which sucks. I probably need to create a new openid auth model which holds the openid url and adds a view for getting new users to create a unique username (or something). Or maybe I should contact the django developers about expanding this?... hmm..

I've been porting my jamvat software to the django platform. Django looks cool and I hope it will get me some

• Get jamvat running on the windows platform
• Provide some UI, connection pooling, security and debugging goodies
• Remove some setup documentation burden (since it's a 'django app')

Anyway, I was immediately hit by the problem that the django dev webserver doesn't serve static files (i.e. js, images, css etc..), except for urls in the built-in admin server. I can't work out why, and I can't see why people aren't complaining about this - I can only assume that it wants you to use a 'proper' webserver to serve these files even while you're deving.

I couldn't find a solution to this, so have written a hack that does the same thing as django does for the admin server files. Just set 'MEDIAROOT' and add a 'DEVMEDIA_PREFIX' to your project settings, then run the script instead of 'django-admin.py runserver'.