29
edits
(added "force" handling) |
(decision) |
||
Line 39: | Line 39: | ||
Choosing to defer events and their actions, is one step closer. Problem is which events we should defer in this way? Naturally we should defer further ''value changed sequences'', but only those three events triggered by a value changed? How about a "rogue" recalculate request during the value changed handling? Should that be deferred too? | Choosing to defer events and their actions, is one step closer. Problem is which events we should defer in this way? Naturally we should defer further ''value changed sequences'', but only those three events triggered by a value changed? How about a "rogue" recalculate request during the value changed handling? Should that be deferred too? | ||
# should we only start deferring events during a ''value change sequence'' | |||
# should any event handling in the model defer concurrent events? | |||
# how about "rogue" events, coming from script, etc.? | |||
# at least also defer rebuild? | |||
I believe the spec. only meant for option 1) to happen, so I think we should go for that. | |||
== The Event-Dispatch Queue == | == The Event-Dispatch Queue == |
edits