Proposals Table of Contents Last edited on Jan 21, 2001 3:13 am
Zope Fish


Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the AbstractZopeGUIDiscussion to make comments.


Martijn Faassen (


Currently the Zope GUI is based on HTML. The GUI code is embedded deeply into the core Zope components; see CleanUpTheCore for a related proposal that deal with this. This proposal assumes CleanUpTheCore is happening; without CleanUpTheCore the problem becomes even more severe.

We would like Zope to support various GUI interfaces besides the current web interface (see also ZopeStudiox and the ManagementInterfaceNG proposal). The implementation technology of the various current and future UIsx varies heavily:

We would like all of these developments to have the potential for success. Currently they are severely hindered though. In part this is described in CleanUpTheCore; the other part will be described here.

In order to supply a UI for a particular component, someone (such as the UI developer or the developer of the original component) needs to write an adaptor layer on top of the component that supports that particular UI. When the UI changes, or when a new GUI is developed, the same thing needs to happen again. Thus, any new UI will have to somehow get all components updated.

An alternative approach is to bootstrap a new GUI on top of another one. ZopeStudiox for instance might display legacy Zope objects it doesn't know to deal with in their HTML management interface. This isn't a clean approach however; the point of a new UI is to improve things, after all. If we can offer more advanced editing widgets for instance, we don't want these editing widgets to go unused for most components out there.

Proposed Solution

Build an abstract GUI layer. Individual Zope GUIsx implement this GUI layer in their own widget set (HTML, native, XUL).

The abstract GUI provides widgets such as views or windows, labels, text entry areas and buttons. There is also a very abstract layout system for these widgets; the idea is to make the abstract GUI as declarative as possible.

Concrete GUIsx such as the through-the-web management interface implements concrete versions of these widgets and the layout system.

A Zope component developer only needs to support the abstract GUI to be supported by all GUIsx. The various concrete GUIsx that implement the abstract GUI would then instantly be able to use these copmonents, and the components would always look native. The developer only needs to think about the GUI once. There can be automatic conformance to a lot of GUI guidelines.

In some cases the Zope GUI may still go beyond the underlying abstract GUI and directly speak to the components themselves to offer extra functionality; this can happen when the interface of the underlying component can be assumed to be stable, or if certain functionality is certain to be supported by all components (the object id would be a trivial example of this).

Risk Factors


This is a large project and should therefore be aiming for inclusion in Zope 3.0. Development of an abstract GUI can start at any time however. The transition could be made more gradual by providing abstract GUI functionality to product developers (with a HTML implemention) in parallel to the original Zope HTML GUI.

The project would not develop any concrete GUI except a reference implementation with a HTML interface.


View source AbstractZopeGUI
Advanced Actions / History
Visitor: Anonymous User
Jump to:
... by pagename prefix or search term.
For a plain search: