I was concerned about non-UI situations where item attributes are
modified...
- I tried to imagine situations relating to calendar+email items, where
the emailness implied that something else was updating email-related
attributes. That confused me pretty quick.
- Then I mentally handwaved around calendar+task items, but taskness
isn't well-defined in 0.6: it's pretty-much a no-op.
- Then I tried to think up a reminders example, but by then it was
lunchtime and I went to eat.
So, I can't think of a specific case - I'm just worried about the
general case of some third-party item having code that modifies its own
attributes based on non-UI-centered state change, and doesn't use
setAttributeSafely to do it. (*cough* Zaobao? *cough* -- ok, I'll stop now.)
...Bryan
Katie Capps Parlante wrote:
Jeffrey Harris wrote:
- It looks like not only UI code, but any modification to ContentItem
attributes must go through this mechanism, right?
Yes, although Ted's busily trying to convince me there's a better way, I
hope he's right ;).
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.
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
