[Zope-dev] Using DTML is too difficult

[Andrew M. Kuchling]

Rik Hoekstra writes:
>(quoting Martijn)
>> 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.

Amusingly, Greg Ward, the resident Perl expert here, made the same
comparison after working with Zope for a while, and I can see his
point.  There are lots of default behaviours that usually do the Right
Thing, but when they aren't what you want, it can be hard to figure
out what's going on.  When things do go wrong, you don't have a lot of
diagnostic tools to pin down the problem; what's my namespace stack
look like?  Developing Zope stuff, I find I'm often inserting "return
repr(someobject)" into ExternalMethods to check on variable values; a
Web-based namespace + variable browser would be helpful.

DTML is beautiful when the problem maps nicely to existing DTML
constructs; however, once you start wanting to add lots of complicated
behaviour, you have to start writing Python code, and for writing
Python code, the Zope development environment has drawbacks, ably
listed by Rik:

>- writing products in python is complicated and mostly not worth it
>- writing python base classes for ZClasses is easier, but using them in the
>Z framework requires  quite a bit of understanding of ZClasses and the Zope
>framework in general
>- External methods are much easier, but they have their own disadvantages:
>     (1) it is less than obvious how they interact with the dtml
>methods/namespace they are called from
>     (2) they are not easily transported to another machine, because you
>need physical access to the
>         filesystem for that (I understand that that's the only way)

Security is, I think, part of the reason that DTML is a sandbox; if
someone gets your Zope management password, they can edit your pages
and run SQL commands in your database, but they can't do 'rm -rf /',
because they can't install ExternalMethods or classes without access
to the machine's filesystem, and there's no way to do such things from
DTML.  

I'm not sure what the fix is: a hypothetical ngDTML, which is
different from DTML and would provide more of Python's power?  Better
debugging tools and support with Zope?  Better support for developing
and debugging your code outside of the Zope server?  I think the
solution lies more with the latter two options; ngDTML would be
difficult to design, and it might be easy to repeat the same mistakes.

Let me hasten to add that this isn't Zope-bashing.  We also use Java
servlets using Apache's mod_jserv.  Servlets have all of the same
problems, with some additional ones:

	1) Instead of a fast interpreter, you get to run the slow
"javac" every time you make a change.

	2) No standard solution for HTML templating.  Sun has JSP, but
they mix your Java code with the HTML, which is a design
mistake that we're trying to get away from!

	3) Instead of writing L = ['material', 'substrate'] in Python,
you get to write:

import java.lang.Vector;
...
    Vector L = new Vector();
    L.addElement( "material" );
    L.addElement( "substrate" );

(Why people think a systems language like Java is appropriate for Web
stuff is beyond me.)

        4) All those useful #in and #tree tags?  Not there -- start
writing your own!

	5) SQL queries?  Start writing JDBC code...

	try {
	    ResultSet rs = doSelect(query);
	    if (rs.next())
		return new Integer(rs.getInt(1));
	}
	catch (SQLException e) {
	    throw new DatabaseCriticalException("Error accessing ResultSet in SequenceWrapper.currentVersion().\nQuery: " + qry + "\nException: " + e.getMessage());
	}

<!--#in myQuery--> is much easier, obviously.

Let me be clear; we're finding that Zope blows other tools out of the
water.  (If I were to get a management edict that "Zope is out; tool X
is in", I'd start tidying up my CV.  Such an edict is unlikely,
thankfully.)  There's just still lots of room for improvement, and we
all really care about that.  :)

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
    "I must confess, I have always wondered what lay beyond life, my dear."
    "Yeah, everybody wonders. And sooner or later everybody gets to find out."
    -- Norton I and Death, in SANDMAN #31: "Three Septembers and a January"