Rik Hoekstra wrote:
Once in a while the subject of wysiwyg comes up on the list, as it did in the last few days. TO summarize the discussion as I understand it: The main problem is that people want a wysiwyg front end for their Zope database/web environment. On first consideration this seems to be something very desirable especially for end users. The problem of content management in web applications is present in other web application servers as well. Therefore various wysiwyg environments have their own solutions for this problem. Just some examples I happen to be acquainted with: - dreamweaver makes a difference between editable zones and ineditable zones in html;
If you want it to. Otherwise you can leave everything editable. It also supports merging XML data into templates to create pages.
<stuff on homesite and frontpage deleted>
The wysiwyg approach also seems to have the inevitable consequence that all of these editors mangle your html in an inexcusable way - so what you get may not at all be what you want.
Dreamweaver was specifically engineered to avoid this problem. The only thing it does in this regard is fix syntax and nesting errors, and even that can be turned off easily. It most certainly does not mangle your HTML. I still have nightmares about a twelve hour session with Frontpage, trying to get it to not mangle my javascript and move it out of the head and into the body of the page <shudder>.
Zope has some inherent features that make these solutions not adequate, as Michael Bernstein (I believe) pointed out. They have to do with the difference between rendered documents and source code.
Yes. An ideal environment needs to display: A) source of unrendered code (in multiple files) B) source of rendered page (usually obtained by 'view source' now) C) A wysiwyg view of the rendered page. It would be _very helpful_ if changes in B and C were back propagated to A. It would also be helpful if when I highlight a section in any view, the relevant portion was highlighted in the other views as well. Now, let me clear up some confusion about what I want _as a designer_: At no time was I advocating this type of setup or any other WYSIWYG environment as a method for adding or editing content. I was describing what I believe to be an ideal environment for designing and editing _layout code_, which is what designers are most concerned with. And many design mistakes can only be easily corrected from within an unrendered source view. For example a munged layout due to a closing </td></tr> improperly nested within a conditional statement. Content should be added and edited from within the web browser. Period.
This is further complicated by the separation of code of and layout as a result of which al templates and logic tend to be in different documents than where actual textual content is managed.
Exactly. But until XML and XSL are more widely deployed, code and layout cannot be as easily separated from each other as content can be from them both, using current tools. <idle_speculation> Hmm, perhaps the solution lies in creating some type of 'layout-only' object. </idle_speculation>
I have been contemplating this issue for some time now, because it is crucial in an academic environment in which all sorts of people with all sorts of abilities (not just designers but also 'just' students and teachers and secretaries) are going to be giving input to a website. Considering all I have come to the conclusion that a webinterface will be the way to go, at least for me.
I absolutely agree that adding and editing content should be done strictly through a web interface.
<justifications for using a web interface for content add/edits deleted>
The only issue at the moment is that the current management interface (while it is a pleasure to work with for developers) is not at all useful for non-developers.
It would be useful if it were as easy to construct add/edit interfaces outside of the mgmt. interface.
All taken together I do not thing there will be a solution in the direction of wysiwyg editors.
I disagree. Designers need visual tools to be as productive as possible, and they will have them.
Instead I would plea for the development of a toolkit for end user web-based editing environments, as I believe many of us are developing them at the moment. Is anyone interested? Ideas? Comments?
I believe that in the short term, extending Homesite and Dreamweaver to understand DTML and access Zope directly would be the most productive avenue of exploration. Dreamweaver can be extended via a published API that someone posted to the list recently, and there is an interesting article in the October WebTechniques about doing so with Java, so perhaps it's possible to extend Dreamweaver with Python as well. Homesite can also be extended, using VTML (Visual Tools Markup Language), but it has the disadvantage of belonging to Allaire, a company who's main product (ColdFusion) is competing with Zope. Interestingly, the guy who originally wrote Homesite, Nick Bradbury, is currently working on a CSS editor using Mozilla's NGLayout engine for the wysiwyg display. It will integrate and replace Homesites CSS editor when installed if you have Homesite, or work as a stand-alone editor otherwise. It's called TopStyle http://www.bradsoft.com. In the longer term, a completely new class of IDE needs to be created that allows for changes in all three views (unrendered code, rendered code, and WYSIWYG) to be reflected in the others transparently. The first example of such an IDE that I've seen is Netscape Application Builder (NAB) which is unfortunately is not only Java and EJB specific, it's Netscape Application Server specific. which is why no one other than NAS users has ever seen it. WebDAV will help bring this about eventually. But I have seen the future, and it has three views. Michael Bernstein.