I added yet another 'with' form to disable *all* notifications within a body
of code. All notifications are disabled, meaning all monitors (index or not),
watchers, observers, collection changes, *all* of them.
I use this new form during merging (as before, but it wasn't as thorough) and
while actually setting the initial values passed via keyword args to the top
Item __init__() method.
Because view.notificationsDeferred() takes precedence over the other
similar 'with' forms, view.reindexingDeferred() and view.observersDeferred(),
it makes more sense to nest view.notificationsDeferred() as the innermost
call when combining it with the other forms.
Deferred notifications are applied in the order they were queued when the body
of execution completes. Deferred notifications may be cancelled anywhere in
the body by clearing the acculumated notifications with the new
view.cancelDeferredNotifications() API. Note that this API doesn't reset the
deferring of notifications, it just clears the currently accumulated
notifications list.
Extra care should be applied when deferring all notifications as when the
notifications are finally run they are applied against the item's new values.
Because the order they are run in is the order they were accumulated in,
actual re-index monitor calls may occur after earlier notifications that may
depend on valid indexes are run. No error is raised in this case. Buyer
beware. A way around this, so that an error is raised, is to wrap a call to
with view.reindexingDeferred() around the with view.notificationsDeferred()
call:
with view.reindexingDeferred():
with view.notificationsDeferred():
...
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
