[Zope-dev] ZPT is young

[Jeffrey P Shell]

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/