FrontPage AbstractZopeGUI / backlinks

AbstractZopeGUI

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

Contact

Martijn Faassen (m.faassen@vet.uu.nl)

Problem

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 ZopeStudio^x and the ManagementInterfaceNG proposal). The implementation technology of the various current and future UIs^x varies heavily:

• HTML in the current management interface and ManagementInterfaceNG.

• JavaScript^x & XUL in ZopeStudio^x

• wxWindows widget in the various wxWindows Zope client.

• other widget sets such as Qt and GTK as well as native Windows would be possible.

• etc. We don't know what the future will bring, but we want to be future proof.

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. ZopeStudio^x 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 GUIs^x 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 GUIs^x 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 GUIs^x. The various concrete GUIs^x 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

• It's a major overhaul.

• Older components will need to be converted to the new abstract GUI (but only once, and they'd only need to track this GUI).

• It is partially dependent on CleanUpTheCore to provide a good basis to build on.

• Building generic GUI systems can take up a lot of time.

• lowest common denominator effect; it is harder for the component developer to do special user interfaces if the abstract GUI does not support what they want. (this does increase GUI consistency though)

Scope

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.

Deliverables

• Abstract GUI widgets that can be used to construct a Zope GUI (text entry, labels, tabs, views and windows).

• An abstract layout system for these widgets.

• A concrete GUI implementation that uses a HTML interface.

• A layer built on top of the core components using the abstract GUI.