The key argument against DTML for me is that it is a slippery slippery slope that leads to something horrible like PHP. I have a large web application that's been under development for 3 years now (in Zope) and it's full of crufty nasty DTML. Making the DTML go away is a key thing that we are now working on.

My experience may help clarify the issue for some people. I've recently moved over to the 'other side' (DTML -> ZPT). I've always felt a bit dubious about ZPT for the following reasons: - it fails to deliver fully on the promise of seamless collaboration with designers (w.r.t macro expansion in particular) - it is verbose, and quite hard to read However, the main reason ZPT advocates like it is that it forces them to code nicely. I've always felt that this was a silly argument, since there's nothing about DTML which forces you to code badly. "Just because I've seen spaghetti DTML, that doesn't mean *my* code isn't nice," I'd say to myself. However, I've been critically monitoring the code I've been writing recently, and I've realised that despite my best intentions, I still write crufty DTML. This is because I'm usually rushing to finish something against a deadline. I write some horrific DTML hack, leave a comment in the code like "XXX Yuk must fix this" and then leave it there for ever. The reality is, few of us have the luxury of enough time to write perfect code every time. Therefore I have come round to the point of view that using a tool which *forces* you to write nicer code is a bonus, even if it is (arguably) harder to scan through. Having said that, I bet people could come up with some *really* nasty ZPT if they tried. seb