On 5/8/02 6:54 AM, "Adrian Hungate" <adrian@haqa.co.uk> wrote:
Seriously though, what, exactly, was so broken about DTML that fixing it became so vital?
There are many things. DTML started its life as basically a reporting focused template language to be used in conjunction with Bobo objects. There were no expr's in those days, they weren't really needed - editing templates through the web was an uncommon thing, and where it was common, you were editing very focused templates that belonged to a very focused application (like tweaking how a report of engine parts would be displayed). It was not intended to be a programming language - just a more advanced version of server side includes. But, as Principia and then Zope grew, it was the main way of gluing everything together. Thus, more and more programming oriented constructs found their way in to DTML along side the reporting oriented constructs. And they grew kindof haphazardly. Plus, people's desires for shortcuts have made for some delightful obfuscations. The fact that <dtml-var foo> and <dtml-var "foo"> can produce wildly different results stopped giving me that old "comfortable, familiar" feeling a long time ago. And the old games and debates over how <dtml-set> might work and how often "REQUEST.set()" gets used, even when its known to be bad... It's just headache. And how about the fact that you never really know how some DTML tag parameters are going to be interpreted? Some are interpreted as a literal string, some as an name lookup, some as an expression. Granted, some of these latter points could be solved by making a TALES aware revision of DTML. A big broken thing about DTML was that often, a designer would make a look for the site, and a DTML programmer would deconstruct it into multiple little DTML objects. When the design changed, reflecting that change across multiple little DTML objects could at times be excruciating. But ultimately, with the power of things like the name lookup (<dtml-var foo>), and the namespace, DTML was really easy to make into components. Sometimes that would come in as a maintenance win (just fix the right component), sometimes at a loss (major design changes meant lots of tweaking, testing, and tweaking and testing some more). On the other hand, I'm making some really nice ZPT based admin interfaces in GoLive 6 right now, coupled with Python Scripts and SQL Methods. It's some of the best looking UI work I've done in years, and it's great to be able to use the tool and switch effortlessly between Visual and Source modes, and not have the Visual mode peppered with unknown or broken looking tags (the visual editors never seemed to care much for code like: <input type="checkbox" ... <dtml-if expr="foo == bar">checked</dtml-if>> However, they're not caring too much over: <input type="checkbox" ... tal:attributes="checked python:foo == bar"> )
Given the strengths of DTML I still maintain that ZPT is no (yet?) a complete replacement, and given the comfortable, familiar syntax, I doubt that it should ever replace DTML completely, even if most pages are ZPT. I would be very supprised (Not to mention impressed) if by 2.6 ZPT can comfortably replace every aspect of DTML without having to employ Python scripts, or some arcane incantations.
It's not a complete replacement, no. DTML is still very good for SQL methods, although much of this has to do with the wonderful <dtml-sqlxxx> tags. DTML does have all that great batching/sorting/reporting stuff built in, while ZPT uses the heavily underdocumented ZTUtils module to provide default implementations of those features (another pro-ZPT note, you can implement and use your own Batcher much more easily in ZPT than in DTML). What's wrong with employing Python scripts? They're much easier to read and write than DTML, and actually go back to the old Bobo way of doing things. In Bobo, before the days of expr's, it was common to have some utility methods on a class that would return data in a form easy to use in DTML, making the DTML cleaner, and making changes into the algorithms that returned that data was easier to manage. Translating from DTML to ZPT is hard. To do this best, one really has to re-architect the presentation layer of their site, rather than trying to just replace DTML with ZPT straight across. But after working with ZPT, especially in situations where I have a blank slate, I find it to be a much better design and usage philosophy. There are still some sharp corners, and I still don't understand how to make the equivalent of the <dtml-tree> tag at all, let alone how to start customizing it.
Don't get me wrong, ZPT is likely to be a very useful supliment to the existing Zope tools, but I would no more suggest replacing Python Scripts, than DTML.
Likely to be? I say it is the most useful supplement to the existing Zope tools that there has been in a long time. ZPT and Python Scripts were raised in a day when the mistakes of the past could be learned from. If some of the techniques used in them could find their way into DTML Documents/Methods and SQL Methods, I'd be very happy indeed. For my closing statement - in my experience there are far fewer surprises in using Page Templates than in DTML. I like this. TALES opens up the possibility for future expression languages. In DTML, expression support is decided on an attribute by attribute basis and is fixed at tag development time. In Page Templates, being able to use a single "master page" metal macro is FAR better than standard_html_header and standard_html_footer. Trying to keep tags balanced between two separate files when a page design gets complex gets to be a royal pain in the ass, no matter how proficient you are with DTML (again - in my experience). And finally, ZPT is much better architected for the future than DTML is. It's a good party, why not join? I keep wanting to say a line about people not moving towards the future and staying with the familiar comfortable nature of the first editor to barely move beyond the one line nature of the teletypewriter, but I'm not going to. ;) -- Jeffrey P Shell www.cuemedia.com http://radio.weblogs.com/0106123/