[Dev] RecurrenceDialog in Table

[Alec Flett]

>  It would be unfortunate if we ended up with all of Chandler being 
> build only from Chandler specific blocks.
>
But ultimately, we're building chandler, we're going to need to write 
chandler-specific code somewhere.

I understand the delegate option, but it seems like whats going to 
happen is that as we add more and more chandler-specific behavior 
(triage, etc) to the table summary view, we're going to keep having to 
add more and more hooks to call the delegate to the base Table class, in 
order to delegate this application-specific behavior. Its the same thing 
that happened with the sidebar, and you yourself moved that to 
main/view/SideBar.py. (and I think that was the right decision)

My concern with heading down the delegate path is that we're going to 
have to constantly complicate the Table class to make the delegate be 
able to handle more and more - this adds complexity to both the Table 
class and its delegate.

For example, Jeffrey's recurrence dialog has to be hooked up when we 
change attributes of an item. So to use the delegate, it seems like we'd 
have to add code to Table to delegate attribute setting, and then add 
code tot he chandler-specific delegate to hook up the recurrence dialog. 
If we just derive from Table (or contain it) then the complexity falls 
almost entirely to the subclass of Table.

Further, I'd like to address this:
>  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.
We don't have a GUI builder. Even if we did, there would always be a 
need for handling subclasses of existing blocks - I think that would be 
a requirement for the actual use of a GUI builder.

That said, I don't foresee any GUI builder springing into existence 
anytime soon. Too often we use this "if/when we have a GUI builder..." 
as an argument towards one design or another, and it gets used to trump 
any other architectural arguments. Lets deal with what we have now.

Alec


> 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
>>
>>