[ANN] HTMLTemplate 1.0.0

[has]

Peter Maas <peter.maas at mplusr.de> wrote in message news:<c9k8gt$sqh$1 at swifty.westend.com>...
> has schrieb:
> > Announcing the final v1 release of HTMLTemplate; best damn HTML
> > templating system evar, or yer money back. Enjoy! :)
> 
> Good work BUT
> there are some other Python templating frameworks around, e.g.
[...]
> Did you find these alternatives unsatisfactory? 

Yep. Some reasons:

1. Most Python templating systems are either code-in-markup or
markup-in-code designs, which don't provide clean separation between
markup and code. Code-in-markup systems at best separate only business
logic; presentation logic remains firmly embedded in markup.
Markup-in-code systems provide no separation whatsoever (the only
example I've liked the look of is Lisp-based
<http://www.lisp-p.org/lh/lh.html>, but I'm not a Lisp programmer).

HTMLTemplate uses a simple DOM-derived approach that provides complete
View-Controller separation [according to Apple's definition of MVC,
not Smalltalk's]. An HTML template is converted into a simple object
model (the View layer) that can be manipulated from your Python script
(the Controller layer). BTW, how the user defines the Model layer is
left completely up to them (in simple scripts I just squish any
business logic into the controller code, in more complex systems I
keep 'em separate). Not my place to dictate that to them; smells of
fascism.


2. A good proportion of other templating systems invent their own
custom templating languages rather than leverage an existing one (e.g.
Python). See Greenspun's Tenth Rule for why this is generally a bad
idea. (I learned this lesson the hard way from writing my second
templating system, which tried to copy the PHP/ASP custom
HTML-embedded language approach. Took me two months to write, two
weeks to debug, and less than a week from completion to burial beneath
the patio. Just as well really; the v2 TO DO list was growing almost
as long as the v1 codebase.:)


3. Most templating systems are either "powerful but complex", "simple
but underpowered" (i.e. crippled and inadequate) or, in worst cases,
"complex AND underpowered". "Flexible" costs extra in any case.  The
best solution would be one that's both powerful and flexible while
also remaining simple in implementation and use: basic Unix
philosophy.

After designing/writing two complex, underpowered and inflexible
templating systems, my third finally met the "powerful" requirement.
Unfortunately, it proved just as complex and clumsy in practice;
features added to make it more flexible and easy to use paradoxically
having the opposite effect. I finally cracked that problem on number
four (the original HTMLTemplate, of which the Python version is a
partially reworked port) simply by throwing out every last bit of
non-essential, non-core functionality I could find and working on what
was left to get it just right.


> If somebody wants to use a Python templating framework 
> why should he prefer HTMLTemplate?

Think of the four years, thousands of lines of code, and dozens of
features that have gone into its creation. Then do a line count of the
API and codebase against the rest of the pack. ;)

HTH