Personal tools
Skip to content. | Skip to navigation
This package provides support for behaviors. A behavior is a re-usable aspect of an object that can be enabled or disabled without changing the component registry. A behavior is described by an interface, and has metadata such as a title and a description. The behavior can be looked up by a given short name or by the dotted name of the interface. With this unique name behaviors metadata can be looked up. When the behavior is enabled for an object, you will be able to adapt the object to the interface. In some cases, the interface can be used as a marker interface as well. As an example, let’s say that your application needs to support object-level locking. This can be modeled via an adapter, but you want to leave it until runtime to determine whether locking is enabled for a particular object. You could then register locking as a behavior. Requirements and Limitations: This package comes with support for registering behaviors and factories. It does not implement the policy for determining what behaviors are enabled on a particular object at a particular time. That decision is deferred to an IBehaviorAssignable adapter, which must be implemented (plone.dexterity implements this). Like the IBehaviorAssignable plumbing, marker interface support needs to be enabled on a per-application basis. This package also does not directly support the adding of marker interfaces to instances. To do that, you can either use an event handler to mark an object when it is created, or a dynamic __providedBy__ descriptor that does the lookup on the fly (but you probably want some caching). A sample event handler is provided with this package, but is not registered by default The intention is that behavior assignment is generic across an application, used for multiple, optional behaviors. It probably doesn’t make much sense to use plone.behavior for a single type of object. The means to keep track of which behaviors are enabled for what types of objects will be application specific.
This package aims to make it easier to register visual components (e.g. views and viewlets) so that they only show up in a Plone site where they have been explicitly installed.
Cache purging support for Zope 2 applications
The plone.cachepurging package provides cache purging for Zope 2 applications. It is inspired by (and borrows some code from) Products.CMFSquidTool, but it is not tied to Squid. In fact, it is tested mainly with Varnish, though it should also work with Squid and Enfold Proxy. This package is not tied to Plone. However, if you intend to use it with Plone, you probably want to install plone.app.caching, which provides Plone-specific configuration and a user interface in Plone’s control panel. plone.cachepurging works with Zope 2.12 and later. If you want to use it with Zope 2.10, you may be able to do so by installing ZPublisherEventsBackport, although this is not a tested configuration.
Zope 2 integration for z3c.caching