James describes a core feature of Django (re-usable web-site components they call “apps”), and explains part of the trade-off that the Django community makes:
If you take a little bit less flexibility… in “swappability” of framework components, you can get a useful benefit in return: a set of common APIs that you can rely on, in exactly the way that my generic content tags rely on Django’s model-loading API, or that things like my user-registration and user-profile applications rely on the APIs and near-universality of django.contrib.auth.
And, I think this trade-off is often missed by people critiquing django. People have even gone so far as to say you “can’t use SQLAlchemy” with django — which is just plain false on it’s face. But what they generally mean is that if you use SQLAlchemy you loose the django-admin, the contrib stuff, and many of the conveniences that Django offers. So, fundamentally this isn’t a trade-off that the django developers forced on you, it’s one that django users have to make for themselves. They can either take the conveniences offered by standardized components, or they can go out on their own and use pretty much any component they want. Most people don’t go off on their own though, as “the price is too high.” But “can’t” is definitely the wrong word to describe this.
Users might want to be able to switch our the ORM and still be able to use the Django admin — but I for one am not sure how the Django people could make that happen in a reasonable way, without significant additional complexity.
But I think James is right on target when he suggested (in a past discussion) that users care about reusability at this level a lot more than they care about how much code the framework authors were able to reuse. TG2 users don’t care if we had to write our own transaction middleware or not. But they do care whether or not they have to write their own user-registration system!
And from the perspective of a Pylons user, this is the very reason that TG2 is important. TG2, like Django will define a set of tools that can be used in building re-usable web site components. TG2 users should be able to powerful, reusable components, with SQLAlchemy, Genshi, ToscaWidgets, and the whole TG2 toolchain, and this is one of the core reasons that Ben Bangert and I decided that TG2 should continue on-top-of Pylons rather than just merging the two projects outright.
There’s a lot of work to be done on the TurboGears 2 site-component front, but we’re committed to making it happen, and it will be one of the areas that we’ll be focusing on at the PyCon sprint in March. And DBSprockets is leading the way by showing how we can use the TG2 toolset to build something like the newforms based version of the Django Admin app.
And of course TG2 has another vector of re-usability via WSGI and WSGI middleware, and that’s an important part of the story too. If you can do authentication in middleware (like Kevin Horn has been doing) with a well defined interface between that middleware and the TG2 app, that enforces a level of orthogonality on your code, and provides for all kinds of interesting possibilities. But, that’s a post for another day.