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... :)