On 26 Jul, 2006, at 09:59, John Anderson wrote:
Grant Baillie wrote:
Sure. But how exactly would this work: i.e. onValueChanged(),
monitoring the changed values, or some other way? I'm a little
wary of onValueChanged() becoming overly complex. In general, we
want to index these attributes, so what I'd like to see is an API
similar to what's now pim.Calculated:
...
This would create an attribute which is a property on the class,
and also create the appropriate index (named the same as the
attribute). Maybe it somehow caches the value so that
getInterestingDatetime doesn't get called every time the attribute
is accessed (though it's not clear that's necessary).
(FWIW, it's the index that ends up creating a monitor here to
update when changes are made to the "source" attribute).
I'm also not in favor of using onValueChanged.
A simple implementation possibility would be to use a python
property for each source attribute involved in the complex
calculation. It would set the source attribute and call the complex
calculation method that might update the indexed attribute.
I could see that being good in simple cases with tightly coupled
attributes. An example of this might be (mentioned in a different
Bryan-initiated thread) triageStatus and triageStatusLastChanged, the
latter being the datetime the user last set triageStatus.
I'm not so sure this will scale well to some of the more complex
calculated attributes required by the dashboard/stamping specs. The
"next interesting date" case, which could potentially have to
traverse several item attributes (and item stamps) is a case in
point. It seems odd to have the code to update that attribute spread
out all over the code base.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
