[Zope] DTML vs ZTP

[Terry Hancock]

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