Sunday, September 20, 2009

Twisted Web in 60 seconds: dynamic URL dispatch


Welcome to the fourth installment of "Twisted Web in 60 seconds". In the previous installment, I showed how to statically configure Twisted Web to serve different content at different URLs. The goal of this installment is to show you how to do this dynamically instead. I suggest reading the previous installment if you haven't already in order to get an overview of how URLs are treated when using Twisted Web's resource APIs.




Site (the object which associates a listening server port with the HTTP implementation), Resource (a convenient base class to use when defining custom pages), and reactor (the object which implements the Twisted main loop) return once again:

  from twisted.web.server import Site
  from twisted.web.resource import Resource
  from twisted.internet import reactor




With that out of the way, here's the interesting part of this example. I'm going to define a resource which renders a whole-year calendar. The year it will render the calendar for will be the year in the request URL. So, for example, /2009 will render a calendar for 2009. So, first, here's a resource which renders a calendar for the year passed to its initializer:

  from calendar import calendar

  class YearPage(Resource):
      def __init__(self, year):
          Resource.__init__(self)
          self.year = year

      def render_GET(self, request):
          return "<html><body><pre>%s</pre></body></html>" % (calendar(self.year),)

Pretty simple - not much different from the first dynamic resource I demonstrated. Now here's the resource which handles URLs with a year in them by creating a suitable instance of this YearPage class:
  class Calendar(Resource):
    def getChild(self, name, request):
        return YearPage(int(name))

By implementing getChild here, I've just defined how Twisted Web should find children of Calendar instances when it's resolving an URL into a resource. This implementation defines all integers as the children of Calendar (and punts on error handling, more on that later).




All that's left is to create a Site using this resource as its root and then start the reactor:

  root = Calendar()
  factory = Site(root)
  reactor.listenTCP(8880, factory)
  reactor.run()




And that's all. Any resource-based dynamic URL handling is going to look basically like Calendar.getPage. Here's the full example code:

from twisted.web.server import Site
from twisted.web.resource import Resource
from twisted.internet import reactor

from calendar import calendar

class YearPage(Resource):
    def __init__(self, year):
        Resource.__init__(self)
        self.year = year

    def render_GET(self, request):
        return "<html><body><pre>%s</pre></body></html>" % (calendar(self.year),)

class Calendar(Resource):
  def getChild(self, name, request):
      return YearPage(int(name))

root = Calendar()
factory = Site(root)
reactor.listenTCP(8880, factory)
reactor.run()





Next time I'll talk about what to do when Firefox requests /favicon.ico from your web app and you don't have one to serve... (ie, error handling).

5 comments:

  1. Very interesting and comprehensive example. But does pure Twisted useful in the production or it should be ran as FCGI application or something like that?

    ReplyDelete
  2. This is probably more of a Python question than a Twisted question but.. Ok it is a Python question - what the heck.

    In the YearPage class definition what is the line 'Resource.__init__(self) doing? I commented it out to see what kind of error it would produce thinking that would help me understand. But the program works just as before.

    It looks like __init__ is just calling itself? Why?

    One more thing... Excellent work on the series! Very clear and to the point. I like it.

    ReplyDelete
  3. It's calling the same method on the parent object, in case it does anything important. Good practice.

    ReplyDelete
  4. Indeed. In this particular example, it turns out that what the parent method does isn't necessary - but that's sort of an accident. The parent method *does* do things, and what it does might change from release to release! So if there is a parent method, you want to call it when you override it.

    ReplyDelete
  5. I read the doc in TwistedMatrix, but it's neither easy understandable nor clear. Your material is far more better :)
    Thanks

    ReplyDelete