FeedMe!

Code should try to be as decoupled from the code it depends as possible, I want me C++ to work with any compiler, I want my web framework to work with any ORM, I want my ORM to work with any database. While all of these are achievable goals, some of the decoupling people are searching for is simply not possible. At DjangoCon 2008 Mark Ramm made the argument that the Django community was too segregated from the Python community, both in terms of the community itself, and the code, Django for example doesn't take enough advantage of WSGI level middlewear, and has and ORM unto itself. I believe some of these claims to be true, but I ultiamtely thing the level of uncoupling some people want is simply impossible.

One of Django's biggest selling features has always been it's automatically generated admin. The admin requires you to be using Django's models. Some people would like it to be decoupled. To them I ask, how? It's not as if Django's admin has a big if not isinstance(obj, models.Model): raise Exception, it simply expects whatever is passed to it to define the same API as it uses. And this larger conecern, the Django admin is simply an application, it has no hooks within Django itself, it just happens to live in that namespace, the moment any application does Model.objects.all(), it's no longer ORM agnostic, it's already assumed the usage of a Django ORM. However, all this means is that applications themselves are inextricably tied to a given ORM, templating language, and any other module they import, you quite simply can't write resonably code that works just as well with two different modules unless they both define the same API.

Eric Florenzano wrote a great blog post yesterday about how Django could take better advantage of WSGI middleware, and he's absolutely correct. It makes no sense for a Django project to have it's own special middlewear for using Python's profiling modules, when it can be done more generic a level up, all the code is in Python afterall. However, there are also things that you can't abstract out like that, because they require a knowledge of what components you are using, SQLAlchemy has one transation model, Django has another.

The fact that an application is tied to the modules it uses is not an argument against it. A Django application is no tightly coupled to Django's ORM and template system is than a Turbo Gears application that uses SQL Alchemy and Mako, which is to say of course they're tied to it, they import those modules, they use them, and unless the other implements the same API you can't just swap them out. And that's not a bad thing.

Last night Django-nyc was generous enough to listen to my presentation Charting Django. The aim of the presentation is to briefly introduce a handful of useful intermediate level Django concepts, which hopefully makes t easier to know where to look (and to know when to look) as you start building more complex applications.

The six features (well, five features and one convention) that I tried to cover were local_settings.py, fixtures, template tags and filters, management commands, custom context and middleware. Kevin mentioned last night--and I think it's hard not to complete agree-that just throwing slides up on your blog doesn't really do justice to the presentation because the best presentations tend to have the least text, but here are the slides anyway.

It was definitely my first time getting somewhere in New York on my own. Somehow I got there five minutes before the presentation was scheduled to begin. Yeah. I need to get out more. I know. I know.

I sometimes use HTTP (Basic) Authentication to authenticate requests to an API of a website. Using cookie and form-based authentication for an API which will be used programmatically is generally a PITA. If the views are exposed via HTTPS (SSL/TLS...