Hi Katie, > Just to be clear, by "this mechanism" -- we're not saying that all code > using ContentItems needs to call "setAttributeSafely" -- only the UI > needs to worry about when/whether to prompt the user for more information. > > Any ContentItem can potentially be a recurring item, so any content item > might need to apply edits to either THIS or THISANDFUTURE. > > Is this what you mean here? If not, I may have misunderstood our > previous discussions.
My thinking has been that UI code, which I think means attribute editor code, drag and drop code, and the code that changes events in the calendar view (is that also AE code?) need to preface changes to ContentItems resulting from user input with a call to setAttributeSafely to allow a dialog to pop up asking about what the change should apply to. It just occurred to me that this call is only required if we assume that changes are propagated to the event or future events immediately. Originally I'd proposed a model where changes were batched and finalized when the detail view was unrendered or possibly at repository commit time. This makes occurrence/modification item code more complicated, and it means changes to any ContentItem's attributes could potentially be batched, but that may be the lesser of two evils. Ted, suddenly it dawns on me that this shift in approach was probably why we weren't understanding one another. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
