+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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
