What is bfg?

bfg is a smallish webframework for python that I would put in the same vein as pylons. If you don’t know, pylons is the framework underlying TurboGears 2. It provides a standard means of routing a request to a controller method via route matching.

BFG on the other hand routes a request differently by default. It uses something called model traversal. What this basically means is based on the request, a model object is chosen as the context. Then a view is selected by referring to a configuration file (configure.zcml), the selected view is then given the request and the context as parameters to do what it needs to do to generate a response.

I mentioned that it does this by default, but it doesn’t have to. There are ways to route a request similar to how pylons does it. And there are pros and cons of doing it this way.

However, the vibe I get from the documentation is that some other features such as Access Control Lists(ACL) are meant to work with model traversal. So using something other than model traversal limits your options in some ways.

The application we’ll be going through in this series uses model traversal, because the series is about BFG.

Why I chose bfg

I have played with many python web frameworks over the years. As of late, I’ve been more comfortable with the frameworks that let you use only what you need to without buying into some development philosophy. I suppose I’m stubborn that way. But this is the reason I was led to Turbogears so long ago. Unlike Django, I appreciated the idea of using a best of breed set of libraries rather than completely re-invent the wheel. I realize that clearly I am in the minority as far as this goes and there are likely a million happy Django user that will gladly tell me I’m doing it wrong.

Here’s my big contradiction. I have always admired zope and plone from afar. Occasionally I have tried to get up to speed on both of them and failed miserably. The learning curve, as most will tell you is very steep. Nonetheless, there’s a lot of cool stuff there to be jealous of. In contrast to pylons, turbogears and even django, zope and plone are very heavyweight frameworks.

So I admire heavyweight frameworks, but prefer lightweight frameworks. Yes, I probably need therapy. But why bfg?

Until I came across bfg, I was happy hacking away in pylons. Sure I had a few issues with it, but for the most part it stayed out of my way. I first started to question whether pylons was the right framework for me when I started toying with ways to break up functionality that can be shared across web apps. There would be occasions where I would wish I had something similar to drupal s plugin architecture. Or more in general, drupal without the php. Other times I’d marvel from afar at the whole slew of pre-built django apps that you could use to build yet another social networking site.

But for the most part, I basically just wanted to write user registration logic one last time and then plug it in wherever I needed to. I did a raw wsgi solution that kind of worked but it was ugly.

When I found bfg, I was intrigued. It shares some of the zope philosophy, but it is lightweight. In my mind this is a win win. Other things that caught my eye.

• Support for authentication that is pluggable.
• Support for authorization which is pluggable.
• Super fast templating via chameleon.
• Support for Access Control Lists that can go down to the model instance, in other words you can configure stuff like “No one can edit this but the person who created it or an admin”.
• Ability to define events that other code can react to.
• Can still be launched via paste.deploy with a configuration ini file just like a pylons app.

The Demo App

There’s a fully functioning version of the demo and the source code for the application I’ll be covering. You can log in as guest/guest if you want to take it for a spin. I'll probably be wiping the db each day.

My motivation for writing this application was to hopefully offer a way for people on our team at work to communicate in a way that doesn’t clog up my email with things that are only important for a defined date period.

For example, an email to everyone announcing that you are sick and/or are working from home is important to me if I need something from you that day. It may not be important when it arrives at 8am, but may be important at 3pm when suddenly your assistance is required. By then there may be 50 other emails burying the now important information.

Another example, is an email announcing something that will be relevant for a period of time. Like, “Regression Testing 1/10/2009 - 1/14/2009” or “Deployment this weekend”. The problems I perceive with using emails for these kinds of things is that it’s lost in the noise and the time of delivery of the information and the time that the information may be relevant are not the same.

So if instead I could convince my team to use a simple web application to enter things that are important for a period of time, the anticipated advantage is team member can refer to it when they need to without having to filter through 50 emails.

I want to have a homepage that says....

So this is the gist of the application I’ll be going through. It’s complex enough to be interesting, but not too complex that it distracts from covering bfg.

I should also point out that by virtue of bfg being a lightweight framework, a lot of other libraries will be used along the way.

For this project I used sqlalchemy, toscawidgets, tw.forms, and a libary I wrote and use called identity.model. I am of the opinion that it is a good idea to get familiar with WSGI, and Paste. So inevitably I’ll probably cover some aspects of all of these as I get through the series.