Why choose Mako over Cheetah?
James Robinson
results. We're a shop with a large investment in Cheetah [ been
called 'old-school' at least once this week on this very issue ],
rendering all sorts of types text with it, but have been hearing good
things about Mako, and are curious as to why one would choose Mako
over Cheetah. How do they really differ?
From what I've read on the Mako docs, seems that there's just one
single data dict in Mako held in the Context, as opposed to Cheetah's
list of dicts [ the searchlist ]. Cheetah uses a C extension to do $
lookups in this searchlist, whereas it appears that Mako needs no
such extension.
What would be compelling reasons to start with Mako over Cheetah, and
what would be compelling reasons [ from Mako's perspective ] why one
might change from one to the other. I'm not meaning to invite
directed evangelism, in that we're not really looking to switch --
just more academic curiosity than anything else.
----
James Robinson
Socialserve.com
Jose Galvez
lack of a c module makes installation on windows simpler. Also with
pylons I don't have to add or change anything to make it work. I used
Cheetah for a few years and switched over to mako because mainly it was
an easy stitch and I like the syntax. But the reality is that there is
no compelling reason to switch, if you have a large cheetah base and
cheetah works for I see no need to switch.
Jose
Mike Orr
Well, Cheetah's #2 developer (me) is now using Mako, so I guess that's
an endorsement. My reason for switching was, there were several
features in Kid/Geshi/Mako that I wanted in Cheetah but would be
difficult to implement given Cheetah's code structure and having to
make an already long manual even longer. Chief among those were
better Unicode support, more use of standard Python expressions (fewer
$ and #), transparent template caching, a search path for
inherited/included templates, more convenient overrideable HTML
escaping, etc. Plus Mako's users' manual is phenomenal: it's concise
yet detailed, answers all my questions, and the developer/user
community is extremely responsive to any question/bug report on the
list. If there was an award for the best Python project documentation,
I'd give it to Mike Bayer for Mako.
Cheetah and Mako are conceptually similar but grew up in very
different environments. When Cheetah was a drawing on Tavis Rudd's
napkin in 2000, there were no comprehensive template engines for
Python (except Zope's XML-based thingy). Tavis demonstrated that
compiling a template to Python source code was significantly faster
than regular-expression substitution. Cheetah borrowed a lot from
Velocity, a Java template engine, and strived to allow graphic
designers to put display logic in templates without having to learn
Python. But users wanted more and more Python features so we kept
adding them until they were all there. The reason being, the
developers can't foresee every situation where a Python construct may
legitimately be needed, so it's better not to artificially prevent
users from doing things.
The idea behind the searchlist is that if you already have your values
as attributes in an object or keys in a dict, you can just put that
object on the searchlist rather than copying every value in a loop.
But few people ever did that much, and now with Buffet the API is a
least common denominator among template engines, which means a single
dict.
To me the biggest innovation after Cheetah was Kid, which showed that
ordinary Python expressions inside ${...} are are very elegant,
ordinary Python assignment statements become possible with a single
dict, smart HTML escaping is important, multiple output formats and
guaranteed well-formedness are desireable. Mako borrowed several of
these from Kid (though Myghty may have had them too?). Some things
like multiple output formats and smart HTML escaping are just not
possible with a text-based template engine, so there was another round
of whether text-based or XML-based engines were better, but the speed
issue is definitely in favor of text, and it turns out that you can't
guarantee output well-formedness even with an XML-based engine if you
have to insert data with preformatted markup. Mako came up with an
HTML escaping scheme that while manual is convenient.
(For HTML escaping, set a default filter, and if you need to output a
value with markup at a particular place, use the 'n' filter to
override the default filter.
N.B. Mike Bayer: 'n' is still not documented in the Filtering chapter.)
So Mako's main advantage is that it came later than the other template
engines, so MikeB was able to see what worked and didn't work in the
earlier engines, and what features would be important in a Buffet
world that the earlier template developers had not foreseen.
However, Cheetah still has a huge userbase and its download numbers
keep increasing, so somebody's using it. The code has been stable in
production environments for years, and most feature additions have
been in response to specific user needs, not willy-nilly bloat. Tavis
is still using Cheetah and supporting it; many of the changes were
those he needed for large applications with user-edited content. The
only reason 2.0 final hasn't been released is nobody has time to
update the manual. I wrote most of the existing manual so I know it
would take a good month of full-time work to bring it up to speed.
But what's in the 1.0 manual works 98% of the time; you just don't get
the new features unless you read through the CHANGES file.
--
Mike Orr <slugg...@gmail.com>
Manlio Perillo
> [...]
>
> Some things
> like multiple output formats and smart HTML escaping are just not
> possible with a text-based template engine, so there was another round
> of whether text-based or XML-based engines were better, but the speed
> issue is definitely in favor of text, and it turns out that you can't
> guarantee output well-formedness even with an XML-based engine if you
> have to insert data with preformatted markup.
This is not true with "good" XML based templating engine, like Nevow.
> [...]
Regards Manlio Perillo
Michael Bayer
ambiguous tags/functionalities. when you look inside the source of a
generated cheetah template, theres a "transaction" variable going on
(a "transaction" in a template ??!). Most importantly, Cheetah
provides no straightforward way to use the same Template object in a
multithreaded environment - you compile the template *with* its
current set of arguments, therefore its at best a single-threaded
template, and it seems people actually work around this by creating
thread local copies of templates. not to mention the docs always
took 10 minutes to load. native dependencies are always a little
icky too.
It just seemed like a very overbuilt and overcomplex product that had
fallen way behind the times....and as the author of Myghty, I was
looking to build something super slick and small (and ridiculously
efficient), pure python, drop dead simple, from both the outside and
inside (source code is easy to read, generated templates easy to
read, etc). Very unicode-centric (cheetah is not unicode aware at
all AFAIK). After a month of development, Mako was more or less
"done" and we've had very little to add/fix to it since its first
month or two.
Mike Orr
>
> I never liked cheetah because it seems enormous with many redundant/
> ambiguous tags/functionalities. when you look inside the source of a
> generated cheetah template, theres a "transaction" variable going on
> (a "transaction" in a template ??!).
That allows a template to be used as a Webware servlet, something akin
to a controller in modern frameworks. Cheetah was originally
developed for Webware back when it was the only non-Zope web
framework. When not called from Webware, Cheetah provides a dummy
compatibility object. Writing to a Cheetah transaction is the same
concept as writing to a Mako context object.
--
Mike Orr <slugg...@gmail.com>