Yesterday we were working on the KARL project, doing some post-deployment housekeeping. Specifically, we had a checkout of the templates that had a local customization (injecting Google Analytics) that we didn’t want to check in. At least not to the software repository itself. We wanted building a demo KARL to have no analytics, certainly not OSI’s account.
The most logical thing would have been to throw ZPT at it and get a little snippet of HTML to jam in just before closing the body tag. But that would mean going to a number of places and injecting calls, plus we’d have to grab the configuration data from somewhere for the right snippet.
Tres and Chris Rossi argued for middleware: something that would watch the outgoing HTML and inject Google Analytics in the appropriate circumstances. An hour later, Tres had written repoze.urchin that parameterized in the Paste configuration file the data, then hacked the HTML on the way out.
When to use and not use middleware is an art that I’m still learning about. The biggest two rules appear to be, don’t solve a problem with middleware if the application won’t run without it, or if the middleware requires access to information inside the application.
