Make a copy of the base_site.html template in django/contrib/admin/templates/admin/base_site.html and put it in your apps local template path.

Add the following template block to /admin/base_site.html

{% block extrahead %}

    div.grippie {
        background:#EEEEEE url({{ MEDIA_URL }}js/textarea_resize/grippie.png) no-repeat scroll center 2px;
        border-color:#DDDDDD;
        border-style:solid;
        border-width:0pt 1px 1px;
        cursor:s-resize;
        height:9px;
        overflow:hidden;
        margin-left: 106px;
    }
    textarea {
        display:block;
        margin-bottom:0pt;
        width:95%;
        height: 20%;
    }

    $(document).ready(function() {
         $('textarea:not(.processed)').TextAreaResizer();
	});

{% endblock %}

And now you should have nice expandable text-areas that look like this one:

Add your custom templates to your template directory and name them 404.html, 500.html etc.

Paste the following into middleware/errorpages.py

class DummyUser(object):

    def get_and_delete_messages(self):
        pass

class NeedsUserObject(object):

    def process_request(self, request):
        request.user = DummyUser()

In your settings.py add the NeedsUserObject middleware

MIDDLEWARE_CLASSES = (
  ...
    'middleware.errorpages.NeedsUserObject',
)

Update: Aprill 11 – Added toggle_debug, automatically switches debug off when publishing and back on for development.

#!/usr/bin/env python
#
# Simple convience script for common publishing and develop tasks
# This script expects dev_appserver.py to be in your $PATH
import os, sys, re

def main(argv):

    command = ""

    try:
        command = argv[1]
    except:
        usage()
        exit(2)

    if command == 'publish':
        publish()
    elif command == 'publish-debug':
        publish(True)
    elif command == 'runserver':
        runserver()
    elif command == "--help" or command == "-h":
        usage()
        exit(0)

def usage():
    print """
    Usage: python manage.py [command] 

    Commands:
        publish - 'updates' Google App Engine with your current version
        publish-debug - 'updates' Goolge App Engine with debug turned on
        runserver - launches the development server on port 8080

    Options:
        --help, -h - Prints this screen

    For more information on a particular command, run [command] --help
    """
def get_gae_dir():
    """ Locate dev_appserver.py and return the directory is in. """

    # There's probably a smarter way to do this...
    script = 'dev_appserver.py'
    stdin, stdout = os.popen2('which %s'%script)
    xpath = stdout.read().strip()
    stdout.close()
    stdin.close()

    # If the file is a symlink, find out where the actual file lives.
    try:
        tmpdir = os.readlink(xpath)
    except OSError:
        tmpdir = xpath

    return os.path.abspath(os.path.dirname(tmpdir))

def toggle_debug(status):
    st = 'False'
    if status:
        st = 'True'

    os.rename('settings.py','settings.py.bak')
    orig = open('settings.py.bak').read()
    p = re.compile('DEBUG\s=\s(True|False)')
    n = p.sub('DEBUG = %s'%st,orig)
    nw = open('settings.py','w')
    nw.write(n)
    nw.close()

def gae_parent(script):

    DIR_PATH = get_gae_dir()
    DEV_APPSERVER_PATH = os.path.join(DIR_PATH,'google/appengine/tools/%s'%script)

    EXTRA_PATHS = [
      DIR_PATH,
      os.path.join(DIR_PATH, 'lib', 'django'),
      os.path.join(DIR_PATH, 'lib', 'webob'),
      os.path.join(DIR_PATH, 'lib', 'yaml', 'lib'),
    ]

    sys.path = EXTRA_PATHS + sys.path
    execfile(DEV_APPSERVER_PATH, globals())

def publish(debug=False):

    if(debug):
        toggle_debug(True)
    else:
        toggle_debug(False)

    sys.argv[1] = "update"
    try:
        sys.argv[2] = os.path.abspath(os.path.dirname(os.path.realpath(__file__)))
    except IndexError:
        sys.argv.append(os.path.abspath(os.path.dirname(os.path.realpath(__file__))))

    gae_parent('appcfg.py')

def runserver():
    toggle_debug(True)
    sys.argv[1] = os.path.abspath(os.path.dirname(os.path.realpath(__file__)))
    gae_parent('dev_appserver_main.py')

if __name__ == '__main__':
    main(sys.argv)

• Python Only – This doesn’t bother me, but is still a deal breaker for a lot of people.
• No way to schedule tasks. (cron)
• No way to dynamically route subdomains. You can’t point *.yourdomain.com at a single script. So your urls have to look like example.com/tulsa and not tulsa.example.com
• You can’t use any existing libraries that make network fetches. Google forces you to use their URL Fetcher class. Which is broken in several ways:
  • No way to set timeout
  • No HTTP Auth Support
  • Does not follow redirects
• You have to user BigTable for your Database Layer, so you have to port any existing database code you have. There is also no ORM for Django to use BigTable yet, which means Django Admin interface will not work.

On the bright side, their publishing and versioning process is outstanding. The administration interface is pretty sexy so I’ve take quite a few screen shots for anyone who didn’t get an invite and would like to see it.

Some cool points:

• Pure Python 2.5
• Environment includes: Django, PyYAML, and WebOb
• Google single sign on… (Where’s my OpenID suport?)
• Simple URL Fetch API (Think cURL but easier)
• GQL Datastore API
• Mail API

Validation logic should be part of the model

Take a look at this bit of code from Django.

# in visitor/models.py
class Visitor(models.Model):
    name = models.CharField(maxlength=30)
    email = models.EmailField(maxlength=200,blank=true)
    website = models.URLField()
    donated = models.DecimalField(max_digits=5, decimal_places=2, blank=true)

In the Zend_Validator is much more complex, typically happens in the controller and has no direct relationship with the data model your validating for.

$nameValidator = new Zend_Validate_StringLength(1,30);
$emailValidator = new Zend_Validate();
$emailValidator->addValidator(new Zend_Validate_StringLength(0, 200))
               ->addValidator(new Zend_Validate_EmailAddress());

// Zend doesn't have a URL validation class, so we would have to
// create a custom validator that extends Zend_Validate
$website = new Custom_Validator();

// This only validates that the number is a floating point number,
// in reality we would probably have to write another custom validator
// to validate monetary values.
$donated = new Zend_Validate_Float();

The nice thing about Django is the actual database tables are created from the model. So when you declare a name field with the maxlength of 30, your validation rules knows your fields max length because it’s based from the same one line of code the database field was created from! I’m not sure I believe building database tables from your model code is the only way to do things, but I am sure complex validation logic for models belongs in their implementation, not in the controller.

Template inheritance rocks.

This is sadly something I had never seen before. Instead of having half a dozen include statements in each of your views you can just have on that says that it extends your base template. The nice thing about this is the child view/template can override what ever portions of the base template it wants, or it can just go with what the parent has. Django’s documentation has a really good example of template inheritance in action.

An auto generated admin interface is more valuable than gold.

Before playing with Django I watched a few screen casts to get a feel for what it was all about. Then Django seemed like a one trick pony to me and the one trick seemed a bit lame. I mean, auto generated administration interface… who cares. Since then I’ve learned Django certainly has more than one trick up it’s sleeve and their main act is really beautiful in person. It is honestly as robust (or more so) as any administration interface I’ve built in the past. I expected something clunky and extremely _not_ user friendly. I really expected it to generate an admin interface that made it somewhat more convenient for programmers, but wouldn’t work for the average Joe. Well, when they say it’s “production ready” that’s exactly what they mean. The number of hours this saves (that can be spent developing fun stuff) is extremely valuable.

Admin scripts

I know this will sound a bit lazy, but I don’t like having to manually create half a dozen empty folders every time I set up a new project, controller etc. Rails and Django both do a good job of generating framework skeletons for you so you can plug away without missing a beat.

Shell to poke at objects

This is really a language feature and not a framework feature, but you can do some really sexy stuff inside the Django shell like insert a new visitor:

>>> p = Visitor(name="Steven", website="http://steven.bitsetters.com")
>>> p.save()

Or select the last five blog posts

>>> recent = BlogPosts.all()[:5]

This makes it possible to stay in Python land forever if you wish. No bouncing around between SQL and Python.

Built-in development servers make getting started fun

There is nothing like spending half an hour setting up Apache and mod_* before writing your first line of code. Django and Rails bundle a lightweight web server who’s sole purpose is to make development easy and convenient. Unfortunately you won’t be seeing a bundled PHP based web server with your favorite PHP framework anytime soon. Try writing one and see how far you get without things like thread support. PHP is really more of a template language itself than a general purpose programming language. Projects like PHP-GTK make me giggle. Single threaded GUI applications are awsome! </sarcasm>