My ToscaWidgets Experience

When I first heard about ToscaWidgets I was excited to say the least. Through the grape vine I heard that it was a new implementation of widgets based on the existing TurboGears widgets. I was immediately drawn to it. I was hoping that it would fix some of the quirks of TG widgets. Unfortunately I wasted quite a few hours and now I still have to roll back to the old TG widgets.

Tosca may be well designed. It may be better, smarter and faster that TG widgets, but much like counting the licks on a Tootsie pop-the world may never know. I blame a lack of real documentation and a lack of examples. I could not find one real example on using forms with TurboGears.

Since I have too many projects on my plate right now I cannot commit to writing a new widget system. I do think it is really needed. Hell…maybe I’ll put in a sleepless night or two to get it done. Either way, I want something with less configuration options and less features. I want dirt simple.

Do your experiences differ?

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati

Kid 0.9.3 Released

This was somewhat of a rush job to fix the issue in ticket #66. For a more detailed list of changes check out the release notes.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati

New Kid Release Schedule

Kid needed a more consistent release timeline. So in order to keep myself on track I added some new milestones and started to plan out the roadmap. If things go as planned I can start knocking out tickets and doing more frequent releases.

If you know of a ticket that you feel is important please make sure it is one of the scheduled 0.9.x milestones. The 0.10 really does not mean much at this point because there has not been any timeframe associated with it.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati

Kid Configuration Consolidation

As the work to simplify the Kid code base continues it became obvious to me that there needs to be a unified way to handle configuration options. Currently there are four ways that default options are set:

  1. Environment variables (e.g. KID_OUTPUT_PY)
  2. String literals (e.g. ‘utf-8′ hard coded in KidParser.__init__)
  3. Global variables in a module (e.g. assume_encoding in kid/__init__.py)
  4. Class attributes (e.g. Serializer.encoding)

Not only are there several ways to do the same thing, but there are subtle bugs lurking. For example, ticket #138 reports an issue caused by the implementation of the class attribute default options.

I have already started down the path toward reconciliation by creating the kid.properties module. The API is light weight and simply consists of get, set and isset functions. The next step is to start refactoring the code to use the new API.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati

Google Summer of Code 2006 Mentor

I have signed up to be a mentor and am looking to mentor projects related to Kid. I may also be willing to mentor projects related to Python web application servers or Python web services. It really depends on the proposal.

I have had a few email conversations with students about some interesting Kid projects. So we’ll see what happens next.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati

Thoughts on Kid

In the last few months I have spent a lot of time patching and extending Kid. During this time I have had to field lots of questions and complaints thrown at me.

The two things that seem to appear the most are concerns about Kid’s speed and it’s lack of good error messaging. I have given a lot of thought to the speed problems in the last few weeks and at PyCon 2006 I had the opportunity, along with Mike Pirnat, to start working on it.

We decided to focus on the speed issue, because that seems to be the thing that turns most people away. Kevin Dangoor also brought up the fact that changes to Kid’s internals may change the solution for the error reporting anyway.

I created a new branch where we could break stuff and not anger any users. Although there is still lots of work two do there were two big wins:

  1. Another developer understands some of Kid’s internals (which is not entirely easy!)
  2. Scripts and tests to help in determine the effect of changes

I have some other more interesting changes in my working copy of the pycon-sprint-2006 branch. After looking at the number of function calls and nested generators it is a pretty good assumption that this can be made faster. I am experimenting with unstreaming parts of Kid. Now since a rewrite Kid’s internals would take a long time and the changes may not help, I wanted to identify things that can be done quickly.

The first step is to eliminate the use of TEXT in the streaming
process. Instead I am attaching the text nodes to the text and tail attributes of elements. This is essentially what ElementTree does. Ideally this will lower the number of times that data will need to go through all of the generators thus speeding up the template.

I am planning on committing code more frequently that I am doing right now. This means that there will be times when the branch is broken. So use it at your own risk!

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati

Easy Install Virtual Python

There are always questions about non-root installations of TurboGears. Fortunately the Easy Install documentation has a section that explains the various options available. I chose to create a virtual Python in ~/vpython/. This seems to work well for me except that to use the virtual Python interpreter I have to use ~/vpython/bin/python. I have create 2 very simple Bash functions to allow me to quickly alias and unalias python.

# Virtual Python
function virpy_on() { alias python=~/vpython/bin/python; }
function virpy_off() { unalias python; }
virpy_on # turn on by default

Typing ‘virpy_on’ or ‘virpy_off’ at the Bash prompt aliases or unaliases python respectively. The alias is on by default.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati

A New Perspective On TurboGears Identity

When I read Jeff Watkin’s post on identity management for turbogears all the pieces of identity finally clicked. I had some ideas that I sent to the TurboGears mailing list, but I didn’t fully understand identity so I could not see where my ideas fit in. Now I have a much better idea.

I spent a little time this morning creating a patch to better illustrate my thoughts. It is incomplete, but in my opinion a valuable step forward. But then again everyone thinks their ideas are great :-) The patch is against revision 100.

Basically the patch tries to decouple the default behavior from the framework. I pulled it into a default module. Eventually I will post more details on the side effects of my changes, but I hope they will be brought up on the TurboGears mailing list.

When the patch is applied only the dev.cfg changed from what Jeff had in his post. In my dev.cfg my identity entries look like:

identity.on = True
identity.filters = [”turbogears.identity.filter.IdentityFilter”]
identity.failure_url = “/login”

Thanks to Jeff for all the work he has put into this. I am really exited about this particular subsystem. This is essential to almost every application that I create.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati

I Attended The First TurboGears Sprint

This past Saturday Mike Pirnat and I drove out to the first TurboGears sprint in Ann Arbor. The trip took a few hours, but our discussions kept it interesting. As we expected we arrived about a half hour late.

Basically Kevin Dangoor (the creator of TurboGears) had created a set of tickets to be worked on during the sprint. A ticket is roughly the equivalent of a small project or task. The group separated into pairs and each picked a ticket to work on. Mike and I got there after the others had separated into pairs so we got paired together.

We were tasked with adding Javascript animation capabilities into MochiKit. We looked at Scriptaculous and Dojo as examples of what to add and decided on integrating Scriptaculous into MochiKit. It was a bit of a challenge because neither one of us had any experience with any of those projects.

Unfortunately we were not able to switch partners or tasks. By the time everyone got setup and really got rolling the sprint was over. There wasn’t a ton of code produced, but the community was being built. I fully expect subsequent sprints to be very productive. It was definitely a worthwhile road trip.

Hopefully I will be able to get to the next sprint. The word out on the street is that it will probably stretch out over a couple of days. So I’d probably get a hotel room and bring the wife and kids. If a remote sprint ever happens I’ll be there for sure.

Other opinions on the sprint:

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati