An attribute monitor is a method defined on an item that is invoked when something happens to the attribute(s) it registered an interest in. That invocation is synchronous and reacts to changes on items in the same repository view as the item of the method being invoked.

Currently, the data model supports so-called ’set’ monitors that fire when an attribute’s value is set, changed or removed.

Before a monitor method can be invoked it needs to register an interest in operations on one or several attribute names. That registration is persistent and propagates to other views once the registering view commits its changes and the other views get refreshed.

Let monitor be an item and attributeChanged be a method defined on monitor, then: Monitors.attach(monitor, 'attributeChanged', 'set', 'food') Monitors.attach(monitor, 'attributeChanged', 'set', 'drink') registers an interest in ’set’ changes in the food and drink attributes for the monitor.attributeChanged() method.

That method, defined on monitor, needs to have at least the following signature: def attributeChanged(self, op, item, attributeName): where op is currently always ’set’, item is the item whose attribute changed and attributeName is the name of the attribute that changed.

You may pass extra arguments and keywords to Monitors.attach(). These arguments are then added to the monitor method invocation. They must be values of types that can be persisted in the repository.

Please note that monitors are matched against attribute names. It is therefore likely that a monitor method is going to be called for changes on items that it is not interested in. Since the monitor method registration propagates to other views as they refresh, a monitor method may also be called in views that it is not interested in running in. It is the monitor method’s responsibility to verify the relevance of the invocation before it acts on it.