Jules Allen wrote:
I do understand your previous statement about separation of 'reporting' and 'logic' and I think it's a good one. However, from a user perspective, I only know how to clumsily use a hammer (DTML) right now so everything looks like a nail to me. Separation of Church and State is a lofty goal and both bleed into each other's turf.
I think that part of the problem is that DTML needs to be a document building language that can create HTML, XML, or what have you, so trying to recreate DTML in a variant of XML seems problematic. There is currently no standard 'eXtensible Server Side Parsed Markup Language'(XSSPML) ;^) , and I think trying to shoehorn vanilla XML into this role would be a mistake. XHTML seems somewhat better, but not by much. When support grows for an extensible language for doing 'web server things', then DC should implement it, as an editor program that supports it should be able to get everything it needs from some form of DTD in order to understand the Zope specific tags. Such an editor would arguably need three basic views: a server-side source view, a client-side source view (after server-side parsing), and a client-side WYSIWYG view (after client-side parsing). Currently, no single editor provides this three way view (unless you add in a browser and view source), because currently no one is drawing a sharp distinction between languages parsed on the client (HTML, XML) and languages parsed on the server (DTML, etc.). Ideally, one would be able to make the appropriate kinds of changes in each view, and have the changes trickle up and down to the other views. Until that happy day arrives, simplifiying DTML syntax and using Python external methods should suffice. I would much rather DC focused on the Zope interface, object system, and underlying machinery. 01 (just my two bits), Michael Bernstein.