Bug in Changed events in ZPatterns 0.4.0a1?
As far as I can tell, the first time an object is changed, an Agent's _objectChanged() will be called, but as long as the object is still in the memory cache, _objectChanged() will not be called again. That is, I change an object - _objectChanged() is called. However, the object is now in the memory cache, so the next time I change the object, _objectChanged() is not called. If I flush the cache, or Refresh the Product, the next _objectChanged() will be honored (but the next-next one won't.) Alternatively, I may be misunderstanding something about the way these events work. Another problem I'm having is giving default values to objects (e.g. default UNAPPROVED status for approval). I can do this with a trigger (whith objectAdded being "client.status = UNAPPROVED"), but I also have a trigger that is equivalent to CatalogAwareness. The problem is that I don't know what order the triggers get called - will the changes made by one trigger be consistently cataloged by the other trigger? -- Itamar S.T. itamar@maxnm.com Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C
At 11:33 AM 6/19/00 +0300, Itamar Shtull-Trauring wrote:
As far as I can tell, the first time an object is changed, an Agent's _objectChanged() will be called, but as long as the object is still in the memory cache, _objectChanged() will not be called again.
_objectChanged is a once per object per transaction event.
Another problem I'm having is giving default values to objects (e.g. default UNAPPROVED status for approval). I can do this with a trigger (whith objectAdded being "client.status = UNAPPROVED"), but I also have a trigger that is equivalent to CatalogAwareness. The problem is that I don't know what order the triggers get called - will the changes made by one trigger be consistently cataloged by the other trigger?
I would suggest that you set up an attribute provider for client.status that returns UNAPPROVED. Since attribute providers are only active if the attribute does not exist, this should solve your problem. As for trigger ordering, they are guaranteed to be called in their plugin sequence for a given object, but the order of objects they will be called on is not guaranteed. However, if a trigger is shared between two DataManagers (Customizers, Racks, Specialists, etc.), it may be called sooner than expected from the point of view of one of the DataManagers' plugin sequences.
0.4.0a2 is out, to fix the bugs reported by Itamar and Mike. I have not yet reproduced all the bugs Mike has reported, but here's what's fixed in alpha 2: * The missing _objectChanged() message - it was very hard to track down, because everything appeared to be working right, except for the fact that it wasn't working. Turns out that _v_status_ (the variable, not the method) was an empty string. Which meant that what looked like self.__dict__['_v_status_'] in code was actually self.__dict__['']. As a side effect, this means that if you've used non-rackmounted DataSkins, they now have an '' (empty name) attribute that is not removable through the Zope management interface. Hopefully this will not affect any production apps since it has only been possible to have this problem since 0.4.0snap1. Anyway, the solution was to simply move the location in the class where the default value of _v_status_ was set. As for your DataSkins... well, you'll need to delete any instances if you want to be rid of the useless empty-named attribute. * Two of the bugs reported by Mike - the manage_setStorage/manage_pack stuff, and the NameError in createItem. I haven't been able to reproduce the "nonexistent _v_dm_" problem Mike has reported. Mike, are you on 2.2 or 2.1.x? Your last post on that subject was unclear, since you said "2.2.6" and there is no such version to my knowledge. :)
participants (2)
-
Itamar Shtull-Trauring -
Phillip J. Eby