Today's tip is:

Don't Get Trapped in the Django Universe

One of Django's strengths is its "batteries included" approach. It provides for free many of the features you would normally have to write from scratch or cobble together from disparate sources. Some examples are the authentication system, the administrative interface, and the templating system. These are wonderfully useful, and they often work together in ways that separately developed libraries can not. However, not every part of Django will fit your needs all the time. Choices were made in the design of Django, and those aren’t always the same choices you would have made.

Fortunately, another strength of Django is its modularity. It is very easy to unplug one of its built-in features and plug in your own or someone else's. I'll go through some of the Django features that you may want to consider replacing or eliminating.

The important point I want to emphasize is that there is nothing unclean or dangerous about doing this. It's your site, you're the boss of Django, and you should only use the parts of it that you need. I think the creators of Django would agree with me.

The Templating System

There is nothing sacred about the Django templating system, and no reason you have to use it in your application. In fact, the more I use Django templates, the more I appreciate the power and flexibility of Cheetah, and so in most of my recent projects I have used Cheetah for my templates. You do lose out on some of the generic templates and template tags that Django provides, but these are easily replaced, especially because Cheetah allows calling arbitrary Python functions from within a template. As a solo developer, I find this power very convenient.

If there is interest, I will be happy to share some of the functions and code I have developed to make it easier to use Cheetah within Django.

The Authentication System

Django makes it very easy to replace or change the built-in authentication/authorization system. You might want to do this if you already have a system in place: for example, if you use HTTP authentication via Apache. Likewise if you want to do something wacky like authentication by IP address within an intranet. Or maybe you have a completely public site with no need for authentication at all.

The simplest way to customize your authentication is to provide a custom Authentication Backend. But you could go so far as to completely replace or eliminate the django.contrib.auth app. Just be aware that the Django admin site relies on django.contrib.auth.

The Object-Relational Mapping (ORM)

Django's high-level Model and QuerySet interface is great for abstracting away the details of database operations, so it is rare that you need to write raw SQL. So much so, in fact, that you can write a complicated application without even knowing SQL. This is a bad idea, however.

Learn SQL, learn what Django is doing behind the scenes with your queries, and don't be afraid to use raw SQL when it is appropriate. There are some things you just can't do with Django's ORM: for example, any operation that involves reading and updating a field atomically. Other operations are just much faster if you can do them raw. A good rule of thumb is that if you are performing queries or updates inside a Python loop, investigate switching it to SQL. One big query is generally much faster than a bunch of smaller queries.

The Database Itself

Yes! Despite what you may have heard, it is possible to create a web application without a database! In fact, for a recent site I developed I did just that. I use Django in a very bare-bones way: Django provides URL parsing and dispatching, a logical source code layout, the handling of HTTP requests and responses, and some utility functions, but that's it. Apache takes care of authentication, Cheetah handles my templates, and I store user data in a JSON formatted text file. With no database, there is no need for an admin site - I can edit the text files directly in the file system. There are valid reasons for all these decisions, and for this project they fit my needs perfectly. It's still a "Django-powered" site, but only in a very limited sense.

Django Itself

This should go without saying, but for many new developers it needs to be said. A web application does not need a web framework. Blasphemy, I know. But CGI has been around since 1993. Django was created in 2003, and didn't go public for a while after that. So we had ten good years of dynamic web pages before Django even was a glimmer. If you've never done it before, I recommend making at least one pure CGI (or FastCGI) app, so you can better know and understand what Django is doing behind the scenes. It's not magic or mystical or even that difficult. Just as driving a stick-shift makes you a better driver even on an automatic, knowing the details of web protocols will make you a better web developer.

Then when you go back to Django you will appreciate all that it is doing for you, as well as realizing that the Django way is not the only way.

Since this need is so universal, and the basic requirements are so easy to describe, many different groups of people have taken it upon themselves to create Yet Another Template Language. As developers, we can join the fray and roll our own, or we can wade through the myriad options available to us to find the one that meets our needs or philosophy. Those who use PHP or ASP pretty much have the choice made for them, since the languages themselves are glorified template processors. Python programmers have a lot more options.

Here I'm just going to focus on the two Python templating languages I have used in real applications: Cheetah and the Django templating engine. (Django, of course, is more than just templates, but the template subsystem can be used independently.) I use and enjoy both of these, but there are significant differences that are worth comparing and contrasting, when deciding which to use for your particular needs. There are other comparisons out there, including one by the Benevolent Dictator for Life himself (though that's a bit out of date and inaccurate). When choosing which to use, you should read as many opinions as you can, then make the decision yourself. Presented here are just my personal thoughts.

Syntax

Both of these languages are plain-text based, rather than XML based or any other format. This means it's easy to use them for creating formats that are not XML or HTML, like text or even code. It also means it's easy to forget to close a tag or to create non-compliant pages, so always be sure to test with HTML-Tidy or something like that.

The two languages are pretty similar in their syntax, and in my humble opinion, they're both pretty ugly.

Django uses {{ and }} to surround variables to be interpolated. These variables can be passed through a "filter" - a specially designed Python function - using a vertical bar |. One additional parameter can be passed to the filter using a colon :. So, for example, to include a floating-point variable, expressed with two digits after the decimal point, you would write something like: {{ myVar|floatformat:2 }}. There is a lot of punctuation there, but you do get used to it.

Cheetah's variable interpretation looks more like how it's done in shell-scripting languages, with a dollar sign $ and optional brackets { and }, so it looks like $myVar or ${myVar}.

They both also allow some logic and flow control. Django has "tags" surrounded by {% and %}. Cheetah has "directives" that start with # and end with either another # or a newline. Cheetah also allows embedding pure Python using ASP-like <% and %>.

Aesthetically, I prefer the dollar signs of Cheetah for variables, but prefer Django's approach to the logic sections. Either way, you'd better do some finger exercises to limber up before typing.

Philosophy

The major philosophical difference between Cheetah and Django templating is the amount of programming power each system makes available in the templates themselves. In some circles, there is a priority placed on separation of content from code, often going so far as to delegate the tasks to different people. According to this philosophy, designers should work on the presentation, writing HTML and so on, and programmers should work on the logic and back-end behavioral aspects. In the real world, this is an impossible division, because the two are often so closely intertwined, and the very existence of template languages is an admission of this fact. A template is, by definition, a mixture of logic and content. The difference is in the extent of this mixture.

Cheetah makes the whole Python interpreter available to the template writer. Django provides a simple set of "tags" and "filters," allowing limited functionality. These can be extended through "custom tags" and "custom filters." According to the Django documentation, this limitation is intentional, and is meant to limit the mixing of logic and content.

In practice, the mixing happens either way. In Cheetah, it is easy to end up with a whole lot of Python code in the middle of your HTML file, which some would consider inappropriate. In Django, it is easy to wind up constructing pieces of HTML in your code files and passing them to the template processor as parameters. On one side, the Python infects the HTML; on the other side, the HTML infects the Python.

Personally, I'm a one-man development team, so I have no problem with mixing logic and content, either philosophically or pragmatically. I find the Cheetah approach leads to less total code required, plus I'm a big believer in the "we're all adults here" approach to programming, so I prefer the power that Cheetah offers. However, I can understand if people want to limit what logic is available in templates, if they are meant to be edited by designers, marketers, or pointy-haired bosses. In that case, Django might make more sense.

What I use

As I said above, I use both. I use the Django templating system when I am working within the framework of Django. Django does allow you to use any templating system you like, but then you lose the power of the built-in generic views and context processors. I use Cheetah when I don't need all the power of the Django framework (the database access layer, URL dispatcher, authentication, etc.).

I have a slight preference for Cheetah, but they're both very useful. I hope this post provides some help for those choosing between the two.