[Dev] Last Call on the Recurrence Spec

[Alec Flett]

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