“Tornado is an open source version of the scalable, non-blocking web server and tools that power FriendFeed”

We’re using Mako to handle our templates (vs the template module that comes with Tornado). It’s super fast and feature rich and has good documentation. Bellow is a base class I wrote that illustrates how to render Mako templates from a Tornado RequestHandler class. It takes care of setting your template directory, template cache directory and your output encoding (utf-8).

Note: This example assumes that you have your template settings defined as tornado options but they could be very easily just hard coded in.

from tornado.web import RequestHandler
from mako.template import Template
from mako.lookup import TemplateLookup
from tornado.options import options

class BaseRequest(RequestHandler):
    def __init__(self, application, request, transforms=None):
        RequestHandler.__init__(self, application, request, transforms)
        self.lookup = TemplateLookup(directories=[options.template_dir], module_directory=options.mako_modules_dir, output_encoding='utf-8', encoding_errors='replace')

    def render_template(self,template_name, **kwargs):
        new_template = self.lookup.get_template(template_name)
        self.write(new_template.render(**kwargs))

Basically you would just derive your handlers from BaseRequest vs from RequestHandler and you will then be able to render your Mako templates via the render_template method.

Here is an example:

class ExampleHandler(BaseRequest):
    def get(self):
        self.render_template('example.html')

Shoot me a comment and let me know if you have any questions.

Now not that there aren’t some decent PHP frameworks out there but lets be honest if I had my druthers the clear winner would ALWAYS be Python/Django. Once in awhile I will get someone who is a little bit more open minded and they will suggest Rails. Which again is fine… I would rather write Ruby then PHP any day but it still is a far cry from Django IMHO.

So my question is this… how do you sell a client on the idea of using Django?! I would love to hear your thoughts about it. To preface my client base is normally entertainment industry based (Record labels, TV networks and Movie Studios). They tend to have overly bloated IT departments that take 7 months to handle an app we can crank out in a matter of weeks. The usual roadblocks I hear are “we don’t support python” or “we have no python resources to maintain the app after your done”. Basically I think my clients tend to think that I’m suggesting they build in Django not out of trying to use the best tool for the job but more as a job security language (jsl).

Anyway as you can prob tell this is a constant source of frustration and any advice would be very much appreciated.

1. Eclipse with PyDev (part of Aptana now)
2. TextMate with Django Bundle (technically not an IDE but allot of people love it)
3. Netbeans with Django Plugin
4. Wing
5. Komodo with Django Komodo Kit

So I’m sure some of you people out there will say man up… use VIM or Emacs… be a real programmer! To that I say have at it. If that’s your preference then do what works best for you. By all means, leave me a comment and tell my how wrong I am and/or glow about how good your IDE/editor is. Long story short Django is an awesome framework and whatever you choose to work in I hope you enjoy it as much as I have.

#A decorator that checks to makes sure a user is active and logged in

from django.contrib.auth import REDIRECT_FIELD_NAME
from django.contrib.auth.decorators import user_passes_test
def active_login_required(function=None, redirect_field_name=REDIRECT_FIELD_NAME):
    actual_decorator = user_passes_test(
        lambda u: u.is_authenticated() and u.is_active,
        redirect_field_name=redirect_field_name
    )
    if function:
        return actual_decorator(function)
    return actual_decorator

You use it in the exact same way you use the normal login_required decorator.

In your view

@active_login_required
def my_view(request):
    # ...

So I pulled the latest Django codebase from svn today and I noticed that my old pagination setup no longer works. Not really surprising as a ton of stuff is being updated due to the coming release of 1.0. So I did a bit of digging into the new pagination code to see if I could rework my wrapper class to work with the new release. It turns out that with the updates there really is no good reason to wrap the classes any more. They have done a good job of working out all the kinks in the pagination setup and it does everything I need it to do out of the box.

So here is a quick nutshell example of how I am using the new django.core.paginator classes to replace the old ObjectPaginator wrapper from my previous example.

in your view:

from django.core.paginator import Paginator

#create a new paginator instance by passing it a collection of objects and the per page count
paginator = Paginator(Contact.objects.all().order_by('last_name'), 10)

#get the page number from a get param
#if param is blank then set page to 1
page = int(request.GET.get('page', '1'))

#grab the current page from the paginator...
contacts = paginator.page(page)

#render the template and pass the contacts page into the template
return render_to_response('contacts.html',{'contacts':contacts})

in your template:
{% for contact in contacts.object_list %}
{{ contact.name }}
{% endfor %}

	
	{% if contacts.has_previous %}previous{% endif %}
	{% if contacts.has_next %}next{% endif %}
	
	
		{{ contacts }}