The onValueChanged() method was invoked on an item instance after any Chandler
attribute change. This was too big a hammer and is now replaced by something
more fine grained, a new 'afterChange' attribute aspect that may list one or
more names of methods to invoke on an item instance after the corresponding
attribute(s) change.
- the protocol of an 'afterChange' method is the same as the former
onValueChanged():
def onBodyChanged(self, attrName):
...
where 'attrName' is the name of the attribute that changed. Having this
argument makes it possible to use the same method for several attributes if
desired.
- an 'afterChange' method is invoked on an item instance only if that method
is defined. It is not an error to specify the name of an undefined method.
The reason for this is that attributes are inherited (or even shared among
unrelated kinds) and the 'afterChange' attribute aspect method names are
stored on the attribute schema item.
- as stated above, the 'afterChange' attribute aspect expects a list of
method names. No code should be made to depend on the order of names in
that list for the order of method invocation, which may be random.
- I added a kludge to the schema API to update existing (usually inherited)
attributes with an 'afterChange' aspect value:
schema.afterChange(attrName=['method', 'names'])
until Phillip replaces this with a new decorator or somesuch.
If the attribute already has an 'afterChange' aspect, schema.afterChange()
appends the method name(s) to the existing value, removing potential
duplicates.
- to set an 'afterChange' attribute aspect, the attribute has to be
defined for that kind (or class) or inherited. With onValueChanged() it was
possible to write code reacting to changes for non-existing attributes. For
example, CalendarEventMixin's onValueChanged() method (now called
onEventChanged) was reacting to changes in a bunch of attributes
among which 'body' and 'lastModified' which are nowhere defined in its
kind/class hierarchy. This was working because item instances of
CalendarEventMixin are also ultimately instances of kinds/classes where
these attributes are defined.
With the 'afterChange' aspect, this trick is no longer possible. The
schema.afterChange() API emits a warning into chandler.log accordingly.
I fixed up all Chandler code using onValueChanged() to use the new
'afterChange' attribute aspect instead. I renamed the onValueChanged() methods
to use more relevant names but they sure can be renamed again...
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
