Goals and requirements
One of my goals in this project is to be fairly agnostic about web frameworks. I am specifically focusing on template systems and presentation logic because that’s where my interest lies, and because there are already some excellent resources comparing web frameworks themselves, such as Ian Bicking’s Web Framework Shootout and Michelle Levesque’s PyWebOff.
With that in mind, here are my requirements for the back-end (that is, the framework that will drive all of these templates):
Nothing fancy
The interface to the back end should be simple. I don’t need a distributed RDBMS system with an ORM or an RSS2 interface which automatically pings del.icio.us; basically what I want is a form that lets me specify some sample data and select a template system, and which will then construct view objects containing the data, pass them to the given template engine for rendering, and display the results.
I also need to have this interface be a basic CGI script. This helps with simplicity, but is also a requirement because it’s easy to run locally, and if I put up live examples it will be easy to host them at my (cheapo) web hosting provider.
Fairly distinct view objects
There is some ambiguity in the MVC pattern between which objects belong in the view and which ones belong in the model. I am taking a somewhat conservative approach here of assuming that the model—that is, the hypothetical one that would exist in a real web application—that underlies everything creates separate view objects, probably containing copied and rearranged data from the model, and then passes these objects to the presentation layer.
In practice, I’m not sure how many python web frameworks really work this way; it’s a somewhat over-engineered approach that’s probably more common in languages like Java. Python is dynamic enough that for most web applications, just passing in elements of the model objects themselves (and requiring the templates or their associated presentation logic to arrange the data correctly) is probably perfectly adequate. It will help me out to look at things this way, though, since I can develop neutral view objects that seem like "natural" depictions of a bunch of data, and then pass them in to each template system in turn.
Implications
Because of the “nothing fancy” approach, I won’t be directly addressing some of the interesting aspects of template engines. I’ve already mentioned that I’m going to focus on platform-agnostic systems, but running everything in a plain-vanilla CGI script means that it will be difficult to measure the relative performance of various engines. Many of these systems will compile a template to a python module. Many will allow one to keep a reference to a template object in memory and repeatedly apply new values to it. Things like this are very useful if the application server as a whole is a long-running Python process such as a Webware or mod_python installation. In a CGI environment, they could actually hurt performance.
I’m also somewhat concerned that my using a unified back-end I’ll be forcing template engines into idioms that aren’t necessarily natural to them. One of my goals is to try to implement various problems using their native idioms, rather than trying to impose too many of my own ideas about how a template engine should work on top of them. On the other hand, I’ll want to have a certain amount of consistency or I’ll go quickly crazy, besides which many idioms may be entirely undocumented.
Next
I present my lightweight back-end framework, Pity. From there, it’s on to some actual comparisons, starting with a quick comparison between a bunch of engines before I focus more deeply on one or another of them.