I suspect that everyone was away at IPC8 when I posted this mail, so I repost it here. (Unless, of course this is a subject no one is interested in or it's utter nonsense ;-)) Wysiwyg Zope editing possibilities has come up in the list more than once. Unless I understand the Zope Mozilla project wrongly, it seems to offer no solution, let alone a standardized one, as Johann Carlsson (the inventor of ZIE) is using XML-RPC for editing. The Zozilla and especially the ZopeStudio project offers some interesting points, though. Now I may be completely mistaken here, as I only half understand everything that has been going on. If so, flame me, and stop reading. If not, read on, and please bear with me, cause this turned out to be a lengthy analysis. The question of wysiwyg comes up on the list frequently, though. And it is certainly not solved, let alone in a portable way. The question of editing and the apparent difficulty of rendered editing vs source editing has been proposed as a fundamental objective to editing Zope html documents/objects ;-) in wysiwig editors. Let's for a second leave aside, whether wysiwyg editors are at all desirable and which. After pondering the question for some time I _think_ I may have a solution. It was triggered by an article of John Aycock and Michael Levy, "An Architecture for Easy Web Page Updating" in Crossroads <URL: http://www.acm.org/crossroads/xrds6-2/updating.html>. They state that the 'atomic document' is a myth and that 'a document is the fundamentally wrong level of abstraction for web page updating'. Then they go on to an architecture which breaks apart a document into editable regions and store these into a dbm-database. The documents are retrieved through a http like protocol (called UTTP and invented by the authors) and edited in a special client. Aycock and Levy's proposal sounded to me as if Zope has provisions for most of this already, but I would propose this could also be achieved through a web-based system. A dtml document is already composed of 'sections' (namelijk html and dtml sections). They can seen as a collection of objects (both real zope objects and section objects) that are together rendered as a html/xml/pdf/whatever document. The dtml object is -in fact- divided into 'inside-document' and 'outside-document' sections. All <dtml-var> related tags are 'outside document' sections and the other <dtml-...> tags are 'inside-document' sections. That is to say, the var tags _themselves_ are inside document, their content is outside document. At the moment, the sections are not visible inside the rendered document. Moreover dtml always either renders the whole document, or it does not, except for the inclusion of <dtml-var>'s that are called as 'not rendered'.
From a site-development point of view the different sections are editable by people with different abilities. In Zope terms these abilities are translated into roles: content managers and designers, dtml programmers, sql programmers. Content managers should not be bothered with dtml, programmers should be programming one object at a time.
An example: a content manager or designer should not have to be able to edit <dtml-if> tags or occupy himself with namespace issues. It _is_ nice for him to see what other content there is on the page he is designing for and what layout he is designing in. If he uses a wysiwyg editor _and_ a the site has a global stylesheet, it would be a good idea if the stylesheet was included at the time of entering content. The server (Zope) should handle that. What stands in the way of making sections editable is not, in my analysis, the dichotomy between document and object, but the fact that in developing in Zope you are dealing with either rendered documents or non-rendered objects/dtml-templates and never with partially rendered document/template hybrids. Or, in fact you are: the Zope management interface where you edit, say, a DTML Document, _is_ such a hybrid: the management interface itself is rendered while the document is not. The hybrid is just not extended beyond the boundaries of the dtml-template. But there is no real reason to do so as (1)Zope encourages factoring common content and (2) a document is in fact a collection of objects or regions. Because and as long this is so, Zope editing is confined to the dichotomy. What should be done to overcome the problem (an example is under the points> is (as I see it) to 1. devise a way to indentify sections in rendered documents. This could be done by making the rendering machinery mark the begin and end of a tag in the rendered version. 2. devise a way to treat sections as objects and make the objects editable _or_ rendered on basis of the roles of an developer. As far as I can distinguish it, this involves the following steps, but please correct me if I'm mistaken or : * Rendered and non-rendered sections should be included in one document. * Only non-rendered objects should be designated as editable. * Rendering (in editing view) is conditional on (1) the role of the current user (manager, content manager, designer etc)) (2) the needs of that user. In other words: the 'editing view' of a dtml object should show a user: a) which parts of a dtml template would be editible to him and b) he should be able to choose whether to render these object/sections or to edit them. * Outside-documents should alway be fully rendered. They should be treated as atomic. * This obviously means that the updating/uploading machinery should also be able to discern between the editable and non-editable sections. For this a simple block parsing mechanism (possibly derived from the dtml parser itself) should be used. * In order to keep track of what sections/objects of the document in question to update the uploading machinery should have knowledge of what was sent to the client (in whatever form). This will probably be the hardest part to figure out. It could be done by cookies, by including rdf in the document or in its header, and/or by editing in a session-like environment. What could and should be done in this case depends on the client that is used for editing. Therefore, the basic machinery should be the same, but it should have a possibility to plug-in different client-specific interfaces. This seems a very Zopish way to treat the problem. * A few thoughts/proposals for the Zope management interface: in the conventional Zope management interface this could easily be done by including textareas on the spot where an editable object is located. Or the document would be presented as a tree to the user, much in the way XMLDocument is now. This would also allow us to have 'collapsable regions' like many programming editors have (or at least this should be possible in the Zope Management interface and in Mozilla). pff. That was much more than I anticipated. I hope I have made my point clear. I wanted to discuss this, before I gave the idea a shot. A few questions beforehand: - is this a sensible approach to solving the rendered document vs object dichotomy - if so, what would be the best way to implement this? I was thinking of a product that would be called whenever the edit view of a dtml object was called. The product would handle the whole round trip from rendering to updating/uploading, including the parsing of the object. Is this feasible, or did I oversee something that would imply a much deeper reworking of the Zope machinery? Rik