“Site Components” in Django and TG2

James Bennet responded to my recent post about Pylons, Django, and conceptual integrity.

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.

PartsUsers 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.

9 Responses to ““Site Components” in Django and TG2”

  1. I think WSGI has the potential to enable this kind of high-level sharing in a way that’s fairly unique in frameworks (and not just Python). However, this has only been partially explored. Because a WSGI component (as Ben called them, after PJE insisted what we’ve been pursuing isn’t middleware) is both middleware and application, it has the ability to provide request annotation, response transformations, and serve up its own independent resources, all in one cohesive package. Django has some of this in their middleware, but it’s not as formal or well packaged, or as flexible in how you can put it together (being a straight list that takes global configuration).

  2. I think it’s great to see that this debate has mostly avoided the usual dick-waving and actually accomplished broadening my horizon on this topic and given me and others a better understanding of what sets all these Python web frameworks apart.

    So congratulations on keeping it civil. TG2 sounds mightily interesting, but I think I’ll stick to Django until further notice, but I will definitely look into it when you get around to release 2.0 :)

  3. Well, there can’t be all this talk about pluggability and swappability and what not without a Zope guy throwing his two cents into the ring, and in true Zope 3 fashion, I’ve done so in a much more verbose fashion :)


  4. I agree that Mark has set a very good tone for this debate, and has maintained the mutual respect that there has always been between the TG and Django teams. The dick-waving has normally taken place between the uninformed fringes, and will doubtless continue to do so. That’s what slashdot is for …

    Having used both frameworks I find much to admire in them both. I think at this stage the relative popularity of the projects has primarily been determined by the quality of the available documentation, and I know further efforts in that respect are required for both platforms. The high development velocity means that documentation is always aiming at a moving target, and that can be frustrating.

    It’s particularly frustrating in the case of Zope, where much of what the innocent dabbler finds on the web is either obliquely indirect or just plain outdated and therefore useless. Given the collective memory of the Internet I don’t really see any other answer than to provide more recent documentation that will eventually rise to the top of the Google heap. It might help if people wroe about “Zope3″ rather than “Zope 3″.

  5. Ian,

    I agree that WSGI middleware has the oportunity to provide a whole variety of services to your app. And I see how the lxml html stuff you’ve been working on, as well as WebOb, will make writing very, very flexible components which are even more framework neutral.

    It will be very interesting to see how that works itself out over the next few months. We’ve been talking about extending the general stacked decorator metaphor that’s pretty central to the TurboGears way of doing things, and extending that to WSGI Middleware, which can be seen as application wide decorators. I’m very interested in seeing how far we can play that out in the framework, so that TG’s embrace of WSGI can be seen by our users as an extension of what they already know.

    Thanks again, for building all the tools we need to make this stuff easier. :)

  6. Mikkel, Steve:

    I was a bit afraid when I started bloging about all of this stuff that I’d open up a can of worms with the fanboys. But I’m gratified that everybody on both sides of the discussion has been contributed interesting ideas, and has been willing to talk about things in a reasonable way.

    Not that I was ever afraid that the Django devs would ever be irrational. I consider Jacob, Malcom, Adrian, and the rest of the Django gang to be friends and colleagues, and I’ve nothing by the highest respect for them.

    But, given the size of both our communities, and a couple past skriminshes, I was worried that some folks would get out of hand. And I have been very, very gratified by the fact that there hasn’t been a single bit of crazyness so far. That’s quite a testiment to the maturity of the python community.

    Thank goodness we haven’t had any “TurboGears (or Django) is a ghetto” posts so far!

  7. Mark,

    I am going to have to call you on this. “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”.

    This is in fact TRUE, unfortunately. A recent project I was involved in absolutely could NOT use SQLAlchemy, as it just didn’t make sense to write our own bridge to it, yet we couldn’t use the ORM because of the heavy customization it would make to our databases. If a large company has legacy databases and heavy performance considerations, then Django just wont work for them a lot of them time.

    I think it would be more helpful if Python as a community stopped drinking the Kool-aide and admit we have some incomplete solutions in the Web Framework world. We need some tough love, not sugar coated politics.

  8. Noah,

    I say you can do it, but you loose some things. That’s the simple truth. Take a look at this example of how to do it:


    Now, you loose a lot when you use SA rather than the django ORM, so it may not be worth doing, but you CAN do it.

    import sqlalchemy works just as well in django as it does in pyGTK or WebWare.

    TG2 and Pylons make it totally trivial by setting up all the bells and whistles for you, but it’s not difficult, let alone IMPOSSIBLE do do in django.

    Not sure where the Kool-aid is supposed to have been drunk here, but I’m pretty sure I’ve got a clear picture of what can be done. And am trying to help people see why django makes some of the trade-offs that they do. You may not agree with their choices, but that doesn’t mean you shouldn’t try to understand them.

  9. Mark,

    I think this is largely an issue of semantics, and politics. It is currently not in favor to make any criticism of Django, and instead people must bend over backwards to be as positive as possible even to the point of suggesting the, yes, SQLAlchemy is not hard to integrate into Django. I don’t care about being politically correct. As an engineer, yes a real engineer, politics don’t help me get my job done, facts do.

    There is a real problem of implementing Django into a facility with a legacy database is because the ORM is, as Jonathan Ellis puts it, feeble: http://spyced.blogspot.com/2008/10/formalchemy-10.html As a result you have a choice to make a frankenstein framework that forks Django and goes down a path with your own glue code.

    Personally, at that point, I would rather use Turbogears, Pylons, or just write my own web framework. Large Corporations don’t like frankenstein frameworks, and it gets pretty tough to tell a company they need to change their database to match what Django does. So for me, Django does NOT in fact work with SQLAlchemy. That is my definition.

Comments are currently closed.