RevolutionaryProposals

Okay, starting to vent. I don't see any reason not to develop a cleaned-up non-backwards compatible version of DTML. Current DTML started out trying to seem easy and hiding complexity, but then added more and more features for power, and it ended up with unnecessarily complexities (far worse than Python would be) popping through its fabric in quite a few place. The result is that I still don't understand all the intricacies of DTML, and I've been at it for quite a while by now. This is not only a documentation problem; it's truly too much like "Perl for the Web".

Since a cleaned-up simplified version of DTML can be developed and used in parallel with current DTML (thanks to Zope's component architecture), I don't see why we shouldn't at least start thinking about it. Saying it'll never happen would be a shame; I'm not going to put up with DTML complexities forever, sorry. Okay, that's my rant. -- MartijnF

---------

I absolutely agree. Not only is DTML complex, several of its most obvious features are unintuitive to someone coming from the HTML world. I mean, who would think <dtml-var spam.index> and <dtml-var "spam.index"> would mean completely different things? Even if you did know the difference, is the rule "if it's in double quotes you're in python" in anyway intuitive? In most languages, anything in quotes is a string, most likely to not be interpreted. Yes, you could use name= and expr=, and I do, but then we start talking about all the other problems of DTML.

I even question if DTML should be so closely tied to the python interpreter. As much as I like python for general programming, I don't think its model of "interpret unless quoted" is very good for DTML/HTML markup-like scripting tasks (at least when the code is in tag attributes --- I'm much more comfortable with it in tag bodies). I think the php or tcl concept of "everything's a string unless otherwise noted" is more intuitive when imbedded in markup; python's still a great choice for those language bindings to call under the covers.

One complication for any object-oriented markup language is defining exactly what "spam.index" is: it is the name of an object, or a reference to it? Is it a string or not? Because python and URL conventions differ on the definition of ".", there will always be an ambiguity (at least on the user's point of view) as to what "spam.index" means. Using "/" as an object path separator is a possible solution, but as has been noted by Jim and others, different people have different ideas about what it should mean.

I don't mean to whale on the authors of Zope or DTML. It's easy to see how DTML evolved to where it is. But I think it's time to take the lessons of DTML1 and build a parallel DTML2 that is clean and useful and intuitive. Hopefully, all the big language problems can be solved at once without breaking anyone's existing code. --halazar

von Jeffrey

Until the expr syntax came along, DTML was (and still is) very powerful. The name lookup alone is a great feature in that it doesn't matter if it's an attribute or a method (although in my new thinking, all accessible properties should only be exposed via methods. but that's a different branch). My revolutionary proposal? STRICT MODE! I much much much prefer to see and use <dtml-var name="getShorty"> and <dtml-if expr="dog==hunting"> now. I'm at the point now where I can read low level C code easier than I can read a lot of the DTML/DTML Scripting that I've seen, and I've been using DTML since the pre-principia days (when, with Bobo, DTML was a great ally. but you didn't have the problems that through-the-web opened up).

[Caseman]?

I think that a better separation needs to be made symbolically between HTML tags and DTML commands. As has been said elsewhere, DTML is a misnomer because it is not a markup language at all, it is a scripting language. I look at it this way: On the one hand you can create Python methods which are Python code (Duh), any HTML is merely a dumb string between quotes somewhere. DTML on the other hand has the Python code quoted so to speak. They both end up fairly hard to read once you reach a certain stage of complexity. DTML is also needlessly verbose IMHO. I propose a middle of the road solution that allows the scripting and HTML to coexist more readably. My Structured Zope Scripting proposal.