Keep in mind as you read this that the Facebook platform is still very new, and likely to change. In fact, if you're a FB user, you are probably aware they recently completed a major transition to a new profile design. This included many changes behind the scenes for developers, some of which are still playing out. I recommend keeping up with the Facebook Platform Developer Forum and the Facebook Developer Blog.

Also, I will assume you have already read the API Documentation and the documentation for PyFacebook, and that you know how to create a web app using Django. If not, you will want to start there.

PyFacebook is very useful and includes some documentation on getting up and running with Django. You do still need an understanding of how Django works and how URLs are mapped.

My goal

My goal with these code snippets and techniques is to make developing a Facebook app as close as possible to developing a regular web app. The application I am using to develop and test these features is The Limerick Book. Compare that page to The Limerick Book Facebook App. In fact, they are the same application, sharing the same code. I also have developed a multiplayer card game based on the traditional Italian game Scopa. This is a Facebook-only application, but I wanted to be able to test it outside of Facebook.

Ideally, we would be able to write code and templates that can work equally well both inside Facebook and outside. This is important even if you want users to only see your application within Facebook, because it makes testing infinitely easier. You want to be able to test on your local machine before publishing content, and you want to be able to test things out free from the limitations and frequent bugginess of the Facebook platform.

First steps

Here are some simple helper functions to make life as a Facebook Python developer easier.

I am making a conscious decision here not to package all these helper functions into a downloadable library. My point here to explain code, rather than just hand it out. Many of these things are specific to my needs, and may not fit exactly what you want, so some tweaking may be required. I have most of these functions in a file called fbUtil.py that I import from most of my Django view code (except for the template tags, which need to be in a specific place, per Django). Feel free to do the same, or to copy and paste the code for your own use, but I recommend reading through the code, as your needs may not be the same as mine.

inFb is a simple function that takes a Request object and returns a boolean telling whether the request is taking place within the context of a Facebook canvas page.

def inFb(request):
    return (request.facebook and
            (request.facebook.check_session(request) or
             request.facebook.in_canvas))

Once we have this, we can create some more useful functions.

facebookUrl = settings.FACEBOOK_URL
def fbReverse(view, args=None, kwargs=None):
    '''
    Much like django.core.urlresolvers.reverse, except works
    in Facebook. Returns an absolute URL to a Facebook canvas
    page.
    '''
    ret = reverse(view, args=args, kwargs=kwargs)
    return facebookUrl + ret[1:] # Remove leading slash

def makeReverse(request, view, args = None):
    '''
    Returns the URL of a the specified view, either in or out of Facebook.
    '''
    if inFb(request):
        return fbReverse(view, args)
    return reverse(view, args=args)

def makeRedirect(request, view, args = None, extra = ''):
    '''
    Returns a Response object for a HTTP redirect, either in or out of
    Facebook.
    '''
    if inFb(request):
        return request.facebook.redirect(fbReverse(view, args) + extra)
    return HttpResponseRedirect(reverse(view, args=args) + extra)

These are designed to simplify URL calculations. See the comments in the code for explanations of what they do.

def makeResponse(request, template, context, common=False):
    context['pageName'] = template
    if (not common) and inFb(request):
        tmpl = 'fb/%s.fbml' % template
    else:
        tmpl = template + '.tmpl'
    return render_to_response(tmpl,
                              context,
                              context_instance=RequestContext(request))

This one is a little different, and may need updating depending on how your code is organized. I keep my templates in the directory 'mySite/myApp/templates' and give them names like 'myTemplate.tmpl'. I put my Facebook-specific templates in the subdirectory called 'fb' and give them names like 'myTemplate.fbml'. This function allows me to create two templates for a view: one for inside Facebook and one for outside. The function will detect which one to use and render it into a Response object. request is the Request object that is passed to the view function. template is a string holding the base-name of the template file, for example 'myTemplate'. context is a dictionary with the template context variables. And if common is True, the function will use the main non-Facebook version of the template no matter what (because ideally we would be able to share even these as much as possible).

One extra little bit that the function does is add an extra template variable called pageName with the base-name of the template. I find this useful for code re-use within templates, though it's not actually a Facebook-related feature.

Authentication

The next thing I wanted to do was to tie in Facebook's user information with Django's authentication mechanism. Depending on your application, you may or may not want to do this. If you want to remember information about user-contributed content, it is useful. The way I did it was to create a UserProfile model, tied in to the User model by a ForeignKey one-to-one relationship, and with a facebookId field (among other, app-specific fields). Then I created a Django authentication backend to allow authenticating by facebook ID. Here is my code for the authentication back end. If a user does not exist with the given facebook ID, a new one is created. (That, of course, may not be what you want, so you may have to modify that code.)

This code assumes that Python's logging facilities have been set up, for error reporting.

class FacebookBackend:
    '''
    Authenticate against Facebook.
    '''

    def authenticate(self, facebookId=None):
        if not facebookId: return None
        try:
            profile = UserProfile.objects.get(facebookId=facebookId)
            UpdateFbUserDetails(profile.user, facebookId)
            return profile.user
        except UserProfile.DoesNotExist:
            # No user. Create one.
            pass
        username = 'fb_%s' % facebookId
        try:
            user = User.objects.get(username=username)
            # This shouldn't really happen. Log an error.
            logging.error('Strange: user %s already exists.' % username)
        except User.DoesNotExist:
            user = User.objects.create_user('fb_%s' % facebookId, '')
        if not UpdateFbUserDetails(user, facebookId):
            return None
        user.save()
        profile, created = UserProfile.objects.get_or_create(user=user)
        profile.facebookId = facebookId
        profile.save()
        return user

    def get_user(self, user_id):
        try:
            return User.objects.get(pk=user_id)
        except User.DoesNotExist:
            return None

def UpdateFbUserDetails(user, fbId):
    """
    Fill in a user's first and last name, from Facebook.
    """
    if (not user.first_name) or (not user.last_name) :
        try:
            fb = get_facebook_client()
            userDetails = fb.users.getInfo(fbId, ['last_name', 'first_name'])
            user.first_name = userDetails[0]['first_name'][:30]
            user.last_name = userDetails[0]['last_name'][:30]
            user.save()
            return True
        except Exception, ex:
            logging.error('Error updating user: %s' % ex)
            return False
    return True

Now here is a function decorator you can use on your view functions. It will perform Facebook authentication if possible. It can also be used to require a login - either via Facebook or through a login page. With a parameter of True, it is equivalent to Django's built-in login_required decorator or to PyFacebook's facebook.require_login decorator, depending on whether the view is accessed inside or outside of Facebook.

def facebookView(requireLogin=False):
    def decorator(func):
        def wrapper(request, *listArgs, **kwArgs):
            facebookLogin(request)
            fb = request.facebook
            if requireLogin and (not request.user.is_authenticated()):
                if inFb(request):
                    return fb.redirect(fb.get_login_url(next=request.path))
                else:
                    return HttpResponseRedirect(settings.LOGIN_URL + '?next=%s' % request.path)
            else:
                return func(request, *listArgs, **kwArgs)
        wrapper.__name__ = func.__name__
        wrapper.__doc__ = func.__doc__
        wrapper.__dict__ = func.__dict__
        wrapper.__module__ = func.__module__
        return wrapper
    return decorator

def facebookLogin(request):
    '''
    Attempt to login the user based on their Facebook credentials.
    Does nothing outside of Facebook.
    '''
    facebook = get_facebook_client()
    if (not request.user.is_authenticated()) or UserProfile.Get(request.user).facebookId != facebook.uid:
        if request.facebook and request.facebook.check_session(request):
            user = authenticate(facebookId=facebook.uid)
            login(request, user)

And here is a very simple example of how to use it:

@facebookView(True) # Require login, in and out of Facebook
def myView(request):
    # Put important view processing here.
    return makeResponse(request, 'myTemplate', {'templateVar':'important data'})

Templates

We are getting closer to the holy grail of being able to write one set of code that can run both in and out of Facebook. It would also be useful to be able to share templates, so I have worked out several mechanisms to facilitate this.

The Context Processor

Django has the useful concept of a "Context Processor," which allows pre-processing of a RequestContext object before the rendering of any template. I take advantage of this quite a bit. I already discussed the cacheBreaker variable in my post about Facebook and JavaScript. Here are a couple more variables I've found useful:

• fb - The facebook object, for accessing the Facebook API, or None outside of Facebook.
• profile - The UserProfile object, if the user is logged in, or None otherwise.
• baseTemplate - The template to extend - either "base.tmpl" outside of Facebook or "fb/base.fbml" inside of Facebook.
• loginRequired - A useful string for including in hyperlinks. Within Facebook, it contains 'loginrequired=true'. Outside of Facebook, it contains something like 'onclick="return checkLogin()"', which is some custom JavaScript to require the user to login before following the link. Of course, if the link already has an "onclick" event, this cannot be used.

I'll leave it to you to write your custom template processor, as they can be very site-specific, but the above should get you started. Here is Django's context processor documentation.

Template tags

To allow more sharing, I've defined a couple of useful template tags. These must be defined in a file in a "templatetags" directory under your application directory, as described in the Django custom tag and filter documentation.

The first is fbUrl. It is the equivalent of the built-in Django url tag, except that when used inside Facebook it produces an absolute link to the requested page within the context of the Facebook canvas. In fact, the code is copied directly from the Django implementation of url. fbUrl relies on the fb context variable, and the fbReverse function, as described above.

from django.template import Node
class FBURLNode(Node):
    def __init__(self, view_name, args, kwargs):
        self.view_name = view_name
        self.args = args
        self.kwargs = kwargs

    def render(self, context):
        fb = template.Variable('fb').resolve(context)
        if fb:
            reverseFunc = fbReverse
        else:
            reverseFunc = django.core.urlresolvers.reverse

        from django.core.urlresolvers import reverse, NoReverseMatch
        args = [arg.resolve(context) for arg in self.args]
        kwargs = dict([(smart_str(k,'ascii'), v.resolve(context))
                       for k, v in self.kwargs.items()])
        try:
            return reverseFunc(self.view_name, args=args, kwargs=kwargs)
        except NoReverseMatch:
            try:
                project_name = settings.SETTINGS_MODULE.split('.')[0]
                return reverseFunc(project_name + '.' + self.view_name,
                                   args=args, kwargs=kwargs)
            except NoReverseMatch:
                return ''

def fbUrl(parser, token):
    """
    Just like Django's url tag, except also works inside Facebook.
    """
    bits = token.contents.split(' ', 2)
    if len(bits) < 2:
        raise TemplateSyntaxError("'%s' takes at least one argument"
                                  " (path to a view)" % bits[0])
    args = []
    kwargs = {}
    if len(bits) > 2:
        for arg in bits[2].split(','):
            if '=' in arg:
                k, v = arg.split('=', 1)
                k = k.strip()
                kwargs[k] = parser.compile_filter(v)
            else:
                args.append(parser.compile_filter(arg))
    return FBURLNode(bits[1], args, kwargs)
fbUrl = register.tag(fbUrl)
                        

Next is fbName. This is to provide the same functionality as Facebook's fb:name FBML tag, except also useable outside of Facebook.

The basic use of it looks like {% fbName user %}, where "user" is a template variable containing the user whose name to display. Then you can add options like linked=false, or useyou=false, as described in the Facebook documentation.

Some differences from the FBML version are:

• shownetwork, ifcantsee, and subjectid are ignored outside of Facebook.
• linked behaves slightly differently. Outside of Facebook, or if its value is set to internal, the user's name will be linked to an app-specific profile page. The view for this page is specified in the variable userProfileView. The view is expected to take one parameter: the user ID.

Here is the code:

userProfileView = 'userProfile'
class FbNameNode(Node):
    def __init__(self, user, args, kwArgs):
        self.user = template.Variable(user)
        self.args = args
        self.kwArgs = kwArgs

    def getBoolArg(self, name, default=False):
        val = self.kwArgs.get(name, default)
        if type(val) is not bool:
            return (val.lower() == 'true')
        return val

    def render(self, context):
        user = self.user.resolve(context)
        fb = template.Variable('fb').resolve(context)
        loggedInUser = template.Variable('user').resolve(context)
        request = template.Variable('request').resolve(context)
        if fb:
            fbUserId = UserFbId(user)
            if fbUserId:
                # In Facebook
                internalLink = False
                ret = '<fb:name uid="%s" ' % fbUserId
                for item, val in self.kwArgs.items():
                    if item == 'linked' and val == 'internal':
                        internalLink = True
                        ret += 'linked="false" '
                    else:
                        if type(val) is bool:
                            if val:
                                val = 'true'
                            else:
                                val = 'false'
                        ret += '%s="%s" ' % (item, val)
                ret += '/>'
                if internalLink:
                    ret = '<a href="%s">%s</a>' % (fbReverse(userProfileView, [user.id]), ret)
                return mark_safe(ret)
        # Not in Facebook
        if self.getBoolArg('useyou', True) and user == loggedInUser:
            if self.getBoolArg('capitalize'):
                ret = 'You'
            else:
                ret = 'you'
            if self.getBoolArg('possessive'):
                ret += 'r'
            elif self.getBoolArg('reflexive'):
                ret += 'rself'
            # ES: How to handle subjectid?
        else:
            ret = UserDisplayName(user)
            if self.getBoolArg('firstnameonly'):
                ret = user.first_name or user.username
            if self.getBoolArg('lastnameonly'):
                ret = user.last_name or user.username
            if self.getBoolArg('possessive'):
                ret += "'s"
        if self.getBoolArg('linked', True) or self.kwArgs.get('linked', None) == 'internal':
            ret = '<a href="%s">%s</a>' % \
                (makeReverse(request, userProfileView, args=[user.id]),
                 ret)
        return mark_safe(ret)
            

@register.tag
def fbName(parser, token):
    '''
    Returns the name for the given user, based on the parameters.

    Acts much like the fb:name FBML tag, except can work in or out of
    Facebook.
    '''
    try:
        bits = token.split_contents()[1:]
    except ValueError:
        raise template.TemplateSyntaxError, "%r tag requires at least 1 argument: the user (%s)" %\
            (token.contents.split()[0], token.split_contents())
    args = []
    kwArgs = {}
    for b in bits:
        if '=' in b:
            name,val = b.split('=', 1)
            kwArgs[name.strip()] = val.strip()
        else:
            args.append(b.strip())
    if len(args) < 1:
        raise template.TemplateSyntaxError, "%r tag requires at least one argument: the user" %\
            token.contents.split()[0]

    return FbNameNode(args[0], args[1:], kwArgs)

def UserFbId(user):
    try:
        return UserProfile.objects.get(user=user).facebookId
    except UserProfile.DoesNotExist:
        return None

Moving on

I think that should be enough to work with for now. Next time, I'll discuss publishing stories to news feeds and all that social good stuff. Until then, please feel free to post any comments, questions, or improvements below.

As I mentioned last time, Facebook lets developers use a subset of JavaScript, which they call FBJS. The FBJS is transformed on the fly into JavaScript as the page is loaded. All variables and functions you define or reference are prepended with a string like "a123456789_", including calls to document.getElementById and setTimer and the like. This is done in order to restrict what you can do with DOM elements, to avoid cross-site-scripting attacks and unwanted user-hostile behavior. FBJS is fairly well documented, so if you plan to do some Facebook JavaScript development, you should start there.

The biggest restriction that FBJS imposes is that you can no longer access the attributes of DOM elements directly, but must go through an abstraction API consisting of a series of setters and getters. For example, instead of saying something like imageEl.src = myImageUrl, you instead need to call imageEl.setSrc(myImageUrl).

This is not too big of an adjustment, if you are accustomed to writing raw JavaScript. It actually has some advantages, because FBJS abstracts away some of browser-dependent aspects into a standard API.

The challenge, however, becomes apparent when you try debugging your JavaScript. With Internet Explorer and its horrendously useless error messages and debugging facilities, it's pretty much hopeless, since the line numbers don't correspond to line numbers in your source code. However, even with Firefox and the wonderful Firebug debugger, all the name mangling and rewriting makes tracking down problems more difficult. Ideally you would want to debug as much as possible outside of Facebook, before then testing on the real site.

To make this easier, I developed some useful code to simulate as much as possible the FBJS environment when running locally or outside of Facebook. The idea was to re-create all the accessor functions on all DOM objects. You can download the file here. You're free to use it, but please don't link directly to the file on my site - copy it to your site and use it there. And read the description below first.

I considered several different approaches before settling on the final version. I considered trade-offs of performance and possible side-effects. Rejected approach number one was to modify Object.prototype to contain the new getters and setters. This would have been the fastest, but can cause problems with code like the following:

for (var param in obj) {
  // Do something with obj[param]
}

This would end up enumerating all of the added functions as well as the properties of the object in question. This is why it is generally considered a bad idea to modify Object.prototype.

The second rejected approach was to create a wrapper class with all the accessor functions, that performs the requisite getting and setting on a member variable containing the actual DOM object. This one could have worked well, but it would have been a lot of code to implement, and would have made debugging with Firebug more difficult because of the added layer of indirection.

The approach I settled on was to simply provide wrapper functions for document.getElementById and document.createElement, and for each element that is "getted" or created, to copy in the required member functions. This has a perfomance penalty during the getting or creation of elements, but the calls themselves are speedy. There is likely to be a lot more manipulation than getting, I would think.

How to use this code

To use this code, just reference this file from your web page before any of your own JavaScript, but only when you are outside of Facebook. Make sure to call fbGetEl and fbCreateEl instead of document.getElementById and document.createElement. In the version of your page that is intended to be run inside of Facebook, include this code:

function fbGetEl(elId) {
  return document.getElementById(elId);
}
function fbCreateEl(elType) {
  return document.createElement(elType);
}

Alternatively, if you are feeling a little tricky, you can add in some code like this to the end of fbHelper.js

document.getElementById = fbGetEl;
document.createElement = fbGetEl;

Then you can continue to use document.getElementById and document.createElement. (Note that I have not tested this approach.)

I hope this comes in handy for some people.

More FBJS tips

Beware of the cache!

If you make a change to your .js file and don't notice any difference in your app's behavior, chances are you are getting bitten by the cache bug. To get around this, Facebook recommends adding "cache-breaker" code to the URL. For example, instead of linking to "myFile.js", link to "myFile.js?v=2". The extra text from the question mark on is usually ignored by web servers for static files. In my Django context processor, I have code like the following:

from svnVersion import svnVersion

# Add this function to your TEMPLATE_CONTEXT_PROCESSORS
# list in settings.py
def fbContextProcessor(request):
    return { # Add any other template vars you want here.
        'cacheBreaker':'?v=%s' % svnVersion }

Then in my template, whenever a have a link, I do something like:

<a href="http://example.com/myFile.js{{ cacheBreaker }}">Click here!</a>
    

      #!/bin/sh
      echo "svnVersion = '`svnversion -n .`'" > svnVersion.py
    

That way, every time I update my code, I make sure to break the Facebook cache. Alternatively, you could call svnversion straight from Python.

console.log is your friend!

This is true in general when JavaScript programming, but especially so with Facebook. Take the time to put in some extra logging messages while you're developing, and testing and debugging will be much easier. And read up on Firebug as much as possible.

Check out the Animation library.

It's pretty cool, and it works outside of Facebook, too.

Beware the limitations.

Facebook only allows up to five external script files, so keep that in mind. You may unfortunately have to combine two or more .js files into one to work around this restriction. Also, FBJS doesn't run on profile pages until the user has interacted with the app.

My setup

Peril 1: Birds of a Feather

Peril 2: Layers of indirection

Peril 3: You're at their mercy

Peril 4: It's different

But I'm doing it anyway

Django templates involve a lot of punctuation. Between the angle brackets and slashes of HTML and the curly braces and percent signs of the Django template language, it's enough to make your pinky fingers hurt just thinking about it. Therefore any little trick to reduce some of this typing burden can be helpful. Presented here is some Emacs Lisp code to provide auto-closing of Django template tags. So even if you still have to type things like curly-brace percent-sign space ifequal blah blah2 percent-sign close-curly-brace, you won't have to type the {% endifequal %}. (Of course, if you're using the abbrev tips I gave previously, you won't even need to type the opening tag very often, but sometimes you still do.)

The code

Ok, here it is. You should be able to copy and paste this into your .emacs file. Then anywhere in your template file, simply call the new function django-close-tag and it will find the last open tag and close it. In the sample code below, I have it bound to C-c]; that is, hold down the control key and press C, then let go of the control key and press the right square bracket. Of course, you can change the code to bind the function to any key combination you want.

(defvar django-closable-tags
  '("for" "block" "comment" "filter" "ifchanged" "ifequal"
    "ifnotequal" "spaceless" "if"))

(defvar django-tag-re
  (concat "{%\\s *\\(end\\)?\\("
          (mapconcat 'identity django-closable-tags "\\|")
          "\\)[^%]*%}"))

(defun django-find-open-tag ()
  (if (search-backward-regexp django-tag-re nil t)
      (if (match-string 1) ; If it's an end tag
          (if (not (string= (match-string 2) (django-find-open-tag)))
              (error "Unmatched Django tag")
            (django-find-open-tag))
        (match-string 2)) ; Otherwise, return the match
    nil))

(defun django-close-tag ()
  (interactive)
  (let ((open-tag (save-excursion (django-find-open-tag))))
    (if open-tag
        (insert "{% end" open-tag " %}")
      (error "Nothing to close"))))

    
(define-key html-mode-map "\C-c]" 'django-close-tag)


    

How it works

The variable django-closable-tags is a list of all the Django tags that require closing. As more tags get added, this list can be expanded.

The meat of the work is done in django-find-open-tag. The first thing it does is search backwards through the buffer for the last Django tag. If the last tag is an end-tag, the function calls itself recursively to skip over that block. This continues until it finds an unclosed tag, which it then returns as a string.

The function you actually call is django-close-tag. This calls django-find-open-tag to find a tag to close, then inserts the appropriate end-tag text.

Hopefully that is pretty straightforward. The only tricky part for a Lisp newbie could be the use of recursion. For a situation like this, recursion is the perfect approach. In a sense, the function calls build a list of closed tags on the call-stack, which then unravels one at a time until an unmatched tag is found.

Other than that, there is some pretty straightforward regular expression matching. These are extremely powerful, and you should read up on them if you haven't already.

Airlines claim the degradation in quality comes from increased competition. They say they are forced to cut corners and reduce features in order to stay competitive. Does this make sense?

What about other industries?

Why has this not happened in the airline industry? Cars and flights are clearly two very different products, but what is the difference that accounts for this discrepancy? The main factor, I believe, is the way people make their purchases. When buying a car, a potential purchaser reads all the specs, he goes to the dealership and test-drives the car and kicks the tires. When the same person buys an airline ticket, he types the itinerary into Expedia.com (or Travelocity, or Orbitz) and gets a list of flights, ordered by price. He picks the cheapest ticket and steels himself for a miserable experience.

"Well," contend the airlines, "people only care about the price of a flight, so we sacrifice the customer experience to meet the demand for lower prices." They now even resort to secret fees for checked bags, in-flight meals, even headphones to watch the movie. This is a sneaky trick to manipulate the search engines. Those extra fees do not show up in the results page. I challenge the assertion that consumers only care about price to the exclusion of other factors. I think the real problem is that price is the only piece of information they are given.

The proof of the pudding

Try it. Go to expedia.com. Fill out the query form. Notice there is no field for the number of checked bags, there is no field for whether you will be having a meal, there is no field for whether you will want to watch the movie. These are important factors that you would want to take into account, but you are not given the opportunity.

Now submit your search. You're presented with a list of flights, with the price in big black numbers and the flight schedule. That's it. No information about leg room, customer satisfaction, on-time performance, in-flight food and entertainment options, cancellation policies, or baggage handling. If you had this information, you would take it into account, but since you don't, you have no choice but to base your decision on price alone.

When I go to Amazon.com to buy a fifteen dollar book, I can read four pages of user reviews telling me about the book. When buying a 600 dollar cross-country flight, I don't see a single user review. There is nowhere for me to enter a review if I want to. The technology is here. It's everywhere. Everywhere except the airline search engines. Why?

Why?

Maybe the airlines are scared to let the consumers have a voice. Maybe they don't want user reviews, because the reviews would be overwhelmingly negative. If so, they are wrong. They're not wrong about the tone of the reviews; they would certainly be mostly negative, at least at first. They are wrong about the effect the reviews would have. In the long run, providing a way for consumers to compare flights and airlines based on more than just price will make flying a more pleasant experience for all. It will allow airlines to compete based on quality, not just price. And it's smart business.

Expedia, Travelocity, and Orbitz are not going to change. They are the Big Three of flight searches. They are cleaning up while the airlines are suffering. There is not enough competition. The only way we will see an improvement is if somebody else steps in and offers us an alternative way to shop for flights. Google, are you listening? Amazon? Apple? Give us more information. Please.

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.

A typical entry:

There once was a girl named Christine
Who had gotten the gambling gene
She said with some sadness,
"I lost at March Madness
Before it reached the sweet sixteen."

Sure, it's no masterpiece, but it's fun. That's sort of the spirit of these contests. Head on over to read more, rate them, or write your own.

Guru: Oh yes, it's soo much better than using tables. Tables are bad, bad, bad! Never use tables!! You'll ruin us all!!!

Student: Um, ok. No tables. But say, I have a question. I'm trying to make my links look like buttons, but when I set a width on them nothing happens. What's that all about?

Guru: Duh! Don't you know, you can't set a width on an inline element? You have to set display:block .

Student: Ah, I see. So now I can set the width, but it just puts each link on a separate line by itself. What if I want three or four on the same line? They're not very wide after all. Could I maybe just use a ta-

Guru: Nooooo! No tables, I said! Look, it's very easy and logical. Just set a fixed width and set float:left on all the items you want on the same line. Why would you not think of that?

Student: Ah, of course, float:left . I guess that should have been obvious.

Guru: Very good.

Student: But wait.

Guru: Now what is it?

Student: Now my buttons are all squished up with the text that comes after them, even if I put a <br> tag after them. Why is it ignoring my <br> tag?

Guru: Don't you know? You should never use the <br> tag! That's mixing layout with content. It doesn't work after floated elements, anyway. You have to make an empty <div>, put it after all the buttons, and set clear:both on it.

Student: Ah, of course. Why didn't I think of that? We wouldn't want to have extra markup who's sole purpose is for layout, would we?

Guru: Of course not. Empty divs and wrapper divs don't count. At least they're not tables.

Student: Ok, now how do I center them?

Guru: What?

Student: I want to center my table of buttons. How do I do that?

Guru: Well, first of all, it's not a "table" of buttons. Don't ever let me hear you use that word again. It's a "list" of buttons. Turn them into a list. Then it's very easy to center them. Set list-style-type:none. Then set display:table, but only in Firefox. You need to use conditional HTML comments for IE. Then set margin-left:auto. That's how we center things, of course. Oh yeah, and you have to enclose the whole thing in another wrapper <div>. Then set text-align:center on the wrapper. See, easy as pie. Aren't you glad we're not in the bad old days, when we used to have to write hacky HTML just to make the layout work?

Student : Maybe I'll go into marketing. (exit stage left)

Sorry, that's what happens when you try to write a limerick after four hours of reading technical specification documents. If you think you can do better, come to our limerick contest website and make an entry, read and rate other entries, and waste some time.

For the developers, the contest site is hosted on Django with a MySQL backend.

There will be a new category of limerick writing contest every month. This month's theme is cheese. Enjoy!

• Go to the limerick contest.

This post addresses the age old question, "If (X)Emacs is so good, why can't it do the typing for me?" Well, the answer, of course, is it can. You just have to write a few lines of Lisp first. Or you can copy and paste the Lisp code off of sites like this one. ;)

Introducing dynamic abbreviations

Pressing M-/, (that is, holding down the Alt key and pressing the forward slash key), runs the command dabbrev-expand, which tries to finish whatever word you are in the middle of typing. For example, if as I'm typing this entry, I type the letter d, then press M-/, "dabbrev-expand" shows up, because that was the last word I typed that started with d. If I then type M-/ again, "dabbrev-expand" changes to "down". If I keep pressing it, the word cycles through different guesses for what I'm going for. If you've ever used VisualStudio, you may see some similarities to the Intellisense feature. I find I almost never type a whole word anymore, I've become so dependent on dynamic completion.

Templates and more abbreviations

dabbrev-expand is useful to avoid having to type long words over and over, but there are also longer patterns that seem to need typing frequently. Thats where the tempo package comes in handy, especially when combined with the abbrev library. Here is some documentation for tempo. Here is some documentation for abbrev.

Essentially, tempo allows you to specify "templates," or blocks of standard text that can be parameterized as they are filled in: the same concept as Django templates, but meant for interactive use. From now on, I will say "tempo template" or "Django template" to avoid confusing the two types.

abbrev lets you define your own pre-set abbreviations, which can be filled in automatically as you type or upon request. This can be combined with tempo to do some pretty powerful stuff very easily.

I have a few Django-specific tempo templates and abbrevs set up in my XEmacs initialization file. For example, as soon as I type "{% block" followed by a space, the entire framework of a Django template block is filled in for me. I've also added a special menu to the menu bar for tempo templates I use frequently.

HTML and templates can be very repetitive, so I've found this saves me a lot of typing.

My initialization file

Here is the subset of my ~/.xemacs/init.el file. This includes the mmm-mode stuff I discussed last time, as well as the tempo templates and abbrevs. I haven't put a tempo template for every possible Django template tag, just the ones I use most frequently. I'll leave further extension as an exercise for the reader.

Also, some people don't like the expansion to happen automatically as they are typing. To turn this off, comment out the line that says "(setq abbrev-mode t)" by putting a semicolon (;) in front of it. Then you can manually expand tempo templates by pressing C-\ (control-backslash).

Once again, this is known to work in XEmacs version 21.4 on Windows XP. It will most likely work in other versions of XEmacs, and possibly in GNU Emacs.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; CSS-Mode
(autoload 'css-mode "css-mode" "Mode for editing CSS files" t)
(add-to-list 'auto-mode-alist '("\\.css\\'" . css-mode))
(setq cssm-indent-function #'cssm-c-style-indenter)
(setq cssm-indent-level '2)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Use hm--html-mode for files that end in .tmpl (Django templates)
(add-to-list 'auto-mode-alist '("\\.tmpl\\'" . hm--html-mode))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Multiple Major Modes.
(require 'mmm-vars)
(require 'mmm-mode)
(require 'mmm-sample)
(setq mmm-global-mode 'maybe)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Custom MMM classes for Django templates
(mmm-add-classes
 '((my-django-expr
    :submode python-mode
    :face mmm-declaration-submode-face
    :front "{%"
    :back "%}"
    :include-front t
    :include-back t)))

(mmm-add-classes
 '((my-django-var
    :submode python
    :face mmm-output-submode-face
    :front "{{"
    :back "}}"
    :include-front t
    :include-back t)))

(mmm-add-mode-ext-class nil "\\.tmpl\\'" 'embedded-css)
(mmm-add-mode-ext-class nil "\\.tmpl\\'" 'my-django-var)
(mmm-add-mode-ext-class nil "\\.tmpl\\'" 'my-django-expr)
(mmm-add-mode-ext-class nil "\\.tmpl\\'" 'html-js)

;; Use different colors for different sub-modes.
(setq mmm-submode-decoration-level 2)
;; Make the code submode a little more readable.
(set-face-background 'mmm-code-submode-face "#EEEEFF")


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Tempo templates and abbrevs

;; Control-backslash to expand a tempo template manually.
(global-set-key "\C-\\" 'tempo-complete-tag)

(require 'adapt) ; Must be done before hm--html for some reason.
(require 'hm--html-mode) ; Needed for hm--html-mode-abbrev-table
(require 'tempo) ; Tempo templates.


;; Expands <span into an HTML span with a class defined.
(tempo-define-template "span"
                       '("<span class=\"" (p "Class? ") "\">" r "</span>" >)
                       "<span "
                       "Insert a template for a span with a class")
(define-abbrev hm--html-mode-abbrev-table
  "<span" "" 'tempo-template-span)

;; Expands <script into an HTML javascript block.
(tempo-define-template "script"
                       '(> "<script type=\"text/javascript\">" r "</script>" > %)
                       "<script "
                       "")
(define-abbrev hm--html-mode-abbrev-table
  "<script" "" 'tempo-template-script)

;; Expands a Django template block.
(tempo-define-template "block"
                       '("{% block " (p "Block name? ") " %}" p "{% endblock %}")
                       "{% block "
                       "")
(define-abbrev hm--html-mode-abbrev-table
  "{% block" "" 'tempo-template-block)

;; Expands a Django template if tag.
(tempo-define-template "django-if"
                       '("{% if " (p "Conditional? ") " %}" p "{% endif %}")
                       "{% if "
                       "")
(define-abbrev hm--html-mode-abbrev-table
  "{% if" "" 'tempo-template-django-if)

;; Expands a Django template for tag.
(tempo-define-template "django-for"
                       '("{% for "
                         (p "Variable? ") " in "
                         (p "List? ") " %}" p
                         "{% endfor %}")
                       "{% for "
                       "")
(define-abbrev hm--html-mode-abbrev-table
  "{% for" "" 'tempo-template-django-for)

;; Create a menu for inserting these templates.
(defun add-templates-menu ()
  (interactive)
  (add-submenu nil '("Tem%_plates"
                     ["{%% %_block %%}" tempo-template-block]
                     ["{%% %_if %%}" tempo-template-django-if]
                     ["{%% %_for %%}" tempo-template-django-for]
                     ["<%_span>" tempo-template-span]
                     ["<s%_cript>" tempo-template-script])))

;; When entering hm--html-mode, turn on abbrevs and add the template menu.
(add-hook 'hm--html-mode-hook
          (lambda ()
            (setq abbrev-mode t)
            (add-templates-menu)))