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