[Zope] DTML Syntax contd. + rant

[Stuart 'Zen' Bishop]

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