>>Personally I've grown to hate DTML in the Zope context; I'd
>>never actually realized you could use them outside of Zope,
>>but then I've never had any desire. And though DTML is
>>faster than ZPT, it's likely to be slower than Cheetah or PSP
>>(which are compiled to Python, where DTML is interpreted).d
> OBJECTION !!!
> 1. Your remark "I've grown to hate" surprises me, really!, I've 'trained'
> many developers in our, again far from ideal, python/Zope(=DT/PCGI)
> methodology, they all had their comments but the feedback on
> DocumentTemplate in terms of syntax, ease-of-use, feature-richness (!!! Main
> plus plus for DT !!!) has been very positive , really ! I'ld say, and don't
> take this personally, please, that your negative attitude is either based on
> incorrect application of the python module (yielding unneccesary problems)
> or on something else (bias?) , really, our experience as well as the
> feedback received from people introduced to DocumentTemplate has been very
> positive .
My hate for DTML is really from a few different perspectives -- and Zope
and Acquisition have a lot to do with it. Outside of Zope I might not
hate it as much. *But*, I am not at all alone in hating DTML, which is
part of why it is deprecated.
But, regardless of the rest of Zope, here's the parts I dislike about it:
* It uses a tag-like syntax, which is unnecessary and annoying, since it
is completely orthogonal to HTML tags. Things like this annoy me
terribly: <a href="item?id=<dtml-var "some_object.id" url_quote>">.
There's just no upside to that. The entity syntax helps, but is too
* It produces exceptionally poor tracebacks. Painfully horribly bad
tracebacks. I think they may have fixed this with Zope 2.7, but I
haven't looked at it. If they have, you have to use the Zope exception
reporter to get that information (not too big a deal, it's a fine
exception reporter). Cheetah and PSP aren't great, but they are usually
* It generally uses standard_html_footer and standard_html_header, that
is, styles are applied with headers and footers. This is awkward in
many cases; e.g., where you have to specialize the header. To a degree
this is always true, because the title is in the header, and so DTML
encourages static titles (title_or_id) which don't convey as much
information as they could.
* It magically folds values into the namespace, when using dtml-in and
dtml-with. I hate that. Namespaces are good. Magically putting values
in the namespace is really bad. (And dtml-in's sequence-item is
* dtml-let propagates values to included templates. Ditto many other
constructs. The result is that you can't understand any template in
isolation. And with the magically extended namespace, you can't even
understand the templates as a whole -- you have to understand the entire
system to figure out where a value came from.
* Yet no good way to define values that aren't scoped in a dtml-let, and
no good way to define values based on conditionals. You have to use
REQUEST.set() and other kludges.
* Annoying access to builtins through _ (e.g., _.int()).
And probably a bunch of other things. Really, I can't stand it, and
I've worked with it quite a bit. The namespace thing is the biggest for
me, though; it's the reason I actively steer people away from DTML. The
others you confront at the beginning, and you can decide if they bother
you; but the namespaces won't be so big a problem until a year later
when someone else is maintaining it. Someone like me :(
> 2. You say "DTML is interpreted" and that that this is a disadvantage of
> Let me point out the idea behind python: the top part of the 'man page' for
> python says, 1st line in the DESCRIPTION section:
> Python is an interpreted, interactive, object-oriented programming language
> that combines remarkable power with very clear syntax.
I brought this up purely in reference to performance. There are
advantages to interpreted templates. I mostly use ZPT now, and it's
interpreted (and considerably slower than DTML, maybe 2x slower?); as
long as it's fast enough, it's OK. I actually brought this up because I
thought you were referring to the speed of ZPT (which I think, in some
cases, can border on problematically slow).
> So, if python is interpreted, how much sense does it make to 'take as an
> advantage' to compile language X to python, and is, more general,
> compilation vs. Interpretation an issue at all given today's language- and
> computational technology ?
> I'ld say: substitute "DocumentTemplate" in above DESCRIPTION and I fully
> support the statement .
> Our experience with DocumentTemplate is, as I said before, that it performs
> *fast* ... One of the reasons is, I suspect without knowing the exact inner
> workings, that it loads some template in RAM and 'parameter
> instantiation/substitution' is a memory-only task without file i/o .
If it's fast enough, that's fine. Speed isn't at the top of the
features I look for. I'm just noting that Cheetah and PSP should be faster.
Ian Bicking / ianb@... / http://blog.ianbicking.org