Sorry to reply to a fairly cold topic, but I just read it ... On Tuesday 07 December 2004 08:24 am, Ian Nunn wrote:
I'm a third of the way through the Zope Book and understand the difference as it is written. As you can appreciate, in learning a new technology, what is missing is the experience that would guide your focus. What I would like is an idea of how real world developers use these in the following senses. Do you use one exclusively (in conjunction with Python)? Do you use primarily one or the other? Do you use both roughly equally? Are there classes of applications where you have found one is preferred? Your advice would be welcome.
I recently started trying out ZPT, which will probably shock its author, as I have railed against it on this list in the past. ;-) So far, I'm not finding ZPT too bad, actually. Some of my original complaints do stand, though, and I have found a few new gripes: 1) Doing the same thing in ZPT as in DTML invariably takes more typing. I have yet to find an example where ZPT is more concise. I find it extremely annoying, for example that I can't simply substitute a variable into an otherwise static attribute -- instead, I have to re-write the whole attribute, which is Just Stupid (TM). So it's not just a question of "less magic", there's actually some significant unnecessary duplication that goes on as a result of using ZPT. 2) Putting code into ATTRIBUTES is UGLY. BTW, did you ever notice that the following won't get interpreted: <script> <span tal:replace="container/myjavascript.js" /> </script> Took me awhile to figure out why. This was the part I really objected to in switching. Having to go from "html in code" to "code in html" makes you have to rethink your whole concept, backwards. 3)For no obvious reason, ZPT replaces "context" with "here". This makes no more or less sense, but is needlessly inconsistent with other Zope code (namely Python scripts). True, DTML doesn't know about either one, but at least it didn't *conflict* with the Python scripts. 4)The insistence on proper XML nesting can be annoying. For example, I frequently used to use a simple expedient for rendering tables with an array of data set to a given width: <table> <tr> <dtml-in mydatalist prefix="sq"> <td>&dtml-title_or_id;</td> <dtml-if expr="sq_index % 4 = 4"> </tr><tr> </dtml-if> </dtml-in> </tr> </table> which you basically can't do in ZPT. IMHO, the number of columns you choose to print a collection of data at is PRESENTATION, not LOGIC, so the fact that ZPT makes me put that decision into a Python script (my ZPT solution requires making 'mydatalist' return a sequence of sequences for each row, instead of just a plain list) seems extremely ironic, given the wild claims made about it. OTOH, there are some bright spots, which ultimately made me want to switch at least some of my code: 1) ZPT has non-Zope implementations. So it no longer has the "proprietary language" stigma of only being useful within Zope (yes I know DTML isn't really proprietary, but there's no independent implementation, to my knowledge, which is the point). 2)More people are learning ZPT from the start, so it's likely that if I want other people to help maintain the code, ZPT is going to be more practical. 3)Unlike DTML, ZPT allows you to define macros and re-use them inside the same file. There's really no reason DTML couldn't be upgraded to do this, but AFAIK, it hasn't been and probably won't be. This allows you to have a file that reads like a module file with functions defined in a bottom-up design process. This tends to eliminate the "huge pile of DTML files" that I currently have in my product code, replacing whole directories of tiny DTML files with larger ZPT files. Obviously you can go too far, but it can aid readability or at least navigability of the source code. 4)ZPT's name spaces (Not the XML namespace notation, but the actual variable look-up process) is more sensible than DTML (I agree with the "too much magic" criticism of DTML). This is TALES specifically, of course. For some reason, proponents of ZPT seem to think of this as the primary difference between the two, though I find it virtually negligible as a user -- the glaring difference in syntax is what is so off-putting, not the TALES namespace design., which *is* better -- no argument there. 5)I never thought much of the point that ZPT code is legal HTML for rendering, since I never intended to use an "HTML editor" for developing pages. But I did find it very useful in fact --- even when you write HTML in gVim, you want to render it in a browser to check it, and ZPT makes this work. 6)Using Python more for presentation code is actually a fairly good thing for me, as I'm very familiar with it. However, claims like "ZPT supports separation of presentation and logic while DTML doesn't" are PURE FUD. Don't buy it. DTML and ZPT are about equally good or bad at this. The real difference is a matter of coding style, not language. The most significant difference, is that DTML is "code first, template second" (i.e. the HTML is embedded in the code), while ZPT is "template first, code second" (i.e. the code is hidden in the HTML). DTML makes it easier to think of pages as being composed of small replaceable elements that can be assembled in arbitrary ways, so that the structure of the page *is* the content, while ZPT makes it easier to make chrome-heavy pages that you stick a little content into. However, despite this bias, it's not that hard to use either language to do either of these approaches. The METAL tags in ZPT are the ones you'll get the heavy use from if you like the "constructed" approach to a page rather than the "inserted" approach. And although the DTML to ZPT pages don't seem to mention it, you darned sure CAN use your DTML standard_html_header and standard_html_footer in a ZPT. Just do this: <span tal:replace="structure here/standard_html_header" /> and <span tal:replace="structure here/standard_html_footer" /> Of course this screws ZPT's precious ability to be properly interpreted in Dreamweaver (TM), but did you *really* care? More to the point, it lets you migrate slowly, as you can keep using your basic DTML design, with some ZPT's added. Do not forget the "structure" part, though -- that'll really frustrate you, as ZPT's default behavior is to HTML QUOTE. On balance, I find that ZPT is not so bad, and I am actually finding it worth the transition for much of my presentation code. I have not got to the point of examining my SQL calls, but they will probably remain DTML for the present (as I eventually want to migrate to Zope 3, I think I will have to be handling those differently as well -- I think Z3 makes you use something more like Python's standard DB API to interact with SQL engines -- but that's a problem for later). Cheers, Terry -- -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com