[Dev] RecurrenceDialog in Table

[John Anderson]

Tables already have a delegate that is intended to providing specialized 
behavior, which we might be able to use here. It would be nice if we 
didn't also need additional subclasses. If and when we have a GUI 
builder, the fewer the number of specialized blocks the better. It would 
be unfortunate if we ended up with all of Chandler being build only from 
Chandler specific blocks.

John

Alec Flett wrote:

> I think we're blurring the line between a block and a view with the 
> Table/wxTable class. Tables are useful for sure as widget-level 
> blocks, but as we move forward the table summary view is going to 
> become more specialized.
>
> Table should be a regular low-level block, and a new class, 
> TableSummaryView, should derive from it, and add capabilities like 
> recurrence support. This would also allow TableSummaryView and 
> CalendarCanvas to then both derive from sort of SummaryView mixin 
> which would allow for a common place for things like menu updating and 
> so forth.
>
> So my propsal, in python:
>
> class Table(Block):
>  ... as it stands now...
>
> class SummaryView(object):
>    """
>    mixin class for event updating, and so forth
>    """
>    def onRemoveUpdateUI(...):
>    etc...
>
> class TableSummaryView(Table, SummaryView):
>    """
>    provides chandler-specific behavior in the summary view - 
> dashboard, and so forth
>    """
>  
> class CalendarCanvas(CollectionCanvas, SummaryView, ....)
>    """
>    similar to the existing class
>    """
>
> Thoughts?
>
> Alec
>
> John Anderson wrote:
>
>> Hi:
>>
>> 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.
>>
>> John
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
>