Posts tagged ‘web framework’

Trembling Aspen

Aspen is a unique Python web framework developed by Chad Whitacre. I am still evaluating it, but one thing I can say unequivocally is that it’s different. Very different. Aspen divorces itself from the MVC pattern that every major — and almost every minor — web framework has been relying on for the past decade. While each framework has its perks and annoyances, they all have this underlying MVC-like interface. Aspen throws that all away.

Aspen lodges itself in a small niche between php-like spaghetti code and a complicated package structure full of python models, views, controllers, and templates. In Aspen, template and control code live in the same file, but in separate pages, called Simplates. In a rebellion against regular expression url parsing, Aspen uses the filesystem to define url structure and paths; like in the old days of statically served HTML files.

One thing I love about Aspen is how easy it is to get up and running. Aspen will serve a single HTML file with no python code without any boilerplate. It serves static files for css, javascript, and images just as easily. To add a dynamic page to your Aspen powered site, you simply use the aforementioned simplates, which include python controllers and Tornado inspired templates in the same file. Aspen provides numerous service connectors, so deployment can also be trivial.

Another great feature of Aspen is its documentation. At first glance, the docs seem sparse and rather limited. However, they are well organized, and every page seems to answer every question I have on the topic succinctly and quickly. Chad seems to have a terrific minimalist policy of telling you exactly what you want to know in as few words as possible. As a writer, I know just how difficult this is to accomplish without repeating oneself.

On the negative side, I do have misgivings as to how well Aspen’s filesystem urls it can scale. Chad has assured me that Aspen is up for running large sites. I appreciate the power of regex urls, and I don’t necessarily like having arbitrary file extensions in URLS. I think locators should be succinct and divorced from implementation details. Ideally, I believe there may be a happy medium between Aspen’s enforced folder structure, and the overly-abstract and overly-complicated url scheme Django and its kin provide.

Another downside is that I haven’t figured out a good way to unit test Aspen simplates. You can refactor much of the code into backend libraries and test that, of course, or you can start the service running and mock requests. However, I miss the TestClient feature from Django that allows me to mock a request without running the server. It provides a better analysis of code coverage, and is closer to the actual code.

Now, with the review over, I’d like to introduce a little project I’ve started to provide some vital features that Aspen core is missing.
Trembling is kind of a catch-all project with a few basic helpers and a few useful projects. Namely, trembling provides:

  • Basic sessions
  • Basic user authentication
  • Less than basic single request messages
  • A simple redirect response

Aspen itself does not define or require a model layer; you’re free to use the ORM, DBAPI connector, or NoSQL database of your choice. Trembling arbitrarily chooses mongoengine for the models. I made no effort to make pluggable backends like Django does; Aspen does not encourage excessive layers of abstraction.

I also don’t know how secure trembling’s session and auth features are. If you find a security hole, pull requests are welcome. Overall, I think the combination of Trembling and Aspen will be very useful for my future basic sites. I would also like to try it on a more complicated project just to see how well it performs.

Introducing Prickle, a time tracking tool

I’ve been doing a lot of Django coding lately, and I’ve been doing it very well. But I’ve felt bit of stagnation settling in. I’ve only been coding what I know. I needed to explore, experiment.

So I picked a couple of technologies I’ve heard about but haven’t tried, and started coding. The goal wasn’t to make something useful, it was to learn some new APIs and frameworks. I accidentally made something useful.

So here I present Prickle. Prickle is a time tracking tool for freelancers written using Pylons, CouchDB, and Jinja2. (Those are the technologies I chose to play with.) I decided to write an app to replace Freckle, a stay-out-of-your-way time tracking tool that has been highly recommended to me by favorite alternate freelancer, Dan McGee. Freckle is a great service, but I have a couple problems with it: I hate hosting my data on other people’s machines, and I hate paying money to use a service. Granted, at $12 a month, it’s going to take me years to earn back the hours I put into developing Prickle, but that’s not the point. Replacing Freckle in my daily use was just a little bonus I got while studying Pylons and CouchDB.

All Prickle does is allow me to enter the number of hours I’ve worked on a project, along with a description. It makes entering hours as simple as possible; the date is selected semi-automatically. Hours can be entered in a variety of formats (0:30, 30, 0.5, and .5 all map to 30 minutes 1, 1:00 1.0 all map to 1 hour), so it tends to “just work”. Project names are autocompleted, so it’s just a few keypresses to get to the description box. Now I type a description, press and I’m done.

There are a bunch of views of the timesheets that allow me to see how much uninvoiced time has been spent on a particular project or during a particular month or day. If I set a rate for a project, I also get a summary of how much money I’ve earned on a given day or month, or how much I’m going to have to bill a client for a specific project.

And Prickle does invoicing. It’s very simple invoicing, but very simple is all that I need. It summarizes the hours since the last invoice was created, displays them in an invoice template (I currently use print to pdf to generate the invoice. Maybe later I’ll automate sending an e-mail to clients). Even here, Prickle has some handy helpers to speed up the process. It keeps track of billing addresses for a given project, so I don’t have to enter it each time, and it guesses what the next invoice number should be so I often don’t have to type it in.

Prickle doesn’t have all the fancy graphs and reports that Freckle has, but it quickly answers the primary questions that I ask of my data: How many hours have I billed today? How much money have I earned this month? Am I on target for this project’s budget?

Prickle is open source, and I’m hoping some people will find it useful enough to contribute back to it. I use it daily already, and don’t really have any complaints. Some things I intend to add include:

* A timer with a pause button. I hated this when I first tried Freckle, but it grew on me.
* improved historic view of invoices
* editing or deleting time entries

Some things I invite others to add include:
* authentication. I like to run things locally, so auth wasn’t important to me. It’s also confusing to implement in Pylons.
* styling. I applied some semi-random CSS rules, but I know it’s ugly.
* browser support. This thing works great in chromium, but I’m using some of the most experimental stuff: html 5 inputs, CSS 3, etc. It’d be nice to add some Javascript to make it work on other browsers.

So, Dusty, now that you’ve played with Pylons and CouchDB, what’s your take?

CouchDB is pretty cool to work with. Map/Reduce based queries take some getting used to, but once you’ve learned them, that’s all you have to know. There’s no tuning SQL, the ORM is a very thin layer, it just works. If CouchDB is as scalable as they say it is, I think I’d like to use it some more.

Pylons is kinda nice. Formencode sucks, but other than that, the libraries bundled with or suggested for pylons are pretty intuitive. I’m finding Django is a bit over-engineered these days, or maybe I’ve just been pushing its limits. I was hoping Pylons would be a less bossy solution, but I don’t think I’ll be switching to it or suggesting it to my clients anytime soon. It seems a bit rough around the center, and doesn’t seem any less complicated than Django, in practice.

Next on my list of tools to play with is node.js. I also want to play with web2py, and I may try a zope 3 app just for fun someday, too.

Web Applications in Python 3

Everyone knows that there aren’t any decent web stacks in Python 3, right? Nobody seems interested in porting Django or Turbogears or Pylons or Plone or Zope to the new, improved much more fun to write language.

Almost true. There are a few less popular frameworks for Python 3, including my own half-finished psyclone: http://archlinux.me/dusty/2010/01/17/python-3-web-framework/

But there aren’t any full stack frameworks. But it’s not too hard to hack one together using available tools.

In my mind, a full stack web framework requires several features:

  • The core server
  • A database engine
  • A templating languages

In addition, it’d be nice if it supported sessions out of the box and had a built-in auth framework. Basically, the more like Django it is, the better.

The good news is, we can hack one together with popular Python 3 ready tools including:

CherryPy provides a working web application engine. SQLAlchemy, which supports sqlite and posgres under Python 3 provides us an extremely flexible and robust ORM. Jinja is an advanced Django-like templating system. I implemented a very basic blog (sans authentication) in these tools in a matter of an hour or so, and it wasn’t any worse to work with than Turbogears. This isn’t a big surprise, since Turbogears is built on CherryPy and SQLAlchemy as well. We don’t have access to the extensive library support Turbogears has to offer, but it is now accurate to say that Python 3 supports a (nearly) full stack web framework.

You’ll need the svn version of CherryPy, and the newly released 0.6 version of SQLAlchemy. Jinja 2 cooperates well.

I don’t find it as pleasant as working with Django (I’m actually not a huge fan of Alchemy’s syntax), but it’s certainly a working solution. It wouldn’t overly much library support to turn it into a really nice system.

A Python 3 Powered Blog

Last week, I posted my intent to port the Tornado web framework to Python 3. Not only have I done that (sort of), but I’ve hacked it to pieces; soon it will be unrecognizable to the original developers, and possibly, to me!

It didn’t take long to get the Hello World example included with Tornado running. Quite a bit more work was the blog demo, but I now have the template, auth, and httpclient modules working, along with the core modules for a working async server. I was able to log into my example blog with my google account, compose some entries, view, and edit them, including the feed.

That doesn’t sound like much if you’re coding blog software for an existing framework (10 minutes in django, probably about 12 in web.py). But if you’re coding a web framework for existing blog software, it’s an accomplishment. I’m proud to have a “working” framework (even though it’s full of bugs and working just means “those things I’ve fixed”) for Python 3 in such a short amount of time.

I’ve named the project psyclone, a play on ‘tornado’ –> ‘cyclone,’ and the fact that Python projects oughta have a ‘p’ and ‘y’ in them somewhere. The code is on github for all to play with. Patches welcome! :-)

I’m having a lot of fun with this project, so it’s taking more of my time than I ought to be devoting to it… on the positive side, it’s progressing rapidly!

My plans:

  • Go over the existing code and improve some of the rather messy unicode/str –> str/unicode hacks I had to make to get it working.
  • Write some tests. (The Tornado team seems not to value tests.) I’ll use py.test and may need to write a test client.
  • Write a session framework and auth framework; the current auth framework uses openID only; but I like a more local solution to be available as well.
  • Consider writing an ORM. Likely, I’ll discard this idea, arguing that Judd was right to design a frameworkwith SQL only. The truth behind the argument will be laziness, of course.

Python 3 Web Framework

I got it in my head this weekend that it was about time someone wrote a web framework for Python 3. My head is kind of stubborn about these things, so I asked it some questions:

Does the world need another web framework?
Do I need another web framework?
Do I have time to do this?

The answers were all “no.” Still, I’m planning to go ahead with it until I get bored. Then the project can sit and collect dust with all my others.

A bit of discussion with The Cactus, led to a few ideas:

I discovered that QP is apparently the “first Python-3 enabled web framework.” I didn’t try it, so I was perhaps unfair in discarding it, but it doesn’t look… suitable.

I looked around some more, and found that CherryPy is about to release a Python 3 enabled version. I’m sure that will spawn a whole slough of Python 3 frameworks built around CherryPy. I considered such a plan (I’d call it ChokeCherryPy based on a receipe my mom devised): create some kind of templating system based on str.format, some session support, and some kind of database module wrapped around py-postgresql. Could be fun. But I’d end up with a mess of third-party technologies much like TurboGears, and that would be embarrassing, plus I’m sure the TG team already has people working on this.

Then I came back to my original plan, which was to port either Tornado or web.py to Python 3. Tornado looks like a smaller codebase (easier to port) and I’ve never used it before, so it’s also a chance to learn something new. So today I forked Tornado on github and run 2to3 on it. I’ve already got the “hello world” demo running; it wasn’t too hard once I figured out the difference between bytes and strings. At least, I think I did that part correctly.

The project is named psyclone, a little play on the ‘destructive weather patterns’ genre. I was close to p3clone, but it’s too hard to convince people it should be pronounced ‘cyclone’.

This isn’t a project I expect to go anywhere; django will be ported to Python 3 soon enough, and other frameworks will be popping up all over. But I’ve been working with Python 3 a lot lately, and I thought it was time to tackle the ‘scary’ job of porting an existing app. It’s tedious, but not difficult.