Yeah, I think this is a general concern - setting these attributes in
the general case from other 3rd party code.
So one of the mechanisms that Jeffrey and I talked about was setting an
attribute on the item before setting any attributes, which would
indicate how future attribute setting would be done.... I'm sure most of
you have seen this, but for review:
>>> event.modifyingFor = THISANDFUTURE
>>> event.title = "New Title for the future"
>>> event.modifyingFor = None
Now one way of handling the case where the user doesn't set it:
>>> event.title = "New Title for ambiguous case"
EventAttributeError: Can't modify calendar attribute 'title' without
setting modifyFor
I imagine things is that the AE's could catch this known exception and
throw up the alert dialog, and then try re-applying the change. But I
heard from Jeffrey that Bryan was concerned about wx eating exceptions,
though I don't see how it could in the above simple callstack. Perhaps
AEs could complicate that and bring wx into the picture though.
Jeffrey had another idea where you'd return a callback which would
actually do the setting
>>> attributesetter = event.setAttributeSafely('title','New Title for
the future')
>>> if attributesetter:
... modifyingFor = promptUserForModification()
... attributesetter(modifyingFor)
this simplifies the AE code because it doesn't have to worry about what
attribute its setting
A third approach would be to return that attribute setter in the exception
>>> try:
... # Could set event.modifyingFor to avoid the exception
... event.title = "foo"
... except EventAttributeError, e:
... modifyingFor = promptUserForModification()
... e.resetAttribute(modifyingFor)
The exception-based mechanism at least allows for other APIs to
generically set attributes. I don't know if or how we do read-only
attributes but if they throw exceptions at least that would be
consistent across the Item APIs that incorrectly set attributes will
fire exceptions.
I really like exception-based solutions, but that's just my take. Thoughts?
Alec
Bryan Stearns wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
