In the long run, a xml editor will be able to get the document from zope, edit it, and update it through webdav. This will solve the gui editing problem. The user edit the document with the xml editor and can embeed the dtml tags inside the xml file to allow dynamic contents. Zope should take care the versioning : if an older version of xml file is exist, it will allociate a new version number, and publish the old version with another url (with versioning). Some new tags should be added to allow the automatically publish the history, the revision date, md5 etc of the document. Just like all the W3C documents on the web. Zope should also take care of publishing the document in multiple ways : source code, source code with dtml-rendered, html pre page, html tar ball, pdf, etc. Zope shoule be able to publish a partial sub-tree of the xml doc with criteria set (adding the root node if necessary). Zope should goes the way to client-side rendering as far as possible, with possible fallback facilities: zope should sent the xml file to the client, with xslt and css to off-load the server. A fallback parameter will then let the server do the rendering if the client fail to do so. Currently, zope's dtml syntax prevent it from embeeded in xml files. Versioning is required for zope to be a content manager. IMHO versioning should be essential part of all web storage system.
Has anywone worked on a mechanism for taking HTML documents that are FTP'd or HTTP-POST'ed by end-users and manipulating them into Zopish documents -- inserting <dtml-var standard_html_header> and <..._footer> tags, for instance?
It seems to me (though I haven't tried yet) that there's more at work than just prefixing/suffixing the content with the <dtml> codes when rendering it. Though such a result might be renderable, it would certainly not be HTML-conformant (prob. two sets of <HTML> and <HEAD> codes) and might give unusual results (the possiblity of conflicting <HEAD> elements in the document and in the standard_html_header; ...).
On a related note, it might be interesting to run a second, modified FTP handler on a Zope Server, which "Zopifies" HTML documents upon upload, perhaps even storing them as some subclass of DTML Document which renders itself as DTML but which returns the originally-uploaded document if accessed via FTP.
Again, I'm just asking if anyone's done any work along such lines. It seems a fairly useful feature to offer if (a) your end-user base is used to more traditional HTML publishing and (b) you want to gain the benefits of Acquisition while making it transparent to your end-users.