On Mon, Jun 12, 2000 at 01:12:33PM -0700, Michel Pelletier wrote:
Amos and I and the guys at Activestate were discussing cataloging at a recent training sessions and we came up with the following possible successor to CatalogAware.
The idea is that a CatalogAware object looks for two methods that return sequecnes of Catalogs that many be interested in this object. The first is class defined method 'getClassCatalogs', the second is an instance defined method 'getLocationCatalogs' that the instance can get from its classes, its instance dict, or acquisition.
The idea is that you provide methods that define the policy for finding Catalogs. The default class defined 'getClassCatalogs' is identical behavior to the old CatalogAware, but you can and probably will override it.
Very interesting indeed. Is the CatalogAware mixin in the future going to move towards Tres' Observable pattern? After initial notification of the set of catalogs (or other interested objects, or a generic notification manager) at creation time, the object will only have to call the 'notify' method, with the appropriate event name. In fact, I think all stock Zope objects should in the nearby future use the Observable pattern to advertise events like this. A catalog, or a specialist object can then react to those events by updateing the catalog. This mechanism allows further refinement of what happens when an object changes, allowing for complex indexing policies, where these policies are contained and thus manageable within one object instance. The pattern (implemented in a mixin class checked into the tree): http://www.zope.org/Members/michel/Projects/Interfaces/ObserverAndNotificati... In fact, I like this way of managing catalogs better than the CatalogManager proposals now in the Interfaces Wiki. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | The Open Source Web Application Server ---------------------------------------------