Reinhardt: a client-side web framework

At PyCon in March, I spoke about how applications can be browser-driven. For the past few months, I’ve been involved with a browser-driven app. Remarkably, some of the same kinds of problems crop up when making a browser-driven app as when you’re making a traditional server-driven webapp. So, today I introduced something called Reinhardt, a client-side web framework. Using Dojo’s Django Template Engine implementation (dojox.dtl), Dojo’s data model ( and Reinhardt’s new Django-inspired URL dispatcher you get something that approximates a server-side web framework all on the client side.

Let’s meet up in Atlanta at PyWorks!


This year has seemed like a big year for Python conference activity in the US. Of course, there was PyCon in March, which topped 1,000 attendees. I’ve also seen announcements for a bunch of regional Python gatherings (like PyOhio, which was close by but I couldn’t attend).

This year, we also get PyWorks, which is joined at the hip with php|works in Atlanta in November. This is the first year for PyWorks, and they’ve got a good lineup going. There’s a day of tutorials and two days of talks, so this is more like a PyCon than it is like those regional conferences.

In addition to attending talks myself, I’m hoping to meet some more good Python and/or JavaScript folks in the “hallway track”. I’m sure there will be lots of Dojo users mixed in with the Python and PHP people, so we should get together.

I have four speaking slots (one of which isn’t listed yet) over the two conference days (gadzooks!). I’ll be doing a revised and expanded version of my PyCon talk “Rich Client Web Applications with TurboGears 2 and Dojo”. I’ll also be giving an updated version of the “Easy build and deployment automation with Paver” talk that Mark Ramm gave in my stead at PyOhio. Paver really puts the “scripting” back in “Python scripting language” (Python certainly does a lot more than “scripting”!)

I’ll also be giving a talk called “ZODB: The Most Underappreciated Library in Python”. The ZODB is great. More people should use it. This is a talk I gave a couple months back at MichiPUG, so it’s only been seen by a small group at this point.

My fourth talk is one I haven’t given anywhere before: “Beyond the Source: Growing Your Community”. I’m going to talk in concrete terms about things you can do to grow an open source community. Open source projects really need to get to a certain level of use before they become viable open source projects, and there are many, many ways in which people interested in a project can help it get there.

I hope to see you there!

The Tech of SitePen Support

I’ve just posted an article with some details on how SitePen’s Support system is built. We use Python on the server and Dojo-driven JavaScript on the browser to create a responsive system. The model we use is similar to what I described in my PyCon 2008 talk where the client is driving the interaction rather than the server.

SitePen’s Support service is built using a variety of interesting techniques and technologies. Read on to see how we built a system that treats the web browser as a real client tier and bridges the worlds of JavaScript, Python and PHP seamlessly to provide a great experience for our customers.

[From SitePen Blog » The Tech of SitePen Support]

A change in Dojo leadership

Alex Russell has announced on his blog:

Two days ago I dusted off the rarely-used voting procedure for Dojo Foundation projects in order to kick off a transition that I’m very excited about: as of this afternoon, the committers of the Dojo project have elected Peter Higgins the new Project Lead for the toolkit project.

[From Dojo Transitions | Continuing Intermittent Incoherency]

So far at SitePen, I’ve had more of an opportunity to work with Peter than with Alex. Peter’s been a knowledgeable, always helpful and fun coworker. He’s going to do a terrific job for Dojo.

Alex has done amazing work to bring Dojo to where it is today (and it’s in quite a good spot). I’m certain that we (the web development community) are going to see very cool new stuff show up as a result of Alex taking a step away from day-to-day leadership on the Dojo Toolkit.

Congrats on the transition, guys!

Dojo Toolbox around the web

Rey Bango at Ajaxian says that “This is a “must-have” for Dojo developers.”. I also enjoyed jdalton’s comment “I totally love this. I don’t even use Dojo and I totally love this. Well done :)”.

Adobe AIR evangelist Ryan Stewart mentions that “it’s basically 100% Dojo”. I did get an email from someone who was curious about what it’s like to create an AIR app using JavaScript. It’s really just like creating any JavaScript-intensive webapp, except you only target one, very capable browser engine (WebKit) and have additional APIs available for things like files, sqlite databases and native windows. Everything you know about web development translates very nicely.

Alex Russell mentions that we were able to port James Burke’s excellent work on the Rhino-based build tool that comes with Dojo. James did a great job on Dojo’s build system. Had he structured things differently, or not written the build system in JavaScript, it would have been difficult to impossible to create the Builder tool. But, as it was things fell into place fairly neatly. We need to get a patch together against Dojo’s build scripts and then the Toolbox will be able to share the code with the Rhino build directly.

Vote us up on DZone!

Peter Higgins, who was quite involved in the development of the Toolbox, put his take up on

And for the German speakers among you, here’s a take on the Toolbox for you. Vielen dank!

What I’ve been up to: The Dojo Toolbox

Today, we unveiled a project that I’ve been quite busy with the past few weeks: The Dojo Toolbox. Check out my First Look article to learn more about it or watch my 5 minute screencast:

The short story is that it’s an Adobe AIR-based app, built with Dojo itself, that gives you a zippy offline API documentation viewer and a graphical user interface for running Dojo builds.

This was my first interaction with the development side of AIR and my overall impression is quite good. The APIs are nicely done, and only having to target WebKit is quite a blessing.

Of course, I’m better known for my Python projects than JavaScript-related projects. In this case, we are using Paver to manage our builds and we also have Python code that processes the API documentation and generates the search index.

My colleagues and I had a great time putting this together. Thanks to SitePen and Adobe for sponsoring this project!

Easy, Repeatable Building/Deployment of Python+Dojo Projects

My latest substantial blog post is now up: SitePen Blog » Easy, Repeatable Building/Deployment of Python+Dojo Projects

Dojo on the client and Python on the server make for a great combination. They’re easy, productive and powerful. In this article, I’ll show you how to use Python + Dojo to cut the number of requests to your server by 95% and simplify development and deployment while you’re at it.

Dojo 1.1 is mighty slick

Alex Russell picked out a few great highlights from the new Dojo 1.1 release and has a nice little essay on open source to boot:

I could go on for a long, long time about what’s great in Dojo 1.1…but I’ll spare you most of that. James, Pete, Dylan, and the release notes can give you a strong sense of why Dojo 1.1 is the most polished, fastest, and easiest-to-use release of Dojo we’ve ever done. For the impatient, you can already start using it from the CDN without downloading anything.
[From Continuing Intermittent Incoherency » Dojo 1.1: Some Awesome For You App]

Dojo is reaping the rewards of having spent a lot of time getting their infrastructure together. 1.1 really improves so many parts of the package.

(ObDisclaimer: I’m not directly involved in the Dojo project myself, but I work directly with core Dojo folks at SitePen.)

Providing support for open source projects

A few days ago I posted a brief blog entry about what I’ve been working on: SitePen Support (Dojo, DWR, Cometd)

We finished the work for the initial launch of this service immediately before I left for PyCon, so I didn’t have a chance to properly blog about it. Getting SitePen Support going has been my primary task in the time since I joined SitePen, so I’m anxious to write about it now that it’s public.

I’m going to start with some of the rationale for the service, and in another post at a later time I’ll talk about how the service is put together.

Imagine that you’re a developer who is facing a deadline or you’re a manager with a team that’s about to become stalled because of an unexpected problem. When working with most open source projects, you’ve got three mighty tools at your disposal:

  1. the documentation
  2. the source
  3. the community

I don’t know how many open source projects you’ve looked at, but #1 is almost always not quite where you want it to be. The unusual situations that are likely to trip you up the most are also the least likely to be documented… so, there’s always #2. Dive into the source directly and check it out for yourself. Of course, Dojo is more than 100,000 lines of JavaScript. Even though it’s nicely organized, there are some tricky concepts being applied and it can definitely take some time to get to your answers.

Which leaves the community. Generally, community support is pretty good at helping you find an answer via forums, mailing lists and IRC. Unfortunately, though, you never know for sure that you’ll get a response from the community, and if you toss a really tricky problem out, project developers might not go after it if they’re in the middle of other big projects.

Now, for Dojo, DWR and Cometd, there is a definite place you can turn for help: the SitePen Support service. SitePen Support is a way for you to bring core project people into your development process when you need them most. All of the plans give you hours of assistance to track down the tricky issues or fix bugs that are important to your projects. They all have a guaranteed initial response, so that you know we’re there keeping an eye out for you. Many of our plans have a feature called “Ask the Experts”. If you can’t find something in the docs, Ask the Experts is a way to find the answer, and we’re even likely to update the docs if need be. For some of the plans, we’ll even troubleshoot and fix your application’s code in addition to the project code.

We’ve also been working on making the service as easy to use as possible. In addition to being able to exchange information via email, we’ve got a Dojo-powered interface for keeping track of what’s going on with all of your support requests.

SitePen Support Screenshot

It’s this interface that I’ll be writing more about later.

If you’re using Dojo, DWR or Cometd and would like some expert help for your projects, check out: