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"