FrontPage ReplaceableProperty / backlinks

Contacts

Shane Hathaway (shane@digicool.com); credit for most of the ideas goes to Phillip J. Eby (pje@telecommunity.com)

This proposal is still in a state of flux - add your comments to ReplaceablePropertyDiscussion.

Problem

The Zope object model does not currently provide a simple way to:

1. override objects in instances of ZClasses. This capability is desireable for making ZClass instances customizable, especially for users who do not have access to the Control_Panel.

2. create easily accessible singleton objects. It would be very useful to be able to reliably access a singleton object through acquisition, but currently Zope provides no protection against overriding the singletons in a subfolder either accidentally or deliberately.

Proposed Solution

A __replaceable__ property which can be set on any Zope object. ObjectManager._checkId() would be modified to look for this property. It would have three available states:

object.__replaceable__ = 0

object.__replaceable__ = 1

object.__replaceable__ = ObjectManager.NO_SUBOBJECTS_OVERRIDE

If __replaceable__ is 0 or not present on the object, _checkId() would behave as it does now. If __replaceable__ is set to 1, _checkId() would allow the object to be replaced even though it already exists (usually in the ZClass.) If __replaceable__ is set to ObjectManager.NO_SUBOBJECTS_OVERRIDE, _checkId() will not allow any object to be created with the given ID, even in subfolders.

In addition to the __replaceable__ property, DT_String should be modified so that DTML can access acquisition reliably. "this()" refers to the method context rather than its container, which is often the same but not always. To solve this, a "self" property should be set on the namespace object so that the method object (with the proper containment context) can be accessed through the expression "_.self".

All of these changes constitute only a few lines of code (perhaps less than 10) added to the Zope core.

Risk Factors

• If there are any objects out there that already have a __replaceable__ property, there may be side effects. It seems unlikely that there are any, however.

• If there is any place in Zope that lets web users create objects without going through _checkId() first, the singleton rule would not be enforced. On the other hand, _checkId() is a major component in Zope's security model, so if there is something that should be calling _checkId() but isn't, it needs to be fixed.

Scope

This proposal does not deal with user interface issues, such as how to set the __replaceable__ property on ZClass methods. The only objective is to make it possible to create easily-accessible singletons and configurable objects.

Deliverables

• The changes to the Zope core that implement this change.

• Documentation describing what __replaceable__ does. (Essentially a copy of this Wiki.)