outsourcing the workshop [10/24/2006 11:42:43]

A while back, Joe Gregorio asked the question: Why So Many Python Web Frameworks?

His answer was: because it's so darn easy to make them. He even cobbled together a framework of his own from readily available libraries. The TurboGears project took the same approach.

I think that actually makes a lot of sense. Joe and TurboGears both use Kid for their templates. It's an XML-based language, which means you can just draw how the page should look in dreamweaver. For HTML, it beats my little template system hands down. The only place I might still want to use zebra is for generating plain text (eg, email). BUT, zebra already compiles down to XML, so why not have it compile down to Kid XML? Then I can throw out half my code.

Same thing with my storage module. SQLAlchemy looks really nice. I can spend a ton of time documenting my module (which isn't even as powerful), or I can update my object-relational mapper to use SQLAlchemy instead. I still prefer using an ORM rather than using SQL, so why not focus on the ORM and outsource the low-level stuff? The only real benefit of my storage mudule is that you can use an in-memory database, which is really nice for testing. But these days sqlite does in-memory databases so much better, and it comes bundled with python already.

Then there's weblib, which basically just has request, response, and session objects. In the old days, my style was strongly influenced by Active Server Pages, and I basically just had python scripts dealing directly with these objects. These days, I try to keep the code platonic (free of any web- or gui- or sql-specific concepts) so I almost never deal with Requests and Responses. So why not ditch that code, and let yaro and flup.middleware.session do the dirty work in the rare cases when I need them?

That leaves me with the platonic stuff, clerks (the ORM module), strongbox (data classes), and a much smaller zebra that just wraps Kid.

I'm using mod_rewrite for my URL routing, but Joe pointed out selector and I really like that. For one thing, it would decouple all this from apache.

There are also a few other things to ditch, like my Date and FixedPoint objects, which now have better replacements.

Doing all this would give me a more powerful framework, with a smaller codebase. More importantly, I'd only have to document and maintain the code I actually care about. It wouldn't take much work, either, since the low-level stuff was all abstracted away to a few corners a long time ago.

So yeah. That's the plan for the framework.