[Zope] - DTML/type-converter extension protocols (was Re: [Zope] - Yet another stupid question: image folders) another stupid question: image folders)

[Phillip J. Eby]

At 05:22 PM 12/7/98 -0500, Andrew Zeldis wrote:
>This is sounding to me like 1) a cool feature; and b) a new tag.
>
>Howbout a general "html" or "link" or "href" tag:
>
><!--#link name="logo.gif" fmt="img"-->
>
>or some such.  Then the magical elveZ would say, "image, better find out
>how big it is, blah blah"...
>
>I know new tags are the wrong (perl) way to go, but if they are general
>enough...  Thus, better to go with #link or #href rather than #img...
>Keep it general.

I disagree with this rather strongly, on two grounds.  First, DTML is not
just for generating HTML - it's also used for generating SQL, plain text,
e-mail, and in ASDF it will soon be used to generate Perl and shell
scripts(!).  I would much rather it stayed a (relatively) lightweight
general text processing language and did not include ANY HTML-specificness.
 AFAIK, it is currently language-neutral other than providing HTML, URL,
and SQL quoting mechanisms.

Second, it is a very small language, and I really like it that way.  In
evangelizing it, I tell people, look, it only really has four keywords:
var, if, in, and unless.  (This was before 'call', 'with', and 'raise' were
added, I guess I should update my spiel.  :) )  I can shame any programmer
into learning it simply by saying, "Hey, you mean to tell me you can't
learn a language with only four primitives?"  :)  I would be happiest if
there were never more than seven primitives in DTML - anyone can learn
seven things.

Of course, I'm probably an extremist, but I don't think that 'sendmail',
'tree', or even 'raise' should be built in as tags.  Make 'em methods like
everything else and use 'call' or 'var' to insert them.  My nightmare is
that now that there's an easy protocol and examples for creating new tags,
there will arise 500 different dialects of DTML, all mutually
incompatible...  And when you try to install a product made with one
definition of say, 'sendmail', it will break the installation of another
product made with a different definition, because the DocumentTemplate
libraries are global.  Shades of MS-Windows shared DLL's!

On the other hand, there is something that would probably fix that
problem...  If DocumentTemplate tried to look up an attribute in itself
called (say) 'DTML_Tag_foo' where foo was the name of a tag it didn't
recognize, then subclasses of DocumentTemplate could extend the language
without altering a global resource.  Perhaps I should submit a patch for
that...  :)