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 limited.
* 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 better.
* 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 annoying too)
* 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 DTML. Let me point out the idea behind python: the top part of the 'man page' for python says, 1st line in the DESCRIPTION section: <quote> DESCRIPTION Python is an interpreted, interactive, object-oriented programming language that combines remarkable power with very clear syntax. </quote>
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 / [EMAIL PROTECTED] / http://blog.ianbicking.org
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Webware-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
