MacDevCenter    
 Published on MacDevCenter (http://www.macdevcenter.com/)
 See this if you're having trouble printing code examples


What Is TurboGears (Hint: Python-Based Framework for Rapid Web Development)

by Matthew Russell
11/08/2005
TurboGears
TurboGears is a Python-based framework that enables you to quickly build database-driven, ready-to-extend web applications. TurboGears can be developed on Windows, Linux, and Mac OS X. It allows you to seamlessly provide HTML or an API for JavaScript to work with, gives your designers room to work with any XHTML tool for building layouts, and enables you to use your database without writing SQL. TurboGears is free and released under liberal open source licenses for both non-commercial and commercial projects.

In this article

  1. It's Kind of Like Rails -- But with Python
  2. Similarities with Rails
  3. A Quick Closer Look at the Stack
  4. An Interview with the Creator of TurboGears
  5. The TurboGears Are Spinning Fast

Rails sure has stirred up a lot of buzz lately (and rightly so), but now there's another great way to develop your next web app. It's lean, it's mean, it's easy to configure and use, and it shouldn't be a surprise that it's based on Python, a language that truly makes the common cases fast and easy. Meet TurboGears -- the powerful new mega-framework that's designed specifically to help you create your next great web app as quickly as possible. And the best part is that you're going to have a lot of fun doing it.

It's Kind of Like Rails -- But with Python

TurboGears stack The TurboGears stack. Image courtesy of Blazing Things.

TurboGears puts together some of the best Pythonic frameworks available to bring you a mega-framework similar to Rails that makes it easy to get a lot of work done in very little time. It's a "full-stack" approach that covers the entire gamut of details involved with traditional web applications. Everything from slapping data down on the disk with SQLObject all the way up to providing a slick AJAX-based user experience with the help of MochiKit, the best JavaScript library you're going to find out there, is included in the package.

Sandwiched in between is CherryPy, the web application framework that makes cranking out dynamic content as easy as writing Python, and Kid, a powerful XML-based templating system. Each piece of the stack does what it does extremely well, and the overall effect of combining the pieces together certainly seems to produce an effect that's greater than the sum of the individual parts. Oh, and by the way, all of those projects are released under liberal open source licenses, as is TurboGears itself. Sound too good to be true? Let's take a closer look.

Similarities with Rails

Perhaps the most important similarity to Rails is the ultra-productivity that you can experience with TurboGears. Do you know of many other frameworks you can use to create a Wiki in only 20 minutes? (Didn't think so.) As we'll see, this productivity isn't the result of rocket science or some kind of profound inner truth. Rather, it's just the natural effect of combining nicely designed software components in a solid model-view-controller architecture.

Notably, each piece of the stack is based on Python, a powerful yet easy-to-use language that heralds itself as making development as simple and quick as possible. Python and Ruby are obviously different languages, but they share a lot of similarities with regard to the perks that they bring to the development cycle. Google's director of search quality, Peter Norvig, recently said, "Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language." Those are inspiring words to hear from a company that obviously has been doing something right.

Another similarity between TurboGears and Rails is that it takes the same basic model-view-controller approach to web development that separates your underlying data and logic from the actual presentation of your content. Not only is code that's written in this way naturally modular, it's also fairly easy to troubleshoot and maintain -- significant factors to consider regarding the life cycle of any project. The model-view-controller approach is the same great methodology that just about any mildly complex application for your Mac is designed with. Examples might not prove anything, but it's hard not to notice how successful Apple has been in leveraging this approach to dish out some pretty amazing applications these last few years.

A Quick Closer Look at the Stack

At the bottom layer of the stack is SQLObject. Essentially, this little marvel removes much of the burden of writing your own SQL queries, and instead, allows you to focus much more of your attention on the modeling process. The basic idea is that classes are flattened into tables and the attributes of the classes become table columns. An especially interesting property of SQLObject is that it tries to be as agnostic as possible with respect to the specific SQL database that you use underneath, so you could transition amongst SQLite and PostgreSQL without hassle.

Here's what's becoming the classic example for illustrating how easy it is to use SQLObject:

from sqlobject import *
from datetime import datetime
        
class Person(SQLObject):

    firstName = StringCol(length=100)
    middleInitial = StringCol(length=1, default=None)
    lastName = StringCol(length=100)
    lastContact = DateTimeCol(default=datetime.now)

That code looks remarkably similar to the following SQL query:

CREATE TABLE person (
         id INT PRIMARY KEY AUTO_INCREMENT,
         first_name VARCHAR(100) NOT NULL,
         middle_initial CHAR(1),
         last_name VARCHAR(100) NOT NULL,
         last_contact TIMESTAMP NOT NULL
     );

Sitting just above the SQLObject layer of the stack is CherryPy. If you've ever done any kind of server-side scripting before with a technology like servlets, you'll find CherryPy to be a very easy way to pump out dynamic content. Here's the classic "Hello World" where you can optionally set the query string parameter who in the URL to display something in the place of "World."

import cherrypy

class MyRoot:
    
    @cherrypy.expose()
    def index(self, who="World"):
        return "Hello, %s!" % (who)

It really doesn't get much simpler than that, and if you're already the least bit Python-savvy, you'll be able to surprise yourself with what you can get done with CherryPy. The performance isn't bad either; the server itself is capable of serving several hundred requests a second, which means that your performance is going to depend mostly on your application's specific code.

Kid is the next layer of the stack and provides a robust XML templating system that makes it easy to separate the content from the presentation of your pages, in addition to simplifying mundane tasks like building tables. For example, take a look at the following code to build a table using Kid:

<table>
    <tr py:for="gear in turbogears">
        <td><span py:content="gear.name">TurboGears</span></td>
    </tr>
</table>

That's easy enough. As you can see, templating engines fill the niche of transforming data that's churned out by an application into a nice presentable format via insertion into a spot template itself. Just think about how much easier that approach makes it to maintain complex hierarchies of documents on sites like eBay and Amazon.

Of course, CSS still styles the actual content that's pushed into the template, but the template itself provides the overall structure for the document. Templating systems provide one of those highly sought-after, win-win situations that allow designers to do what they do best (presentation) and developers to do what they do best (deliver content).

Finally, MochiKit tops off the TurboGears stack by providing a rich JavaScript library that you can use to work AJAX capabilities or those final user-interface tweaks into your application. If you've ever done much work with JavaScript, you already know that development often can be painful because of the lack of standard library functions. Fortunately for us, MochiKit significantly lessens the burden of that very problem, allowing us to focus our attention on more interesting things. Consider the following snippet of code for building a table using MochiKit:

    var rows = [
        ["dataA1", "dataA2", "dataA3"],
        ["dataB1", "dataB2", "dataB3"]
    ];
    row_display = function (row) {
        return TR(null, map(partial(TD, null), row));
    }
    var newTable = TABLE({'class': 'prettytable'},
        THEAD(null,
            row_display(["head1", "head2", "head3"])),
        TFOOT(null,
            row_display(["foot1", "foot2", "foot3"])),
        TBODY(null,
            map(row_display, rows)));
    // put that in your document.createElement and smoke it!
    swapDOM(oldTable, newTable);

A job well done. You'll find all sorts of goodies that'll save you time in MochiKit: logging utilities, AJAX utilities, the ability to fade text, and sorting lists, just to name a few.

And there you have it, the four simple yet elegant components that pack quite a punch when used together -- the power of SQL without writing SQL queries for data storage, a robust and flexible Pythonic web server for generating dynamic content, XML-based templates to provide an overall structure and organization for your documents, and finally, some JavaScript to spruce things up a bit and add some spunk to the user experience.

No doubt, you're wondering how to get started at this point. Well, it's easy. Too easy. Just go out to the TurboGears Mac installation page and follow the steps. All that's required is making sure the correction version of Python is installed and downloading the goods. Then you'll be on the way to creating that Wiki you've always wanted. There's also a massive collection of resources provided to get you up and running. And now, here's a real treat.

An Interview with the Creator of TurboGears

TurboGears is such a cool project that I thought we should try to get some one-on-one time with Kevin Dangoor -- the creator of TurboGears and the upcoming Zesty News product. Fortunately for us, he was more than willing to take a few minutes out of his busy schedule to talk a little more about his work.

MR: I always find it fascinating see the progression of events that leads people to do such interesting things as creating a new framework, so before we get to TurboGears itself, could you say a little about your background? Are you a software engineer?

KD: Yeah, actually my degree is in computer science from the University of Michigan. I graduated in 1994, so it's been a while. I've been programming professionally since 1988, but along the way I've also worked jobs in management, sales, and engineering. I've also had a couple of my own companies, which is something else I bring into this whole endeavor. Interestingly enough, it's not just about the programming -- there's also a lot of product management aspects that come up when you're developing professionally.

MR: So what specifically gave you the inspiration for TurboGears? You obviously had the technical background, but where did the creative inspiration come from?

KD: Well, the inspiration for TurboGears is actually my Zesty News product. While working on that, I needed to have the tools to make the web application itself. At the beginning of the year, I started looking at the various frameworks there were available in an effort to put something together that would do what I needed. Along the way I decided to really emphasize plug-ins for Zesty News, and that was the point at which I decided that I needed to document all of the work I had been doing and put it out there so other people could take advantage of it. Rather than being a sudden flash of inspiration, TurboGears came from an evolutionary process in building Zesty News.

MR: So this effort is a full-time job then? It's not just a part-time effort that you work during the evenings?

KD: Yes and no. You could say that my day job is working on Zesty News -- that's what my company Blazing Things is developing at the moment. But I decided that I would develop TurboGears and get it out to the masses before getting back to Zesty News, because I think that TurboGears is really showing that there is a demand and a real need in the Python world for a "full stack" web framework.

MR: So why is the TurboGears stack so reliant on Python?

KD: I think Python is a really easy to learn and fun language for development, and it's not a very difficult endeavor for anyone who's ever had any programming experience. In fact, I've noticed that a lot of people on the mailing list for TurboGears said that they're new to Python so it looks like there are quite a few people that are coming to Python through TurboGears. I don't think they're finding Python itself to be a very difficult part of the learning process. I personally have been developing in Python for about 10 years, and I consider it my language of choice.

MR: How much "glue code" did you have to write to get TurboGears working?

KD: Well, for the first release, the amount of code involved in putting TurboGears together was quite small. I would say the initial TurboGears release was only around a thousand lines or so. I didn't make any notes at the time, but I really don't think it was more than that. It was really small, and the amount of code necessary to get these pieces working together was negligible because they are so nicely written and had a natural interoperability with other projects. The bulk of the code is naturally going to remain in the individual projects that make TurboGears possible, and hopefully some of the components developed for TurboGears will migrate back out into the pieces of the stack themselves. But overall, the amount of code specific to TurboGears has been growing with each release.

MR: Would you say that Rails has had any impact at all on your design of TurboGears?

KD: Well, actually, when I was starting Zesty News I considered Rails but decided to use Python because of particular Python libraries that are not readily available for Ruby. So, yes, I did look at Rails, but the specifics of Rails weren't really an influence on TurboGears because I started with different tools, namely CherryPy and SQLObject. But conceptually it has the same sort of architecture as Rails. The fact that Rails gives you everything you need for a web application from front end to back end is what was missing in open source previously, and that has been a big influence on projects like TurboGears that have come since.

MR: So what took us so long to get to this "full stack" paradigm of web development like Rails and TurboGears? Is Apache losing any footing here?

KD: Well, I think there will always be room for the servers like Apache in the world because it's hard to beat them for serving up static files and things of that nature. As far as application servers like Rails and TurboGears, however, I think lightweight development processes have actually existed for some time with the net-savvy companies like Amazon, eBay, and Google. These companies have all been using languages like Python and Perl internally so I think the idea has been there longer than you might think. But I think there's a real shift happening in corporate America right now with regard to enterprise-level development. They're finally realizing that they don't have to do things that take thousands of lines of XML configuration and tens of thousands of lines of code when they can rely on smaller and more agile frameworks that are just as capable for the common case -- frameworks like Rails and TurboGears.

MR: What advice would you give to developers who are trying to decide whether or not to choose TurboGears or Rails for their project?

KD: There are definitely some trade-offs and I think they go back to the third-party libraries that are available for Python and Ruby. Python has a lot of useful libraries that aren't available for Ruby yet, but Rails has been around longer so, from a documentation perspective, it is better established -- although we're working hard to fix that. I think the other big thing is that TurboGears and Rails have two different styles of doing things and so it also comes back to preference at some point. It's kind of like that the whole Emacs versus Vim argument. The two tools can do the job arguably equally well, but stylistically they are very different. Hence, people might choose one or the other based on their own personal preference and style. TurboGears definitely has a different style than Rails, and for some people, I think that style will definitely appeal.

MR: AJAX has its place in the TurboGears stack, so does that mean that you think it's here to stay? There has been a bit of discussion about that lately.

KD: I think AJAX is here to stay for a while. Browsers are supporting it more and more, and it is something that you can do to provide a much richer user experience than otherwise. It's possible that new standards will come up and newer standards will change the way we do AJAX (remember, it's more of a concept than it is an entity), but for what it does there is really no better alternative right now.

MR: How well does TurboGears perform and scale when compared with the enterprise-level servers like J2EE?

KD: Really, scalability is more about application design than it is about choosing a particular application framework, and that's just one more reason that TurboGears is a very viable choice. As long as you are designing an application in the way that you need it to scale, you should have no problem using TurboGears that relies on a very high level language like Python. Personally, I've done a lot of Java and J2EE development, and I'm much happier working in Python now. I'm able to get stuff done so much more quickly, I fight with the tools a lot less, and it just seems to be a lot more fun overall.

MR: Since you're mostly flying solo on this project, do you use any particular kind of development cycle, or do you pretty much wing it?

KD: TurboGears development is not a solo endeavor, because there are other people leading and contributing to all of the projects involved with TurboGears. For Zesty News, I very much believe in agile development methods. I've done a lot of extreme programming (XP), and so I also believe very strongly in unit testing. In fact, before releasing TurboGears, I actually put together a testing package called TestGears to make unit testing easier. For that matter, I believe very strongly in test-driven development in general. I usually write the tests before the code. I don't need to do, or believe in doing, a giant functional specification beforehand, because I think it is often a waste of time. But I do believe in going through a process similar to XP. So, yes, even working as a single developer I still feel the need for a development process so that I can make sure I'm heading in the right direction and measuring progress.

MR: You're approaching a v1.0 release soon. How long has it taken to get this far, and when can we expect v1.0?

KD: It was really a process that started at the beginning of the year if you count the selection of tools, defining of requirements, etc. I've gone through a variety of different tools throughout the evolution of Zesty News, and in its current form, I'd say that TurboGears has basically existed since July. That was when Bob Ippolito released MochiKit, which was pretty much the last piece of the puzzle. MochiKit is a JavaScript library that helps handle a lot of front-end tasks. It's been nearly 2 months now that I've been spending almost all of my time working on TurboGears, because I want people to be able to easily develop plug-ins for Zesty News.

Naturally, I don't think I can solve all of the world's problems by v1.0. But plenty of useful functionality already exists, and we are already doing a good job of making sure that anything we change between now and then will stay backwards compatible. Changes are being documented, and we are being very disciplined to make sure that people know about changes that have major impacts when transitioning through major versions. We're currently on the fast track to v1.0, but there is already so much useful functionality in there that there is no reason for people to stand by waiting. Forecasting ahead, v0.9 will be out really soon, and v1.0 should be out by the end of the year.

MR: Great. Well, thanks so much for taking the time to chat. You're doing great work with TurboGears and Zesty News. Keep it coming.

KD: Definitely. This has been fun.

The TurboGears Are Spinning Fast

Kevin and the rest of the crew at Blazing Things are making significant progress on a very regular basis, so check the TurboGears website often for new announcements, screencasts, and tutorials. It's really going to be interesting to see how this project continues to develop and the impact that it has on developers and end users alike.

Matthew Russell is a computer scientist from middle Tennessee; and serves Digital Reasoning Systems as the Director of Advanced Technology. Hacking and writing are two activities essential to his renaissance man regimen.


Return to the Mac DevCenter

Copyright © 2009 O'Reilly Media, Inc.