Datasheet

Part I: Introduction to Python Frameworks

TurboGears accomplishes the few important goals that matter:

❑ It enables separation of concerns, which makes maintenance, revision, and the addition of fea-

tures easier.

❑ It is excellent in the role of a DSL layer that acts as the binding force for well-crafted Pythonic

components at every level:

❑ SQLObject handles the model translation from a relational form (from a SQLite or MySQL

database) to a Python object form (and back).

❑ The Kid templating engine, which can be used standalone at design time as well as in the

deployed RIA, is filled in by the TurboGears layer with data from the model. The advantage

to running standalone at design time without the backing model or controller logic having

been fully developed is that it enables application developers and UI designers to work in-

dependently, in parallel, and then converge somewhere along the development path.

❑ Within the browser, JavaScript logic is organized through MochiKit, which has the

avowed aim to “make JavaScript suck less.” Put in more polite language, MochiKit collects

a wide array of loosely related JavaScript functions into a single library, and offers a very

Pythonic-looking API for method invocation. Chapter 11 covers MochiKit in greater detail.

❑ CherryPy creates the web server layer and the control path for transmitting the business

logic to the Python code — at least for the development phase. It is likely that for deploy-

ment, especially if you use a commercial-grade ISP, you will have to deploy primarily on a

web service engine such as Apache.

Leveraging the Power of Django

Django’s design center is rooted in the specific domain of content management systems. As such, it’s

somewhat more focused than TurboGear, which as suggested in the previous section, is much more of a

general tool for producing Web 2.0 applications. Thus, where TurboGears is widely focused, Django

tends to feel more narrowly focused. Django was created to facilitate creating a daily online newspaper

with dynamically generated columns and pages. As you work with both of these frameworks, you will

come to appreciate the differences and, more importantly, why the application spaces of interest to dif-

ferent designers forced specific design decisions.

Leveraging the Power of Python

There is probably very little you don’t know about Python unless you’re new both to Web 2.0 develop-

ment and to agile languages. But at the risk of telling you things you may already know, there are a few

important things that ought to be said of Python as an undercarriage for Web 2.0 frameworks. If you pro-

gram in Python, you already have experienced some of the attributes that make it a very suitable base.

First of all, Python is an agile, high-level, and interpreted language. For Web 2.0 development, this

means that you can write a little, test a little, and deploy a little. This is a perfect quality for iterative

development, and is especially perfect for creating the experimental, fast-changing applications in the

Web 2.0 space. Applications change quickly here during development and testing, because they are

generally driven by the passion of small teams rather than large companies seeking to implement a

service-oriented architecture with many moving parts and several months or years to achieve results.