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
