[Dev] RecurrenceDialog in Table

[John Anderson]

Putting it in Table assumes that you would never edit it anywhere else, 
e.g. a DetailView.

So far I think the dashboard functionality is mostly deteermined by the 
sort function on the table and code that specifes which attribute to 
place in the cell.

Bryan Stearns wrote:

> I don't see how it's better to put knowledge of proxies into attribute 
> editors instead of Table (since they're both at the same "level" of 
> chandlerness).
>
> I agree with Alec that we'll need to put more Chandler-specific 
> knowledge at the root of the summary view very shortly for the 
> dashboard, if we're not there already because of this proxy issue. 
> Because of that, I don't think it makes sense to do a lot of 
> refactoring (pushing proxy knowledge into AEs) when we're going to 
> have a convenient Chandler-aware base for the summary view soon.
>
> ...Bryan
>
>
> John Anderson wrote:
>
>> On first glance it seems like these features belong more to the 
>> AttributeEditor, not the Table, if you want it to apply to any place 
>> the calendar event mixin is edited.
>>
>> Jeffrey Harris wrote:
>>
>>>Hi John,
>>>
>>>  
>>>
>>>>I noticed that in revision 7115 you added RecurrenceDialog to Table. On
>>>>first glance it doesn't seem like all Tables should know anything about
>>>>recurrence since Tables are used in lots of situations besides the
>>>>summary view.
>>>>    
>>>>
>>>
>>>Are there situations where a Table is working with only items that can't
>>>be edited, or only items which could not possibly have been stamped with
>>>CalendarEventMixin?  In those circumstances, I agree, a recurrence
>>>dialog won't come into play.  My guess was that those circumstances are
>>>rare.
>>>
>>>I have little attachment to where the recurrence proxies come into play.
>>> The requirements, as I've understood them, are:
>>>
>>>A) Use a proxy whenever a calendar event mixin might be edited
>>>B) Never set a reference attribute's value to a proxy, as the repository
>>>doesn't believe in proxies (the reverse is perfectly fine, however, as
>>>proxies do believe in the repository), so if P is a proxy for A, B.a = P
>>>is disallowed, but P.b = A is fine
>>>C) Use the same proxy for items that are drawn as items that are edited,
>>>so that edits are visible when the recurrence dialog pops up
>>>
>>>There used to be a requirement D) that proxies persist between edits, so
>>>that a series of attribute edits to the same item wouldn't pop up the
>>>dialog over and over, but this turns out to have been a misunderstanding.
>>>
>>>Sincerely,
>>>Jeffrey
>>>  
>>>
>>------------------------------------------------------------------------
>>
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>>Open Source Applications Foundation "Dev" mailing list
>>http://lists.osafoundation.org/mailman/listinfo/dev
>>  
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20051005/ecb8c114/attachment.htm