[Dev] RecurrenceDialog in Table

[John Anderson]

Alec Flett wrote:

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

Obviously there is a line beyond which we should make a specialized
block -- the Sidebar is already over that edge. Maybe the Summary will
get there someday too. But we shouldn't go there until we need to.

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

It might make more sense to add this behavior to the AttributeEditors
instead of the 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.

All I'm suggesting is that, if possible, we should choose a design that
doesn't make a GUI builder difficult or impossible. I also don't think
the needs of a GUI builder will require drastic changes to our architecture.

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