[Zope-dev] References to hypertext templating languages

Ken Manheimer klm@zope.com
Thu, 16 May 2002 18:03:05 -0400 (EDT)


Don, it sounds like HyperTIES Markup Language addresses some similar
purposes in similar ways to Zope Page Templates.  There are also some
significant differences, which may interest you.  ZPT has some
distinctive features particularly aimed to promote ease of collaboration 
between web designers and programmers (or between those two sides of a 
developer, working with themselves.-)

Chief among those features is use of tag attributes for computation hookup
- variable access, conditionals, loops, method invocation, etc. By using
tags on standard XHTML, the results of adapting a page for hookup with the
rest of the application retains the structure and parsability that the
designers originally created.  The original structure is preserved, and
conversely, typical design tools preserve foreign tags (generally,
ignoring them, maybe even colorizing them distinctively), so we avoid
disruption in both directions.

(It's a pleasure to be able, as a programmer, to take designer's markup
and add the right tags, capitalizing on their designs without disrupting
them - and to be able to trade the result back and forth, evolving it
without having to retrofit changes again and again.  I've done this, on 
customer projects, and was **not** able to do so when we were using DTML.)

The issue about "order of tags" seems to be a misunderstanding - the
order being described was order of _execution_ - precedence of the
tags, to serve the programmers purpose.  For more information, see the
TAL (Template Attribute Language) specification:

  http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4

The discussion about "procedural versus templating language" may be based
on misuse of terms.  I think the issue is block-structured versus
page/layout markup.

It's common to see templating languages that hookup to underlying
programming logic by interspersing block-structured code with page-layout
directives.  Both in principle and as someone who has used a few of these
systems, i think they're fatally flawed for anything more than simple
layouts. I know that we *can* accomplish elaborate layouts with such
systems - god knows, i've done so.  I'm just saying they're unnecessarily
hard to unravel, change, and debug - because of an "impedence mismatch",
where the structuring of one syntax does not obey the structuring of the
other.

(Recently i posted something equating this intermixing of structural
boundaries with undisciplined use of goto in a high-level language - both
defeat many of the benefits of clean structuring.  This sort of thing is
especially galling, eg in DTML, to those of us that came to Zope with an
appreciation of Python for its tendency to exceptionally readable,
comprehensible code.  I also like lisp, particularly for its elementary
syntax and susceptibility to programmatic manipulation, but have been won
over beyond lisp by python's economies...)

Using XML for your language, as i gather HyperTIES does, avoids the
structural disruptions, since XML is strict and consistent with HTML.  By
sticking with HTML, however, we also leverage pervasive expertise - at
least being able to use the efforts of the numerous folk familiar with
HTML, and in some cases enabling them to do various levels of their own
programming hookup with ZPT.

There may seem to be ways we restrict our templating language by using
HTML, and in some ways, that's right.  In fact, that's another, very
important benefit, here.

The Zope environment provides numerous ways to express elaborate
business logic, ways that are much easier to read and process than any
markup-oriented language can provide.  (These ways include things like
web-editable python scripts, standalone "external" methods, and
product methods, as well as SQL methods and so forth.)  Markup is best
used for presentation - the only procedural logic we want in our
templates should be presentation specific, or calls out to tap the
results of the application business logic, underneath.

Conversely, the business logic should not have to produce presentation -
just provide the fodder for it.

ZPT sits in this balance, very nicely i think.

I haven't been following the conversation very carefully, so don't
know whether or not you've gotten acquainted with ZPT - the canonical
place is:

  http://dev.zope.org/Wikis/DevSite/Projects/ZPT

Considering the approach of HyperTIES, you may find a lot to like
there.

-- 
Ken Manheimer
klm@zope.com