Clever Name TBD

Yes, it's been done a thousand times, and I've gone and reinvented the wheel by creating yet another templating system for HTML. You might wonder what might posess me to do that, and the answer is that, basically, they all suck. It's entirely possible that mine sucks as well, but it works for my needs, and that's what I wrote it for. Actually, they don't all suck. WebObjects, for example, is pretty good, despite being a Java platform, which is a major reason why I can't use it. It's also not free (but then it's a lot more than a templating engine and includes EOF, which is well worth paying for).

My requirements:

• No code in HTML.
  Instead, you insert tags, which are replaced with dynamic content. HTML is for composing content, not programming.
• Components.
  This is something that WebObjects does very well. I want to be able to define nestable containers that implement widgets and whatnot.
  Components are not necessarily embedded in code. They can live in independent files that can be managed entirely apart from code. They may be composed entirely in HTML, or implemented entirely in code, or a combination thereof.
  WebObjects does this by using three files: HTML, bindings, and code. I put the bindings in the HTML, so I use two files: HTML and code.
• Stream-based.
  Some toolkits (WebObjects included) render a page in memory, then spit it out to the server all at once. That model means that a page doesn't start to render in the user's browser until after all of the page has been rendered to HTML on the server, which may take a while. It is sometimes possible to send a reasonable amount of data to the user before blocking on an expensive operation (eg. a database query), and it should be possible to send data as soon as it becomes available.
• Python.
  An awful lot of web tools are built for Java. Unfortunately, Java sucks for many reasons, not the least of which is that Java is an island, and doesn't play well with any other language/environment.
  I like Python, so I wrote it in Python, which is easily bridged to Objective-C, which means I can get to the entire Cocoa stack in Mac OS X. (Yeah, that's bridged to Java also, but not as well, and Java still sucks.) Not that AppKit is useful to a typical HTML application, but Core Data (in Tiger) sure might be.
• Only one special tag.
  The <component> tag is the only tag that is special to the templating system.

Anyway, a first draft is checked into my Subversion tree at http://svn.red-bean.com/wsanchez/trunk/Spiffy/. Docs are sparse, but there is an example set of templates there, which I use to test the code. Spiffy doesn't do form handling (use the cgi module), nor is it an app server. It's just a templating engine, at least for now.