(Originally to zope, but should have been to zope-dev) On Wed, 10 Nov 1999, Martijn Faassen wrote:
If I ever get the time I'd be tempted to work on a DTML 'cleanup' project. DTML is currently *far* too much like Perl and not enough like Python. *some* easy things are very easy, but as a consequence some other easy things become far too hard, or at least look far too complicated. You can spell the same thing in too many ways. The community encourages and praises additions for convenience (like the 'default' option, or the new extended &entity; syntax) but as a result DTML loses its conceptual integrity. It becomes too big and not easy to understand.
I understand the argument that DTML shouldn't be used for complicated purposes, and that you should use Python. This is fine and good, but in practice people *do* use DTML for complicated purposes. ZClasses in fact encourage this.
DTML should be more like Python. Luckily the Zope framework does allow new objects to be plugged in using something else than DTML, so not all hope is lost. :)
Feedback on this rant would be appreciated.
I'm with you 100%. It makes me feel like I'm programming a reverse polish calculator sometimes :-) A low-level user (one not confidant in writing external methods) shouldn't have use magic constructs like <dtml-var "_['sequence-item'].title_or_id()"> dtml-in is the main culprit - a synonyms for the magic variables that conform to python naming standards need to be created and the old ones depricated. Is there any reason why I should fix this and submit the patch for 2.1? (or 2.2?) Possibly REQUEST needs to be available through aquisition rather than having to be passed to everything. How about <dtml-python> print "<p>" print html_quote('''The <dtml-ver2> tag is executed, the code contained between the tags simply writing to standard out to produce the rendered version.''') print '''<p>This could be done either through stealing from the existing PythonMethods code if it can be proven to be as secure as DTML''' if untrusted_pythonmethods: print '''<p>An alternative approach would be to run the code using r_eval. A BastionClass wrapper would be used to protect access to objects - the code would initially only have access to the bastionised _ object, and all the getattr and getitem methods would aquire objects as normal, but return another bastion wrapper instead of the real object. <p>Of course, this may be how PythonMethods already works for all I know....''' print ''' <p>Currently, calling python functions needs to be done through the current namespace, with calls like _.string.split(...). This seems arse over tit - wouldn't it conceptually be better to use a prefix for aquisition? _.standard_html_header() for example - this makes it much clearer IMHO what is going on and easier to grasp. It might be too late in the day to change this however.''' </dtml-python> Is existing DTML good enough for 'simple' scripting? I think the current confusion threshold occurs when people start needing to pass parameters to methods (and the whole quoted and unquoted thing kicks in, and suddenly they have to understand about the _ namespace, and the magic variables to pass a DTML method to make it work). - Zen, who is still a bit grumpy today. ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen