Web Framework Wars: Counter-counter-attack

Since ljb doesn't seem to allow comments (I may be missing something), I thought I'd reply to some of what he says in Web Framework Wars Episode 1.

I must say I haven't looked closely at Ruby on Rails. Primarily because I'm not interested in changing to Ruby. (Which I recognise is an argument I hate when people refuse to consider Python.)

I have, however, been keeping up on what one can do with it. I think Ian Bicking describes my thoughts - Ruby on Rails seems to be cool primarily in terms of the integration.

My code probably looks scary because SQLObject and Webware are generic tools, and the code is creating a bridge. SQLObject focuses entirely on providing a relational-object mapping (and just happens to be an ORM too). It has no concept of how to display the objects. Webware, similarly, provides a generic servlet as the most direct way to interact with it.

Let me reply to some things that were missed. SQLObject, too, can just read the schema of the existing table and use that. But instead I created the table from SQLObject, since that's a lot easier for me, instead of swapping to some database schema designing tool. I like the fact I can just forget the database is there sometimes. I hope that gets the overengineering smell away from it.

Webware, I admit, may be overengineered. I only use WebKit, the rest of the stuff in Webware has better alternatives - such as SQLObject and Cheetah. But I don't think you can see any of that from my code. If anything, it seems Webware provides me with almost no ability to do anything useful. I only really use self.request() and self.session() and self.sendRedirectAndEnd() from Webware itself. (And hopefully all that is doable from WSGI.

Having taken a look at how Ruby on Rails deals with this, I've got a few ideas on how better to approach this.

The more I think about it, WSGI has a lot of potential to build a set of components like this that will take Python a step forward by harnessing the effort that had been going into building on differing web frameworks - a problem Ruby hasn't really had.