RE: [Zope-dev] manage_afterAdd and manage_beforeDelete
Well, technically there is a constructor of sorts - the DTML method or External method that is the target of the "Add" form for your ZClass is basically the equivalent of a Python constructor
I've been adding a method to my ZClasses called 'manage_afterAdd' (and often, 'manage_beforeDelete'), which are called by the ZClass framework, I think. It's really convenient, but I'm not entierly sure they're not reserved for internal uses. I haven't found anything that uses them yet.
Mike Pelletier.
(I've CC'ed the lists on this, since it probably of interest to other folks out there...) Mike, It probably a bad idea to try to use manage_afterAdd as a handy constructor - the manage_afterAdd and manage_beforeDelete methods are currently a lightweight solution for the fact that there is no "event model" in Zope, but often objects will want to perform some extra activities when they are added/deleted (such as add or remove themselves from Catalogs). The manage_afterAdd, in particular, could get you in trouble, since it will also be called whenever an object cut/copied and pasted to a new location. In that case the construction logic would almost certainly not be appropriate, and could actually run without raising an error, but re-initializing and wiping out the existing data in your object in the process. :( In general, the manage_afterAdd and manage_beforeDelete protocol should be thought of as hooks for fixing up or cleaning up the environment of an object on add/delete/cut/copy/paste events (registering and unregistering with Catalogs, etc.). Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
It probably a bad idea to try to use manage_afterAdd as a handy constructor - the manage_afterAdd and manage_beforeDelete methods are currently a lightweight solution for the fact that there is no "event model" in Zope, but often objects will want to perform some extra activities when they are added/deleted (such as add or remove themselves from Catalogs).
The manage_afterAdd, in particular, could get you in trouble, since it will also be called whenever an object cut/copied and pasted to a new location. In that case the construction logic would almost certainly not be appropriate, and could actually run without raising an error, but re-initializing and wiping out the existing data in your object in the process. :(
In general, the manage_afterAdd and manage_beforeDelete protocol should be thought of as hooks for fixing up or cleaning up the environment of an object on add/delete/cut/copy/paste events (registering and unregistering with Catalogs, etc.).
To reinforce your point, these hooks should absolutely not be conected with constructors in any way. Adding an object is not like creating it. These hooks are for objects that modify their environment and, therefore, need to know when they've been inserted into or removed from an environment. Most objects should not modify their environments and should not need these methods. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (2)
-
Brian Lloyd -
Jim Fulton