[Chandler-dev] Dashboard date and lastmodified proposal
john at osafoundation.org
Tue Aug 15 11:50:46 PDT 2006
+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,
> 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 :).
> 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,
>> 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.
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "chandler-dev" mailing list
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev