June 02 2007

Python Web Application Diary, Part Two

In part one of this series, if you are following along, you installed some software components and hopefully have run one or more of the QP demo applications to prove that your configuration is working.

Where Code Lives

I presented in part one some of the choices I've made for my own system configuration as it pertains to file layouts and hierarchies.

QP is able to manage multiple applications, and requires only a little conformity to make that happen. Forget where applications should live? Issue the command qp -h.

Create a library

Throughout this series I'm going to be adding objects and UI elements to my own library, called Parlez (one of these days I'll release it) -- you probably want to create your own support library, maybe you'll call yours "snodgrass" - and add your objects to it. Ensure your library sits somewhere in your PYTHONPATH. Google is your friend. Mine looks something like this:

/www/lib/Parlez/
                bin/
                doc/
                lib/
                    test/
                    ui/
                        test/

/www/lib/parlez -> /www/lib/Parlez/lib

Create an application skeleton

Applications on the other hand are going to live under /var/qp_sites which I've symlinked from /www/qp_sites for my own personal configuration.

To create the application skeleton - something which you'll do frequently - I used to simply cp a template directory. Last night I created a short Python script to do this work for me. mkqpapp.py is available for download: http://mikewatkins.ca/software/files/qp/mkqpapp.py and running it is simple:

mkqpapp.py ~/qp_sites/blog 8011

Which should return with something like:

------------------------------------------------------------
blog application created in /usr/home/mw/qp_sites/blog

To start and stop blog issue the commands::

    qp blog start (or use qp -u blog)
    qp blog stop  (or use qp -d blog)

For more qp command line options::

    qp -h

To view the running application, visit::

    http://localhost:8011/

mkqpapp.py created the following under ~/qp_sites/blog/:

CHANGES
README
__init__.py
bin/
doc/
slash.qpy
test/
ui/
    test/
var/

So lets start it up:

qp -u blog

And visit the page at http://localhost:8011/ which shows:

It worked!

The blog application lives at /usr/home/mw/qp_sites/blog.

In Part Three of this series we'll actually get some code happening.

QP application generator

In preparation for Part Two of the on-going QP tutorial, I whipped up a simple script that automates the creation of a QP application skeleton.

The script lives at: http://mikewatkins.ca/software/files/qp/mkqpapp.py

Using it:

mkqpapp.py </path/appname> <http port number>

eg:

cd ~/qp_sites
mkqpapp.py contact 8011

or:

pwd
/tmp
mkqpapp.py ~/qp_sites/contact

Will both create a QP application called "contact" in /usr/home/yourhomedir/qp_sites/contact.

The script makes some assumptions and enforces a certain amount of sanity; the defaults can easily be changed afterwards.

Source viewing and vim shortcuts

While not strictly relevant to QP, I thought I’d share my editing environment
and a few customizations. I use “vim“ for most work, writing, and email, so
naturally I’ve got a few customizations to help with everyday tasks.

For all the relevant packages I copy or move the extracted tarball sources
into “/www/lib“ and have shortcuts in “vim“ that let me quickly find and
open the source. I’ve also got a collection of vim shortcuts which help speed
up the write and test cycle, including toggling back and forth between the
current module and its corresponding test suite which lives in
“./test/utest_module.py“.

Tag support in vim is handy, so after any upgrade to sources I generate tags
against python packages of interest with a simple script “mktags.sh“::

#!/bin/sh
echo “updating site-packages…”
cd /usr/local/lib/python2.5/site-packages
rm tags
/usr/local/bin/exctags -R—langmap=python:.py.ptl.qpy—languages=python qp qpy durus dulcinea

Sources that I work on have their tag files updated whenever a file is saved
via a ftype hook that calls::

function WritePythonTags()
let foo = system(”/usr/local/bin/exctags—langmap=python:.py.ptl.qpy *.py *.ptl *.qpy”)
endfunction