[Zope-dev] 'object based' Zope editing (repost)

[Rik Hoekstra]

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