

part 1: the back-end



(part 2 is about changing the interface) colr.org rewritepart 1: the back-end

Summary:

I wanted to use colr.org as a testbed for (a) learning python (b) using the web.py web application framework.

I was worried it might take a lot of effort to learn a new language, a framework, and a different style of web programming (fastCGI) all at the same time. One of those "Bite off more than you can chew, and then chew like hell." things.

Happily, the chewing was good. Colr.org gets a nice upgrade. Python is found to be fun to code in. web.py gets a lot of credit for being a powerful tool in a small package.

Some numbers:

3367 lines of perl (not counting CGI, DBD and other modules)

1304 lines of python (not counting web.py and other modules)

What's good about web.py

It's minimal. In the ecosystem of web frameworks, something needs to occupy the "small, light and fast" niche. web.py is it.

It's capable. Web.py is surprisingly versatile. It runs in regular or fastCGI mode. You can use templates if you want, or skip them. The DB abstraction layer is especially useful and smooth.

It's got good author and community support. Web.py's author, Aaron Swartz, is right there in the discussion group, responding to questions and fixing bugs. A lot people much smarter than me are testing and hacking on web.py.

Debugging is slick. Instad of "500 server error", you get a snippet of the failing code, with the current line highlighted. And the values of all local variables at the time of the error.

What's good about fastCGI

It's zing-fast.

A couple thoughts on frameworks

One reason people use frameworks is that you "get things for free". For instance, in web.py you get automatic input validation "for free."

But ha ha, it's not really free. The price you pay for free things is needing to comprehend them. The more things a framework gives "for free," the greater the burden on the developer to understand how the free things work and interact.

Python code example:

try: new_tags_string = web.input('tags').tags except KeyError: response.success = False response.messages.append('Error! No tag supplied!') print response.write_js() return

Someone new to web.py might wonder about "web.input('tags').tags" Seems redundant, right? Well, it's an abbreviation of:

inp = web.input('tags') # maps user-supplied data to input object, 'tags' parameter is required. new_tags_string = inp.tags # get the value of the supplied tags parameter

Make sense? Those two references to 'tags' aren't redundant. The first is an argument to web.input, saying "throw an exception if this parameter isn't found". The second gets the actual parameter value.

Good frameworks make the free things intuitive or easy to learn. Web.py's documentation is pretty bare-bones, but it's good. It doesn't hurt that web.py is small enough to make checking the source code relatively low effort.

That's all, thanks for reading!

Part 2:redesigning the interface.

questions, comments, suggestions.