More useful CatalogAware class?
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. Thoughts? -Michel """ This is a candidate successor to the CatalogAware class. """ class CatalogAware: meta_type = 'CatalogAware' default_catalog = 'Catalog' def getClassCatalogs(self): """ You want to over ride this method if you don't like the default policy of acquire a Catalog named 'Catalog' """ if hasattr(self, self.default_catalog): return [getattr(self, self.default_catalog)] def manage_afterAdd(self, item, container): self.catalog_object() for object in self.objectValues(): try: s=object._p_changed except: s=0 object.manage_afterAdd(item, container) if s is None: object._p_deactivate() def manage_afterClone(self, item): self.catalog_object() for object in self.objectValues(): try: s=object._p_changed except: s=0 object.manage_afterClone(item) if s is None: object._p_deactivate() def manage_beforeDelete(self, item, container): self.uncatalog_object() for object in self.objectValues(): try: s=object._p_changed except: s=0 object.manage_beforeDelete(item, container) if s is None: object._p_deactivate() def get_catalogs(self): cats = [] # first, try and call a class defined method to get # catalogs... we don't want to acquire... if hasattr(self.aq_base, getClassCatalogs): for cat in self.getClassCatalogs(): if cat not in cats: cats.append(cat) if hasattr(self, getLocationCatalogs): # next, try and call a method that can be class defined, # instance defined, or acquired. for cat in self.getLocationCatalogs(): if cat not in cats: cats.append(cat) return cats def catalog_object(self): """ Call this to catalog yourself """ for catalog in self.get_catalogs(): catalog.catalog_object(self, self.getPhysicalPath()) def uncatalog_object(self): """ Call this to uncatalog yourself """ for catalog in self.get_catalogs(): catalog.uncatalog_object(self.getPhysicalPath()) def recatalog_object(self): self.uncatalog_object() self.catalog_object()
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 ---------------------------------------------
participants (2)
-
Martijn Pieters -
Michel Pelletier