Proposals Table of Contents Last edited on Jan 20, 2001 9:00 pm
Zope Fish

Non-Persistent Control Panel Proposal

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




The Control Panel and its contents are Persistent objects, stored in the ZODB. This causes trouble for ZEOfiedx Zope installations, since either multiple clients try to recreate filesystem Product objects, or each one has to use a common Product object which may not accurately reflect the state of the Product in that client. If you delete the directory for a Product, the corresponding object remains until you manually delete it.

This persistence is pointless, since these objects aren't meant to be edited, they don't support Undo, and they can easily be recreated if they don't exist (and often are, anyway).

Since the root Application object and the Control Panel depend on the ZODB, in the event of a problem with the storage Zope cannot provide through-the-web diagnosis or recovery.

Filesystem Product objects aren't meant to be edited through the web, but nothing stops you from editing them in the current implementation. This prevents them from being purely informational objects. That is, they are more than just a means to check the status and configuration of filesystem Products. Since you can put persistent objects in them, they have to be persistent.

Proposed Solution

Separate through-the-web (TTW) Products from filesystem Products, perhaps even taking TTW Products out of the Control Panel entirely. Change the Control Panel and its Products collection into completely read-only, non-persistent objects used solely to monitor and control the state of Zope.

Make the Control Panel accessible regardless of the state of the ZODB. Even if the storage fails completely, allow users defined in the access file to navigate through the Control Panel in order to diagnose and perhaps attempt to remedy the failure. Provide a Control Panel view of logging messages emitted during Zope startup.

Every time Zope starts, it should create a Control Panel object and all of its subobjects. Objects in the Products collection should represent the status of filesystem Products only. TTW Products should be kept in a separate, persistent collection, perhaps not even in the Control Panel. ZPublisherx should special-case access to the Control Panel so that it cannot fail due to problems with the state of the Application object.

Products should be able to mount read-only filestorages when initialized. These could contain help system data, or in the case of distributed Products the entire implementation.

Risk Factors


This proposal covers an unfortunate amount of ground.


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