[Chandler-dev] Dashboard date and lastmodified proposal

[John Anderson]

+1. I've run into a number of situations where the fine grained 
onValueChange would be useful.

Grant Baillie wrote:
> So, there was a long discussion about this subject on IRC yesterday, 
> mainly between Phillip & Andi, with occasional interjections from 
> Bryan and me. Here's my understanding of what the plan is: Please pipe 
> up if you have corrections or objections!
>
> 1) The general "calculated attribute" case:
>
> - Andi will add an onChange attribute aspect, a way of specifying a 
> list of methods that will be invoked when a particular attribute is 
> changed. This is a more fine-grained version of the current 
> onValueChanged() hook for items, but will be initially implemented so 
> that the existing onValueChanged() calls still take place.
>
> - Phillip will add support in the schema API for being able to have a 
> syntax like the following for Calculateds:
>
> class ContentItem(Item):
>
>     nextImportantDate = schema.One(schema.DateTime)
>
>     @schema.onChange(lastModified, nextReminderTime, 
> 'CalendarEventAnnotation.startTime')
>     def updateNextImportantDate(...):
>     ...
>
> which is a way of allowing the updateNextImportantDate method to be 
> called whenever any of the attributes lastModified, nextReminderTime 
> or CalendarEventAnnotation.startTime change. (The latter is assuming 
> Events are implemented as an Annotation stamp).
>
> - Longer term, we will need to add support for specifying more than 
> just a method for the attribute aspect. (In the case of annotations, 
> as alluded to in the "Stamp/Annotation-related questions" thread, we'd 
> need to point to a method defined in the annotation class; i.e. the 
> schema API will need to pass an Importable here).
>
> 2) ContentItem.lastModified:
>
> - Andi will add support for a commit-time hook to the repository.
>
> - Phillip will figure out a way for "substantive" changes to take 
> advantage of that hook. More specifically, a way for all ContentItem 
> changes to be considered substantive, unless otherwise specified.
>
>
> A couple of notes:
>
> 1. Andi was a little concerned that the syntax in 1) would lead to 
> ambiguities in the order in which the callbacks would take place.
>
> 2. The example in 1) is an interesting one, because it involves code 
> (updateNextImportantDate) being called in response to a change in 
> lastModified. However, the change in lastModified could be happening 
> as a result of the commit-time hook, so it would be good to make sure 
> that any further changes made in updateNextImportantDate() are handled 
> appropriately (an unbounded recursion being inappropriate :).
>
> --Grant
>
>
> On 10 Aug, 2006, at 08:46, Andi Vajda wrote:
>
>>
>> On Wed, 9 Aug 2006, Bryan Stearns wrote:
>>
>>> That's kind of the reverse of what I was suggesting: the method name 
>>> hangs off any attribute that needs the method to be called, instead 
>>> of hanging it off the attribute the method updates. I think it might 
>>> work, though - something like:
>>
>> I think, we're in agreement actually. I was suggesting hanging the 
>> method off the attribute that changed not off the attribute that 
>> needs to change, ie the attribute the method updates.
>>
>> In other words, 'foo' changes, a method called say 'onFooChanged' 
>> updates another attribute, say 'lastModified'
>>
>>>  class Note(ContentItem):
>>>   nextReminderTime = schema.One(schema.DateTime,
>>>                                 onChange='updateNextImportantDate')
>>
>> Right, in other words, 'nextReminderTime' changes, a method called 
>> 'updateNextImportantDate' is called to make more changes elsewhere.
>>
>>> Also, using this for lastModified (as I've shown) looks possible, 
>>> though too wordy (since a parcel developer would have to remember to 
>>> put "onChange=updateLastModified" on every user-editable attribute).
>>
>> Yep, but one would hope that this list of attributes is finite. 
>> Another solution would be to introduce something discussed a long 
>> while ago but never implemented, another attribute aspect describing 
>> a difference between 'user' or 'domain' attributes and 
>> 'implementation' attributes. If we did this, we could have a sort of 
>> onUserValueChanged() method that works like onValueChanged() today. 
>> Still, it seems that that would reproduce what now seems like a 
>> mistake in hindsight, onValueChanged(), too big of a hammer.
>>
>> I think the per-attribute (yet optional) aspect naming a method to 
>> invoke on the item when the attribute changes holds the most promise.
>>
>> Andi..
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev