FrontPage ZopeTemplateLanguage / backlinks

ZopeTemplateLanguage Proposal

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

Contact

Chris Withers (chrisw@nipltd.com) also ChrisW ;-)

Problem

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 the code.

Specific problems include:

• Obscure syntax to work around common problems, the most famous being:

  <dtml-var "my_method(_.None, _, myparams)">

  also:

  <dtml-var "PARENTS[-1].folder.object.method(Some, params)">

• Long-winded syntax to carry out simple tasks, for example:

  <dtml-call "REQUEST.set(myvar,1)"> to set a variable.

  <dtml-with "object.manage_addProduct'MyProduct'^x">
  <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.

  • Confusion between expressions and names for named parameters.

Proposed Solution

This proposal relates to, and maybe by covered by, several other proposals:

• DTMLExpressionSyntax

• NamespacePassingRevisited

• GenericMethodInterface

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 ;-)

Risks

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.

Scope

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.

Deliverables

• A specification for a hypothetical "perfect" Zope Template Language.

• examples written in this language

At this point, a seperate project would be needed to either alter DTML to fit the spec or to implement the language.