[Chandler-dev] Dashboard date and lastmodified proposal

[Andi Vajda]

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..