Note - this document is still a work in progress. Please do
not make inline comments in the proposal - use the
ZopeTemplateLanguageDiscussion to make comments. This page will
be updated as comments are taken into account.
Last Updated: 7/8
Chris Withers (firstname.lastname@example.org) also ChrisW ;-)
DTML has grown over the years to solve problems as people encountered them.
It is now well beyond the use it was originally designed for and the strain
is showing, particularly as the DTML documentation has lacked far behind
Specific problems include:
Obscure syntax to work around common problems, the most famous being:
<dtml-var "my_method(_.None, _, myparams)">
<dtml-var "PARENTS[-1].folder.object.method(Some, params)">
Long-winded syntax to carry out simple tasks, for example:
myvar,1)"> to set a variable.
<dtml-call "manage_addMyProduct(some, param, s)">
</dtml-with> to add an object.
Heavily python oriented. Unless you know python you won't get much done.
You'll get tripped up unless you know a lot of obscure python.
Some bits of python have even been abused:
_[x] should return an object with key
x from the dictionary
not execute it first.
Keywords that aren't as related to their actions as they could be.
For example, let, var, with and so on.
This proposal relates to, and maybe by covered by, several other proposals:
I expect it will evolve as these become more finalised...
The project for this proposal is to come up with a new Zope Templating Language specification to
explore how we could do things if we had the opportunity to start from scratch.
This specification could then either be used to improve DTML or could be actually implemented.
If used to improve DTML, new syntax could be gradually phased in while old syntax is phased out.
In essence, only breaking small bits of code at a time ;-)
If used to replace DTML, the two could exist in parallel until such time as DTML was deemed
no longer necessary.
Please see the ZTLSpecification page for the overall aims of the language and its hypothetical
specification. Comments are welcome but may be
incorporated as changes or removed. If you want your comments to stick around, put them
in ZopeTemplateLanguageDiscussion ;-)
The risks would depend on what the decided outcome is.
If it is decided to improve DTML, then compatability would be the main risk. How to introduce
changes to the syntax wihout breaking old code that users were not expecting to be broken.
These are the same risks faced to a lesser extent by the DTMLExpressionSyntax.
If it is decided to replace DTML, it will be difficult deciding whether to fix DTML bugs or
just to say "use ZTL". There's also the matter of converting all the DTML in Zope and Legacy
Products over to ZTL. That said, there's no reason why DTML can't stay around long enough
for this not to be painful.
This proposal only addresses the actual template language. It doesn't tackle the problem of
interfaces that people are likely to use in methods being non-standard and often confusing.
At this point, a seperate project would be needed to either alter DTML to fit the spec or
to implement the language.